Successfully reported this slideshow.
APPLICATION SECURITY TRENDS – LESSONS                               LEARNT         Firosh C Ummer, Technical Director, Pal...
Contents   Challenges in Enterprise Application Security    Programs   Risk Based Application Security Program   Threat...
Why Application Security testing?3                                         Application Vulnerabilities Exceed OS          ...
Threat Intelligence Report - 2011                              >50% of attacks are                               targeted...
Tools are simplifying the attacks5       Automated techniques are improving           600,000 websites compromised in 2 ...
Most applications tend to be insecure atfirst6       It’s easy to make security errors       Few developers are trained ...
A few common security flaws7    1.    Weak input validation    2.    Relying on client-side validation    3.    Use of dyn...
Threat Intelligence Report - 2011                            XSS,                             Authentication &           ...
Mobile Applications   On account of the variety in the mobile    space, each OS is an altogether different    thing in it...
Mobile Application security risks*   Insecure Data Storage                     More resources at:   Weak Server side val...
Challenges    Budgets are limited    Limited internal expertise    Standard pen tests take more time    Tools alone ar...
Tools alone are not sufficient12        High rate of false positives        They cannot detect business logic risks     ...
E.g. Business logic risks13        An adversary can…            submit deposit requests on behalf of other users        ...
The 80/20 Approach
Goals of application securityProgram15     1.   Find all holes in existing applications     2.   Fix them quickly     3.  ...
Two phase approach16     1.   Risk based enterprise testing program          1.   Risk profile based testing schedules    ...
Risk based enterprise testingprogram
Basic characteristics 1.   Different levels of testing 2.   Framework for classifying apps 3.   Baseline standard checklis...
Different levels of testing   All apps would not undergo the same level of    testing       Some apps will get a full te...
Different levels of testing                                Application with Plain                              information...
Different levels of testingApplication Type             Test Type                 Frequency                             Pe...
Framework to classifyapps   A risk assessment framework to prioritize apps       Prioritizing helps share the limited bu...
The criteria in the framework   Is the data sensitive?   Is the application critical?   How connected is the applicatio...
Baseline standard for the securitytests   A minimum set of checks for all apps       Does it do input validations at the...
Automated Workflow                     25
Dashboard Reporting26
Application Penetration Tests
Methodology28
Step 1: Study the Application29        Features, functions        Walk through site        Read the manuals        Int...
Step 2: Create Threat Profile30        Threat  Goal of the Adversary        Threat Profile  List of All Threats       ...
Creating the threat profile31      Structured process to create Threat Profile      Select known threats from available ...
Sample Threat Profile for Internet     Banking32        An adversary…          Siphons  off funds from one account      ...
Threat profile repository33      Structured process to create Threat Profile      Select known threats from Paladion    ...
Sample Test Plan for 1 Threat in     Internet Banking34        Views account statement of other users          SQL  Inje...
Test Plan35
Executing Test Cases36        Mix of manual and automated techniques     • Manual Testing              • Automated Testin...
Publish the Report37        Executive Summary          Strengths          Weaknesses        Detailed Findings        ...
Code Reviews
Benefits of Code Review39        More exhaustive than Penetration Tests            Finds all instances of SQL Injection,...
Methodology40        7-step structured methodology          Threat-profile   based approach to focus on what’s          ...
The 7-step Code Review      Methodology41 Preparation            Study Application       1           Create Threat Profile...
Step 3, 4: Code Layout and Plan42        Step 3: Study Code Layout            Get familiar with Pages, Forms, Classes   ...
Step 5, 6: Analyze and Verify43        Step: Analyze the code          Dissect Pages, Classes, Settings          Consul...
Step 7: Publish the Report44        Executive Summary            Strengths            Weaknesses        Detailed Findi...
Build Long Term Capability
Integrate Security in SDLC    Traditional Methodology                           Architecture Code       Security Test    ...
Integrate security in SDLC – 80/2047        Avoid errors in new code            Train developers, designers            ...
Build long term capability with     Training48        Training for Developers, Designers and QA        New code gets saf...
Standardize49        Define Standards for Developers & Designers            Secure Coding Standards for Developers      ...
Application Security Standard50        40 – 60 standards          75%    mandatory, 25% optional          Critical   ap...
Examples51        Mandatory          The   application must…            Insist                  that the user changes p...
Measure effectiveness52        Institute reviews to measure progress            Architecture reviews of new apps        ...
Thank You            sales@paladion.net
Upcoming SlideShare
Loading in …5
×

