Embed within SDLC Module (to be combined) OWASP Education Project Copyright 2007 © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation http://www.owasp.org Introduction OWASP 2 People / Processes / Technology Training Awareness Guidelines Automated Testing Secure Development Application Firewalls Secure Code Review Secure Configuration Security Testing OWASP 3 A Few Facts and figures Interesting Statistics – Employing code review IBM Reduces 82% of Defects Before Testing Starts HP Found 80% of Defects Found Were Not Likely To Be Caught in Testing 100 Times More Expensive to Fix Security Bug at Production Than Design” – IBM Systems Sciences Institute Promoting People Looking at Code Improvement Earlier in SDLC Fix at Right Place; the Source Takes 20% extra time – payoff is order of magnitude more. Ref: http://ganssle.com/Inspections.pdf OWASP 4 People Awareness and Education OWASP 5 Get Buy In! Management support crucial Talk Business: Create Value Controll Risk Create CxO elevator pitches OWASP 6 Web Application Security SDLC Elevator Pitch Between 70% and 90% of web applications have serious vulnerabilities because …the average developer is still not trained well enough. … of the way they came to be. Embedding application security controls into development and deployment will Allow for higher uptime, less TCO Put YOU into risk control OWASP 7 Developer and administrator training Give a man a fish and you feed him for a day; Teach a man to fish and you feed him for a lifetime. Chinese proverb Organize Developer Workshops Not only preach, but provide guidelines tuned to the environment and tools to empower the developers and administrators OWASP 8 Security Requirements and Abuse Cases OWASP 9 Security Requirements Security aspects must be part of the requirements The ‘business’ should be informed of certain risks Solid base for next application security controls Define Security Requirements Standards Which controls are necessary When are they necessary (applicability) Why are they necessary (e.g. SEC, SOX, etc.) Easy to use reference for requirements teams Standard method to implement each control Provide reference on how to implement OWASP 10 Application Security Requirements Tailoring Get the security requirements and policy right Generic set of security requirements Must include all security mechanisms Must address all common vulnerabilities Can be use (or misuse) cases Address all driving requirements (regulation, standards, best practices, etc.) Tailoring examples… Specify how authentication will work Detail the access control matrix (roles, assets, functions, permissions) Define the input validation rules Choose error handling logging approach OWASP 11 Abuse Cases Source: Templates for Misuse Case Description, Sindre & Opdahl OWASP 12 Negative Scenarios are Not New Montignac Caves, Dordogne, France 'Suppose it turns and charges us before it falls into the pit' OWASP 13 Misuse Cases threatens Drive the Car Steal the Car Car Thief Guttorm Sindre and Andreas Opdahl, 2000 Actor is a Hostile Agent Bubble is drawn in inverted colours Goal is a Threat to 'Our System‘ Input for Threat Modelling OWASP 14 Threat Modeling OWASP 15 Why Understand the operating environment your application is heading into Identify, analyze and document (and thus hopefully mitigate) threats OWASP 16 Overview assets input/output exposure (internal, external, distributed, centralized..) threat types (patterns) impact (who, how, why) OWASP 17 Identifying threats – data flow diagrams dfd, level0 contains the major processes, system boundaries .. interactions with external entities OWASP 18 Categorizing and Quantifying Threats Most known: Microsoft stride, dread spoofing, tampering, repudiation, information disclosure, denial of service, escalation of privileges damage potential, reproducibility, exploitability, affected users, discoverability Most important thing is that used models assist in understanding and communicating OWASP 19 Threat Modeling Select mitigation strategy and techniques based on identified, documented and rated threats. Benefits: Prevent security design flaws Identify & address greatest risks Increased risk awareness and understanding Mechanism for reaching consensus Cost justification and support for needed controls Means for communicating results OWASP 20 Success Factors Obtain management support Involve Business and Technical experts Designate focal points Define procedures Document and maintain result OWASP 21 Resources http://www.octotrike.org Threat modeling book - swiderski, snyder http://blogs.msdn.com/threatmodeling/ OWASP 22 Secure Design Guidelines OWASP 23 Secure Design Principles (*) Secure the weakest link Practice defence in depth Fail securely Follow the principle of least privilege Compartmentalize Keep it simple Promote privacy Remember that hiding secrets is hard Be reluctant to trust Use your community resources Future proof security design! (*) Building Secure Software, Viega-McGraw OWASP 24 Security Principles Minimize attack surface area Establish secure defaults Principle of Least privilege Principle of Defense in depth Fail securely Don't trust services Separation of duties Avoid security by obscurity Keep security simple Fix security issues correctly OWASP 25 Design Reviews Better to find flaws early Security design reviews Check to ensure design meets requirements Also check to make sure you didn’t miss a requirement Assemble a team Experts in the technology Security-minded team members Do a high-level penetration test against the design Be sure to do root cause analysis on any flaws identified OWASP 26 Secure Coding Guidelines and Security Code Review OWASP 27 Secure Coding Guideline Formalize best practices into secure coding guidelines well documented and enforceable coding standards Tune towards environment OWASP Secure Coding Guide can be reference can be used as a metric to evaluate source code OWASP 28 Code Review Security bugs subset of implementation bugs! Static / dynamic analysis tools Requires manual inspection Threat-based Check list driven Benefits: Improves code quality Prevents security bugs Increased developer awareness and understanding OWASP 29 Testing for web application security OWASP 30 Software Vulnerability Analysis Find flaws in the code early Many different techniques Static (against source or compiled code) Security focused static analysis tools Peer review process Formal security code review Dynamic (against running code) Scanning Penetration testing Goal Ensure completeness (across all vulnerability areas) Ensure accuracy (minimize false alarms) OWASP 31 Application Security Testing Identify security flaws during testing Develop security test cases Based on requirements Be sure to include “negative” tests Test all security mechanisms and common vulnerabilities Flaws feed into defect tracking and root cause analysis OWASP 32 The OWASP Testing Guide Part of an appsec body of knowledge… Testing Principles Testing Process Custom Web Applications Black Box Testing Grey Box Testing Risk and Reporting Appendix: Testing Tools Appendix: Fuzz Vectors Information Gathering Business Logic Testing Authentication Testing Session Management Testing Data Validation Testing Denial of Service Testing Web Services Testing Ajax Testing OWASP 33 Secure administration and Security within Change Management OWASP 34 Deployment Process Ensure the application configuration is secure Security is increasingly “data-driven” XML files, property files, scripts, databases, directories How do you control and audit this data? Design configuration data for audit Put all configuration data in CM Audit configuration data regularly Don’t allow configuration changes in the field Gap Development - Deployment OWASP 35 Application Security Defect Tracking and Metrics “Every security flaw is a process problem” Tracking security defects Find the source of the problem Bad or missed requirement, design flaw, poor implementation, etc… ISSUE: can you track security defects the same way as other defects Metrics What lifecycle stage are most flaws originating in? What security mechanisms are we having trouble implementing? What security vulnerabilities are we having trouble avoiding? OWASP 36 Deployment WebAppSec Controls OWASP 37 Software security tollgates in the SDLC Iterative approach Security requirements Design Review Risk analysis Requirements and use cases Design Risk-based security tests Test plans Code Review Static analysis (tools) Code Penetration testing Test results Field feedback OWASP 38 WebAppSec Tools OWASP 39 Tools •Test sites / testing grounds •HTTP proxying / editing •XSS cheat sheet tools •webapp fuzzing •Encoding tools •HTTP general testing HTTP fingerprinting •Browser-based HTTP tampering / editing / replaying •Cookie editing / poisoning •Ajax and XHR scanning •RSS extensions and caching •SQL injection scanning •Threat modeling •FireFox Add-Ons •Bookmarklets •SSL certificate checking / scanning •Honeyclients, Web Application, and Web Proxy honeypots •Footprinting •Web application security malware, backdoors, and evil code •Web application assessment services •Browser-based security fuzzing / checking •PHP static analysis and file inclusion scanning •Web Application Firewall (WAF) and Intrusion Detection (APIDS) rules and resources •Web services enumeration / scanning / fuzzing •Web application non-specific static sourcecode analysis •Static analysis for C/C++ (CGI, ISAPI, etc) in web applications •Java static analysis, security frameworks, and web application security tools •Microsoft .NET static analysis and security framework tools, •Database security assessment •Browser Defenses •Browser Privacy 40 OWASP •Application and protocol fuzzing Tools http://www.owasp.org/index.php/Phoenix/Tools Best known OWASP Tools WebGoat WebScarab Remember: A Fool with a Tool is still a Fool OWASP 41 Tools – At Best 45% MITRE found that all application security tool vendors’ claims put together cover only 45% of the known vulnerability types (over 600 in CWE) They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true) OWASP 42 Technology Do not develop on islands, but look for organisation wide: Framework Architectures J2EE, .NET Security Patterns Leverage PKI, IAM initiatives Vulnerability Scanners Application level firewalls OWASP 43 Starting and improving an SDLC OWASP 44 Opportunities for Metrics - Secure Development Life Cycle (SDL) Were software assurance activities conducted at each lifecycle phase? Secure questions during interviews Concept Security push/audit Threat analysis Learn & Refine External review Designs Complete Team member training Security Review Test plans Complete Data mutation & Least Priv Tests Source: Microsoft Code Complete Deploy Review old defects Check-ins checked Secure coding guidelines Use tools Post Deployment = on-going OWASP 45 How to Start? No Big Bang approach Trigger can be (bad) result of Web App Pen Test Assure Management buy-in: First business case! Then Bootstrap! OWASP 46 Business Case For use throughout the lifecycle and the entire software portfolio: Contracting Phase Development Phase Deployment/Production Phase Audit Phase Benefits: Cost savings Risk measurement and reduction Compliance reporting OWASP 47 Cost Savings Significantly reduce the costs associated with new and deployed products : A flaw that costs $1 to fix in the design and development phase will cost $100 to correct once it is deployed Reduce development time and number of cycles Patch management costs Contractor and vendor costs “Removing only 50 percent of software vulnerabilities before use will reduce patch management and incident response costs by 75 percent.” (John Pescatore, Gartner) OWASP 48 Risk measurement and reduction Eliminate vulnerabilities before they become liabilities Manage the risks of serious financial loss, negative publicity, legal liability, loss of contracts, erosion of market share, degraded performance or other serious business impact as a result of a failure in security Set, enforce and report that software assurance thresholds are maintained Measurable reports prove progress internally and for compliance OWASP 49 Compliance Reporting Compliance reporting: Comply with legal and regulatory requirements Regularly assess risk, disclose vulnerabilities and weaknesses, and prove progress both internally and for compliance requirements Scope & application Risk assessments are mandatory for most regulations, including application vulnerability detection Example internal control frameworks: CobiT, ISO 17799 Example regulations: Basel II, FISMA (NIST 800-53), DoD 8500.2, Sarbanes-Oxley, FDA, HIPAA … OWASP 50 BootStrap! Identify current way of working! Set goals and start with phased approach Compare this with security strategy (can already be set out in a secure development policy) Perform a gap analysis and proceed with process improvement cycles: Tailor to Company Culture! Driven by Risk Management! Introduce Metrics OWASP 51 Examples of Application Security Metrics Process Metrics Is a SDL Process used? Are security gates enforced? Secure application development standards and testing criteria? Security status of a new application at delivery (e.g., % compliance with organizational security standards and application system requirements). Existence of developer support website (FAQ's, Code Fixes, lessons learned, etc.)? % of developers trained, using organizational security best practice technology, architecture and processes Management Metrics % of applications rated “business-critical” that have been tested. % of applications which business partners, clients, regulators require be “certified”. Average time to correct vulnerabilities (trending). % of flaws by lifecycle phase. % of applications using centralized security services. Business impact of critical security incidents. OWASP 52 Examples of Application Security Metrics Vulnerability Metrics Number and criticality of vulnerabilities found. Most commonly found vulnerabilities. Reported defect rates based on security testing (per developer/team, per application) Root cause of “Vulnerability Recidivism”. % of code that is re-used from other products/projects* % of code that is third party (e.g., libraries)* Results of source code analysis**: Vulnerability severity by project, by organization Vulnerabilities by category by project, by organization Vulnerability +/- over time by project % of flaws by lifecycle phase (based on when testing occurs) Source: * WebMethods, ** Fortify Software OWASP 53 Web Application Security Roles and Responsibilities OWASP 54 Get involved Security Analyst: Get involved early in SDLC. Security is a function of the asset we want to secure, what's it worth? Understanding the information held in the application and the types of users is half the battle. Involve an analyst in the design phase and thereafter. Developer: Embrace secure application development. (Educate) Quality is not just “Does it work” Security is a measure of quality also. OWASP 55 Get involved QA: Security vulnerabilities are to be considered bugs, the same way as a functional bug, and tracked in the same manner. Managers: Factor some time into the project plan for security. Consider security as added value in an application. – $1 spent up front saves $10 during development and $100 after release OWASP 56 Roles Role of security architect (cross-development projects): ensure security goals are reached during all cycles of the development process create awareness within development teams, business bridge function to "IT Security" mentor the security engineers and project leaders Role of security engineer (part of project team) SPOC within development team for all security related matters. Search for Champions! OWASP 57 Round up OWASP 58 Where to start? Awareness and Training 2-hour course: $100-200/seat Seeing the look on the IT VPs’ faces when they get SQL Injection: Priceless Policies and Standards Application Assessments and Reviews Get some data Strive to be consistent and uniform Support Development Teams OWASP 59
© Copyright 2024