This document discusses lessons learned from application security trends. It recommends a risk-based application security program with two phases: 1) A risk-based enterprise testing program with different levels of testing based on application risk, and a framework to classify applications. 2) Building long-term capability through training, standardized security practices, and measuring effectiveness. Key aspects include threat modeling, code reviews, defining security standards, and integrating security into the SDLC to prevent errors in new code. The goal is to find and fix vulnerabilities while building resilience against the latest attacks.

1. APPLICATION SECURITY TRENDS – LESSONS
LEARNT
Firosh C Ummer, Technical Director, Paladion Networks
www.paladion.net

2. 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?
3
Application Vulnerabilities Exceed OS
Vulnerabilities
During 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/

4. 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. Tools are simplifying the attacks
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

6. Most applications tend to be insecure at
first
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

7. A few common security flaws
7
1. Weak input validation
2. Relying on client-side validation
3. Use of dynamic SQL queries
4. Not escaping <, and > characters
5. Incorrect cache control directives
6. Un-patched servers
7. Weak session management
8. Weak encryption
9. Wrong specs of expected input
10. Misunderstanding of end-user environment

8. Threat Intelligence Report - 2011
 XSS,
Authentication &
Session Mgmnt
and
Misconfiguration
vulnerabilities
contributes to
more than 50%
 Injection
vulnerabilities are
showing a
downward trent

9. 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

10. Mobile Application security risks*
 Insecure Data Storage More resources at:
 Weak Server side validations & http://www.paladion.net/paladion
Controls labs.html
 Insufficient Transport Layer Protection • Mobile Code Scanner for
 Client Side Injections Android
 Poor Authorization and Authentication • “InsecureBank” test
 Improper Session Handling application for Android
 Security Decisions via un-trusted Plynt Certification Criteria for
inputs Mobile Applications
 Side Channel Data Leakage http://www.plynt.com/criteria/mo
bile-application-criteria/
 Broken Cryptography
 SensitiveTop 10
* OWASP Information Disclosure

11. 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
12
 High rate of false positives
 They cannot detect business logic risks
 Directly impact business
 More difficult to find

13. E.g. Business logic risks
13
 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

14. The 80/20 Approach

15. Goals of application security
Program
15
1. Find all holes in existing applications
2. Fix them quickly
3. Avoid errors in new code
4. Be resilient to the latest attacks

16. Two phase approach
16
1. Risk based enterprise testing program
1. Risk profile based testing schedules
2. Mix of manual & automated testing
2. Build long term capability

17. Risk based enterprise testing
program

18. Basic characteristics
1. Different levels of testing
2. Framework for classifying apps
3. Baseline standard checklist
4. Automated workflow & online reporting
18

19. 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

20. Different levels of testing
Application with Plain
information & Low value
transaction
Black Box Testing
Application with User
Access &supporting critical
Penetration Test (Gray business functions
Box Testing)
Application supporting
highly critical process
Source code reviews
(White Box Testing)
20

21. Different levels of testing
Application Type Test Type Frequency
Penetration Tests (Gray Quarterly
Box)
High critical applications
Code Reviews Annually
Medium critical Penetration Tests (Gray Half yearly
applications Box)
Less critical applications Penetration Tests (Gray Annually
Box)
21

22. 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
22

23. The criteria in the framework
 Is the data sensitive?
 Is the application critical?
 How connected is the application?
23

24. 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

25. Automated Workflow
25

26. Dashboard Reporting
26

27. Application Penetration Tests

28. Methodology
28

29. Step 1: Study the Application
29
 Features, functions
 Walk through site
 Read the manuals
 Interviews, questionnaires
 Make sense of the modules

30. Step 2: Create Threat Profile
30
 Threat  Goal of the Adversary
 Threat Profile  List of All Threats
 An adversary…
 Siphons off funds
 Reset passwords of other users
 Views account statement of others

31. Creating the threat profile
31
 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
32
 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
33
 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
34
 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
35

36. Executing Test Cases
36
 Mix of manual and automated techniques
• Manual Testing • Automated Testing
• Business logic flaws • Injection attacks
• Privilege escalation • Cross site scripting

37. Publish the Report
37
 Executive Summary
 Strengths
 Weaknesses
 Detailed Findings
 Solutions and fixes
 Compliance to standards
 Central
Bank Guidelines
 PCI-DSS

38. Code Reviews

39. Benefits of Code Review
39
 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
40
 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
41
Preparation
Study Application
1
Create Threat Profile
2
Analysis
Study Code Layout
3
Code Review Plan
4
Analyze Code
5
Solutions
STRUCTURED METHODOLOGY
Verify Flaws
→ THREAT-PROFILE BASED APPROACH TO FOCUS ON WHAT’S 6
IMPORTANT
Generate Report
7
→ HYBRID OF MANUAL AND AUTOMATIC VERIFICATION
→ CUSTOM SCRIPTS TAILORED FOR EACH APPLICATION

42. Step 3, 4: Code Layout and Plan
42
 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
43
 Step: Analyze the code
 Dissect Pages, Classes, Settings
 Consult Reference checklist
 Combination of manual and scripted
techniques
 Step 6: Verify the flaws
 Verifyexploitation through walk through
 Take screen shots of code snippets
 Ensure the snippets tell the story

44. Step 7: Publish the Report
44
 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

45. Build Long Term Capability

46. Integrate Security in SDLC
 Traditional Methodology
Architecture Code Security Test
Threat Automated
Review cases
Modeling scanning Scan
SRS Security Security Coding Code Pen test
Checklist features Guidelines Review Hardening
SRS Design Development Testing Deployment
Security Define Vulnerability
Evaluate against
Specifications Training secure Assessment
Threat model
for 3rd party build

47. Integrate security in SDLC – 80/20
47
 Avoid errors in new code
 Train developers, designers
 Define application security standard/best practices
 Measure Effectiveness

48. Build long term capability with
Training
48
 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
49
 Define Standards for Developers & Designers
 Secure Coding Standards for Developers
 Secure Architecture Framework for Designers

50. Application Security Standard
50
 40 – 60 standards
 75% mandatory, 25% optional
 Critical apps to meet all standards
 Less critical ones need to meet only mandatory
controls

51. Examples
51
 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
52
 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

53. Thank You
sales@paladion.net