Application Security TRENDS – Lessons Learnt- Firosh Ummer

809 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Application Security TRENDS – Lessons Learnt- Firosh Ummer

  1. 1. APPLICATION SECURITY TRENDS – LESSONS LEARNT Firosh C Ummer, Technical Director, Paladion Networks www.paladion.net
  2. 2. Contents Challenges in Enterprise Application Security Programs Risk Based Application Security Program Threat Modeling in Application Testing Security Code Review Process
  3. 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. 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. 5. Tools are simplifying the attacks5  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. 6. Most applications tend to be insecure atfirst6  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. 7. A few common security flaws7 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. 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. 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. 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. 11. Challenges  Budgets are limited  Limited internal expertise  Standard pen tests take more time  Tools alone are not sufficient 11
  12. 12. Tools alone are not sufficient12  High rate of false positives  They cannot detect business logic risks  Directly impact business  More difficult to find
  13. 13. E.g. Business logic risks13  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. 14. The 80/20 Approach
  15. 15. Goals of application securityProgram15 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. 16. 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
  17. 17. Risk based enterprise testingprogram
  18. 18. Basic characteristics 1. Different levels of testing 2. Framework for classifying apps 3. Baseline standard checklist 4. Automated workflow & online reporting 18
  19. 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. 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. 21. Different levels of testingApplication Type Test Type Frequency Penetration Tests (Gray Quarterly Box)High critical applications Code Reviews AnnuallyMedium critical Penetration Tests (Gray Half yearlyapplications Box)Less critical applications Penetration Tests (Gray Annually Box) 21
  22. 22. Framework to classifyapps 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. 23. The criteria in the framework Is the data sensitive? Is the application critical? How connected is the application? 23
  24. 24. Baseline standard for the securitytests 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. 25. Automated Workflow 25
  26. 26. Dashboard Reporting26
  27. 27. Application Penetration Tests
  28. 28. Methodology28
  29. 29. Step 1: Study the Application29  Features, functions  Walk through site  Read the manuals  Interviews, questionnaires  Make sense of the modules
  30. 30. Step 2: Create Threat Profile30  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. 31. Creating the threat profile31  Structured process to create Threat Profile  Select known threats from available Repository  Brainstorm on additional risks  Consult business to verify Threat Profile
  32. 32. Sample Threat Profile for Internet Banking32  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. 33. Threat profile repository33  Structured process to create Threat Profile  Select known threats from Paladion Repository  Brainstorm on additional risks  Consult customer to verify Threat Profile
  34. 34. Sample Test Plan for 1 Threat in Internet Banking34  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. 35. Test Plan35
  36. 36. Executing Test Cases36  Mix of manual and automated techniques • Manual Testing • Automated Testing • Business logic flaws • Injection attacks • Privilege escalation • Cross site scripting
  37. 37. Publish the Report37  Executive Summary  Strengths  Weaknesses  Detailed Findings  Solutions and fixes  Compliance to standards  Central Bank Guidelines  PCI-DSS
  38. 38. Code Reviews
  39. 39. Benefits of Code Review39  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. 40. Methodology40  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. 41. The 7-step Code Review Methodology41 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. 42. Step 3, 4: Code Layout and Plan42  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. 43. Step 5, 6: Analyze and Verify43  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. 44. Step 7: Publish the Report44  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. 45. Build Long Term Capability
  46. 46. Integrate Security in SDLC Traditional Methodology Architecture Code Security Test Threat Automated Review cases Modeling scanning ScanSRS Security Security Coding Code Pen testChecklist 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. 47. Integrate security in SDLC – 80/2047  Avoid errors in new code  Train developers, designers  Define application security standard/best practices  Measure Effectiveness
  48. 48. Build long term capability with Training48  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. 49. Standardize49  Define Standards for Developers & Designers  Secure Coding Standards for Developers  Secure Architecture Framework for Designers
  50. 50. Application Security Standard50  40 – 60 standards  75% mandatory, 25% optional  Critical apps to meet all standards  Less critical ones need to meet only mandatory controls
  51. 51. Examples51  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. 52. Measure effectiveness52  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. 53. Thank You sales@paladion.net

×