Application Security TRENDS – Lessons Learnt- Firosh Ummer
Post on 18-Nov-2014
447 Views
Preview:
DESCRIPTION
Transcript
APPLICATION SECURITY TRENDS – LESSONS LEARNT
Firosh C Ummer, Technical Director, Paladion Networkswww.paladion.net
Contents Challenges in Enterprise Application
Security Programs Risk Based Application Security Program Threat Modeling in Application Testing Security Code Review Process
3
Why Application Security testing?
Application Vulnerabilities Exceed OS VulnerabilitiesDuring the last few years, the number of vulnerabilities being discovered in applications is far greater than the number of vulnerabilities discovered in operating systems.
http://www.sans.org/top-cyber-security-risks/
Threat Intelligence Report - 2011
>50% of attacks are targeted at application layer
Attacks are financially motivated – so they are focused on financial applications
Full report at: http://www.paladion.net/paladionlabs.html
5
Automated techniques are improving 600,000 websites compromised in 2 days with SQL Injection
Samy exploited XSS on 0.5 million users in 6 hours
It takes less skill to exploit an application
Tools are simplifying the attacks
6
It’s easy to make security errors
Few developers are trained in security
There’re a large number of attacks to aid
the adversary
Most applications tend to be insecure at first
A few common security flaws1. Weak input validation2. Relying on client-side validation3. Use of dynamic SQL queries4. Not escaping <, and > characters5. Incorrect cache control directives6. Un-patched servers7. Weak session management8. Weak encryption9. Wrong specs of expected input10. Misunderstanding of end-user environment
7
Threat Intelligence Report - 2011
XSS, Authentication & Session Mgmnt and Misconfiguration vulnerabilities contributes to more than 50%
Injection vulnerabilities are showing a downward trent
Mobile Applications On account of the variety in the mobile
space, each OS is an altogether different thing in itself.
Certain Basic Security concepts & test cases remain the same.
Some do change as every platform may have its own specific issues
Guideline standardization is difficult
Mobile Application security risks*
Insecure Data Storage Weak Server side validations & Controls Insufficient Transport Layer Protection Client Side Injections Poor Authorization and Authentication Improper Session Handling Security Decisions via un-trusted inputs Side Channel Data Leakage Broken Cryptography Sensitive Information Disclosure
More resources at:http://www.paladion.net/paladionlabs.html• Mobile Code Scanner for
Android• “InsecureBank” test
application for AndroidPlynt Certification
Criteria for Mobile Applications
http://www.plynt.com/criteria/mobile-application-criteria/
* OWASP Top 10
Challenges
Budgets are limited
Limited internal expertise
Standard pen tests take more time
Tools alone are not sufficient
11
12
Tools alone are not sufficient
High rate of false positives
They cannot detect business logic risks
Directly impact business
More difficult to find
E.g. Business logic risks An adversary can…
submit deposit requests on behalf of other users circumvent the maker/checker process modify the amount of a release request of other users insert negative amounts in cash deposits view deposit requests of other users estimate the available amount of other users
13
The 80/20 Approach
Goals of application security Program
1. Find all holes in existing applications
2. Fix them quickly
3. Avoid errors in new code
4. Be resilient to the latest attacks
15
Two phase approach16
1. Risk based enterprise testing program
1. Risk profile based testing schedules
2. Mix of manual & automated testing
2. Build long term capability
Risk based enterprise testing program
Basic characteristics1. Different levels of testing2. Framework for classifying apps3. Baseline standard checklist4. Automated workflow & online reporting
18
Different levels of testing All apps would not undergo the same level
of testing Some apps will get a full test Others will get a shorter, faster test
19
Different levels of testing
20
Black Box Testing
Penetration Test (Gray Box Testing)
Source code reviews (White Box Testing)
Application with Plain information & Low value
transaction
Application with User Access &supporting
critical business functions
Application supporting highly critical process
Different levels of testing
21
Application Type Test Type Frequency
High critical applications
Penetration Tests (Gray Box)
Quarterly
Code Reviews Annually
Medium critical applications
Penetration Tests (Gray Box)
Half yearly
Less critical applications
Penetration Tests (Gray Box)
Annually
Framework to classify apps A risk assessment framework to prioritize
apps Prioritizing helps share the limited budget
better between the apps Tailor the framework to the needs of the
business Developed in close consultation with
business owners Multiple iterations to develop
The draft framework have many questions/criteria
22
The criteria in the framework Is the data sensitive? Is the application critical? How connected is the application?
23
Baseline standard for the security tests A minimum set of checks for all apps
Does it do input validations at the server? Does the app adhere to the password
policy? Is it safe against SQL Injection, XSS
24
Automated Workflow
25
26
Dashboard Reporting
Application Penetration Tests
28
MethodologyUnderstandi
ng the application
Creating a Threat Profile
Creating a Test Plan
Performing Manual &
Automated Tests
Creating a Report
29
Step 1: Study the Application Features, functions Walk through site Read the manuals Interviews, questionnaires Make sense of the modules
30
Step 2: Create Threat Profile Threat Goal of the Adversary Threat Profile List of All Threats
An adversary…Siphons off fundsReset passwords of other usersViews account statement of others
31
Creating the threat profile Structured process to create Threat
Profile Select known threats from available
Repository Brainstorm on additional risks Consult business to verify Threat
Profile
32
Sample Threat Profile for Internet Banking An adversary…
Siphons off funds from one account Views account statement of other users Adds beneficiaries to another account Orders check book on behalf of others Resets the password of other users Edits the profile of other user
33
Threat profile repository Structured process to create Threat
Profile Select known threats from Paladion
Repository Brainstorm on additional risks Consult customer to verify Threat
Profile
34
Sample Test Plan for 1 Threat in Internet Banking Views account statement of other users
SQL Injection on AccNo in request Variable Manipulation attack on the AccNo
in the request Directly access the pdf/word file on the
server Access the file from the browser cache
35
Test Plan
36
Executing Test Cases Mix of manual and automated techniques• Manual Testing
• Business logic flaws• Privilege escalation
• Automated Testing• Injection attacks• Cross site scripting
37
Publish the Report Executive Summary
Strengths Weaknesses
Detailed Findings Solutions and fixes Compliance to standards
Central Bank Guidelines PCI-DSS
Code Reviews
39
Benefits of Code Review More exhaustive than Penetration Tests
Finds all instances of SQL Injection, XSS, etc Best method to find Backdoors
Malicious backdoors Inadvertent backdoors
Better suited for Finding cryptography related vulnerabilities Analyzing application configuration issues
Precise solutions, pin-pointing the vulnerability Easier to fix
40
Methodology 7-step structured methodology
Threat-profile based approach to focus on what’s important
Hybrid of manual and automatic verification Custom scripts tailored for each application
41
The 7-step Code Review Methodology
Study Application
Create Threat Profile
Study Code Layout
Code Review Plan
Analyze Code
Preparation
Analysis
Verify Flaws
Generate Report
Solutions
1
2
3
4
5
6
7
STRUCTURED METHODOLOGY→ THREAT-PROFILE BASED APPROACH TO FOCUS ON
WHAT’S IMPORTANT→ HYBRID OF MANUAL AND AUTOMATIC VERIFICATION→ CUSTOM SCRIPTS TAILORED FOR EACH APPLICATION
42
Step 3, 4: Code Layout and Plan
Step 3: Study Code Layout Get familiar with Pages, Forms, Classes Identify critical classes:
Authentication, Authorization, Critical transactions Step 4: Code Review Plan
Map each threat to pages, classes, or config settings Pick relevant tests from reference checklist Review with the code owner
43
Step 5, 6: Analyze and Verify Step: Analyze the code
Dissect Pages, Classes, Settings Consult Reference checklist Combination of manual and scripted techniques
Step 6: Verify the flaws Verify exploitation through walk through Take screen shots of code snippets Ensure the snippets tell the story
44
Step 7: Publish the Report Executive Summary
Strengths Weaknesses
Detailed Findings Solutions and fixes
Pin-pointed to lines of code Easier to fix, as it’s more precise
Compliance to PCI DSS standards Review with supervisor Published to client
Build Long Term Capability
Integrate Security in SDLC Traditional Methodology
SRS Design Development
Testing Deployment
TrainingSecurity Specifications for 3rd party
SRS Security Checklist
Threat Modeling
Architecture Review
Security features
Code Review
Coding Guidelines
Code scanning
Security Test cases
Evaluate against Threat model
Define secure build
Automated Scan
Hardening
Vulnerability Assessment
Pen test
47
Avoid errors in new code Train developers, designers Define application security standard/best practices Measure Effectiveness
Integrate security in SDLC – 80/20
48
Build long term capability with Training
Training for Developers, Designers and QA
New code gets safer as team is more aware
Fixing apps also become easier QA starts security test cases 1-2 days trainings are popular
49
Standardize Define Standards for Developers & Designers
Secure Coding Standards for Developers
Secure Architecture Framework for Designers
50
Application Security Standard 40 – 60 standards
75% mandatory, 25% optional
Critical apps to meet all standards
Less critical ones need to meet only
mandatory controls
51
Examples Mandatory
The application must… Insist that the user changes password on first login Maintain an audit trail of all successful and failed logins Timeout user sessions after 15 minutes of inactivity
Optional Critical applications must…
Display last 3 transactions when the user logs in Forcefully log out the user when unexpected inputs are
received
52
Measure effectiveness Institute reviews to measure progress
Architecture reviews of new apps Code Reviews of new Code Penetration Tests
How many bugs are slipping into the next developmental stage?
How quickly are classes of security bugs disappearing?
sales@paladion.net
Thank You
top related