Your SlideShare is downloading. ×
Application Security TRENDS – Lessons Learnt- Firosh Ummer
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Application Security TRENDS – Lessons Learnt- Firosh Ummer


Published on

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • 260 customer – 14000 assets in 2011
  • Samy – XSS attack through social networking site30,000 desktops were wiped off, CEO’s passwords and core router name & passwords are posted on the website. Shamoon.
  • Critical data (user name and pwd is being stored) in logs and memory devices.Same as webappsec – server side validation etcUnencrypted data being sent out.Client Side Injections: Using device identifier for authenticationSession id are longer, stored in cookiessdaData being logged in logs, temp directories – 3rd party librariesEncording, obfuscation being used
  • Transcript

    • 1. APPLICATION SECURITY TRENDS – LESSONS LEARNT Firosh C Ummer, Technical Director, Paladion Networks
    • 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.
    • 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: html
    • 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. 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. 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. 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 & 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 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 sufficient12  High rate of false positives  They cannot detect business logic risks  Directly impact business  More difficult to find
    • 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. The 80/20 Approach
    • 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. 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. Risk based enterprise testingprogram
    • 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 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. 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. The criteria in the framework Is the data sensitive? Is the application critical? How connected is the application? 23
    • 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. Automated Workflow 25
    • 26. Dashboard Reporting26
    • 27. Application Penetration Tests
    • 28. Methodology28
    • 29. Step 1: Study the Application29  Features, functions  Walk through site  Read the manuals  Interviews, questionnaires  Make sense of the modules
    • 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. 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. 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. 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. 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. Test Plan35
    • 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. Publish the Report37  Executive Summary  Strengths  Weaknesses  Detailed Findings  Solutions and fixes  Compliance to standards  Central Bank Guidelines  PCI-DSS
    • 38. Code Reviews
    • 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. 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. 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. 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. 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. 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. Build Long Term Capability
    • 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. Integrate security in SDLC – 80/2047  Avoid errors in new code  Train developers, designers  Define application security standard/best practices  Measure Effectiveness
    • 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. Standardize49  Define Standards for Developers & Designers  Secure Coding Standards for Developers  Secure Architecture Framework for Designers
    • 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. 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. 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. Thank You