Application Security TRENDS – Lessons Learnt- Firosh Ummer
Download as PPTX, PDF0 likes1,125 views
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.
Application Security TRENDS – Lessons Learnt- Firosh Ummer
- 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
- 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
- 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
Editor's Notes
- #5: 260 customer – 14000 assets in 2011
- #6: 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.
- #11: 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