Hide Notes 

Slide 1: Software Security Engineering and Risk Management Processes to Build Secure Web Applications Marco Morana OWASP Chapter Lead Rochester Security Summit 29-30 October 2008 OWASP Cincinnati Chapter Meetings Copyright 2008 © 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
Slide 2: Agenda 1. 2. 3. 4. Software Security Awareness: Business Cases Approaches To Application Security Software Security Roadmap (CMM, S-SDLCs) Software Security Activities And Artifacts       Security Requirements and Abuse Cases Threat Modeling Secure Design Guidelines Secure Coding Standards and Reviews Security Tests Secure Configuration and Deployment 5. Metrics and Measurements 6. Business Cases OWASP 2
Slide 3: Software Security Awareness Business Cases OWASP 3
Slide 4: Initial Business Cases For Software Security Avoid Mis-Information: Fear Uncertainty Doubt (FUD) Use Business Cases: Costs, Threat Reports, Root Causes OWASP 4
Slide 5: Business Case #1: Costs “Removing only 50 percent of software vulnerabilities before use will reduce defect management and incident response costs by 75 percent.” (Gartner) The average cost of a security bulletin is 100,000 $ (M. Howard and D. LeBlanc in Writing Secure Software book) It is 100 Times More Expensive to Fix Security Bug at Production Than Design” (IBM Systems Sciences Institute) OWASP 5
Slide 6: Business Case #2: Threats To Web Applications 93.8% of all phishing attacks in 2007 are targeting financial institutions (Anti-Phishing Group) Phishing attacks soar in 2007 (Gartner) 3.6 Million victims, $ 3.2 Billion Loss (2007) 2.3 Million victims, $ 0.5 Billion Loss (2006) Phishing attacks exploit web application vulnerabilities (OWASP T10) A1(XSS) weak authentication authorization vulnerabilities (A1, A4, A7, A10) OWASP 6
Slide 7: Business Case #3: Application Security Root Causes Application vulnerabilities issues: 92 % of reported vulnerabilities are in applications not in networks (NIST) Security design flaws issues: “Security design flaws account 70% of the defects being analyzed 47% of design flaws have medium and high business impact and easily exploitable” (@Stake) OWASP 7
Slide 8: Approaches To Application Security OWASP 8
Slide 9: The “Know But Ignore” Approach: Do Not Act OWASP 9
Slide 10: The Reactive Approach: Act After The Fact 5 Go Fix Security Bugs! ? ? OWASP 10
Slide 11: Tactical View: Finding Vulnerabilities Manual Penetration Testing Manual Code Review Automated Vulnerability Scanning Automated Static Code Analysis OWASP 11
Slide 12: Strategic View: Manage Software Risks OWASP 12
Slide 13: Holistic View: Software vs. Application Security Security built into each phase of the SDLC Look at root problem causes Proactive, Threat Modeling, Secure Code Reviews Security applied by catch and patches Look at external symptoms Reactive, Incident Response, Compliance OWASP 13
Slide 14: Software Security Roadmap OWASP 14
Slide 15: Software Security Roadmap 1. Assess the maturity of the organization software security development processes, people and tools 2. Define the software security process: security enhanced SDLCs, frameworks and checkpoints 3. Implement software security activities 1. 2. 3. 4. 5. Security Requirements Secure Design and Threat Modeling Secure Coding Guidelines and Security Code Review Security Testing Secure Deployment 4. Collect metrics and measurements 5. Create business cases and set objectives OWASP 15
Slide 16: Software Security Initiative: Maturity Levels OWASP 16
Slide 17: Software Security Initiative: Maturity Levels  Maturity Innocence (CMM 0-1) No formal security requirements Issues addressed with penetration testing and incidents Penetrate and patch and reactive approach  Maturity Awareness (CMM 2-3) All applications have penetration tests done before going into production Secure coding standards are adopted as well as source code reviews  Maturity Enlightenment (CCM 4-5) Threat analysis in each phase of the SDLC Risk metrics and vulnerability measurements are used 17 for security activity decision making OWASP
Slide 18: Security-enhanced lifecycle process (S-SDLC) models: MS-SDL, Cigital TP and CLASP OWASP 18
Slide 19: Building Security In the Waterfall SDLC Secure Requirements Threat Modeling Secure Code Reviews Security Testing OWASP 19
Slide 20: Build Security in Agile SDLC Application Security Assurance Review { Threat Model Stakeholder Security Stories Periodic Security Sprints OWASP 20 20
Slide 21: Security Requirements and Abuse Cases OWASP 21
Slide 22: Security Requirements Encompasses both functional requirements for security controls and risk mitigation driven requirements from the abuse case scenarios Define Security Requirements in Standards Which controls are required (e.g. authentication, authorization, encryption etc) Where should be implemented (e.g. design, source code, application, server) Why are required  Compliance and auditing (e.g. FFIEC, PCI, SOX etc.)  Mitigation for known threats (e.g. STRIDE) How should be implemented and tested OWASP 22
Slide 23: Functional and Non Functional Requirements Functional Requirements: Define the expected functionality of security controls Depends on the applicable standards, policies and regulations Positive statements  “the application will lockout the user after 6 failed logon attempts”  “passwords need to be 6 min characters, alphanumeric” Risk Driven Security Requirements Address all common vulnerabilities Can be derived by use (or misuse) cases Negative statements  The application should not allow of the data being altered or destroyed  The application should not be compromised or misused for unauthorized financial transaction by a malicious user. OWASP 23
Slide 24: Security Requirements Derivation Through Use and Misuse Cases Enter Username and password Includes User User Authentication Includes Threatens Brure Force Authentication Includes Show Generic Error Message Includes Mitigates Harverst (e.g. guess) Valid User Accounts Mitigates Includes Application/Server Validate Password Minimum Length and Complexity Includes Mitigates Dictionary Attack Mitigates Hacker/Malicious User Lock Account After N. Failed Login Attempts Source: OWASP Testing Guide Vs 3 Introduction OWASP 24
Slide 25: Threat Modeling OWASP 25
Slide 26: Threat Modeling  Categorizes the threats to the application, highlights potential vulnerabilities and identifies countermeasures to be developed  Use a systematic fact based and methodical approach: 1. Scope Assessment 1. System Modeling Requirements, Use Cases Physical and Logical View, Data Flows, Trust Boundaries, Entry Points STRIDE, ASF 1. Threat Identification 1. Threat Vulnerabilities and Attacks Security Controls Risk Modeling Checklists, Attack Vulnerability Mapping 1. Identification of Countermeasures 1. Threat Prioritization and Risk Ranking OWASP 26
Slide 27: System Modeling: Data Flow Diagrams HTTP/HTTPS over public internet , form logins Anonymous Apache 2.0.54 on OpenBSD 3.7 with mod_lisp and CMUCL PostgreSQL 8.0.3 on OpenBSD 3.7 Database ODBC over SSL on switched 100 bT, user/pass login Machine Boundary Flat text file on OpenBSD 3.7 User Web Server Administrator Firewall Local Filesystem Logs Source: Threat Modeling Dr James Walden OWASP 27
Slide 28: Threats and Countermeasures Identification Source: OWASP TM OWASP 28
Slide 29: Threat Modeling in the SDLC Threat Modeling in the SDLC Definition Definition Use and Abuse Cases Secure Requirements Engineering Security Requirements Design Design Secure Architecture Modeling Data Flow Diagrams Threat Modeling Attack Trees Development Development Secure Coding Standards Secure Code Reviews Security Unit Testing Security Testing Guidelines (Unit Tests) Testing Testing Security Testing Guidelines (System Tests) Security Integrated Testing Vulnerability Assessments (User Acceptance Test) Deployment Deployment Vulnerability Assessments (Production) Secure Configuration & Installation OWASP 29
Slide 30: Secure Design Guidelines OWASP 30
Slide 31: Security Design Reviews Objective is promote secure design and identify of potential flaws before construction phase Secure Architecture Review Process Review High Level Design documents and verify that security controls requirements are documented Engage with:  Architects  Application Security Experts Provide guidance on security technology/design patterns Identify potential gaps in security controls with threat modeling OWASP 31
Slide 32: Secure Coding Standards and Secure Code Reviews OWASP 32
Slide 33: Secure Coding Standards/Guidelines Describe secure coding requirement in terms of: 1. The common vulnerabilities (e.g. OWASP T10) 2. The issue type (e.g. Application Security Frame) 3. The security threat or how can be exploited 4. The in-secure code root cause of the vulnerability 5. The “How to” find the vulnerability with black box and white box testing 6. The secure coding requirement/recommendation 7. The risk rating (e.g. STRIDE/DREAD, OWASP) OWASP 33
Slide 34: Example SQL Injection - Secure coding requirements Use SQL parameterized queries, avoid dynamic SQL generation:  SELECT * FROM users WHERE username=?  JAVA EE use strongly typed “PreparedStatement”  in .NET use “SqlCommand” with “SqlParameters” Sanitize input, remove special characters: ' " ` ; * % _ =&\|*?~<>^()[]{}$\n\r Use custom error messages:  No SQL exception information in error messages OWASP 34
Slide 35: Secure Code Reviews  Objectives:  Identification of security issues in source code, the type of the issue, the severity and recommendation on how should be fixed  Can be used to validate secure coding standards  Security assessment before releasing to QA and production  Methodologies:  Automated Focused Source Code Analysis  Focus is on validation of false positives and auditing of automated scan results  Manually Focused Secure Code Review  Focus is on identification of security issues as bugs vs. flaws by categorizing the issues by type of vulnerability introduced OWASP 35
Slide 36: Source Code Analysis OWASP 36
Slide 37: Security Tests OWASP 37
Slide 38: Security Testing Develop security test cases Positive functional security test cases Negative test cases (from use and misuse cases) Common vulnerabilities exposure Integrate Tests in Developers and Testers Workflows Static and Dynamic Testing, Unit Tests Integrated System Tests and Operational Tests Analyze and report test data Defect Management Root Cause Identification OWASP 38
Slide 39: Security Testing Example: XSS Define Test Case Test login web page for XSS Testing Procedure Type the following strings in input fields  <script>alert()</script>;  javascript:alert()  +ADw-SCRIPT+AD4-alert();+ Pass: Input validation Error is through to the user Fail: an alert dialog box is seen in the browser window. OWASP 39
Slide 40: Testing Tools Categorization and Examples Vulnerability Scanning ISS, Foundscan, Nessus, Nikto Fault Injection Testing (Black Box Testing) Webinspect, Appscan, Hailstorm, Paros, Peach Binary Analysis IDA Pro, @stake SmartRisk Source Code Analysis Fortify, Klockworks, Parasoft, Free Tools (e.g. FindBugs) Threat Modeling MS TAM, TRIKE, PTA Technologies Rootkit BackDoor Analysis ootkits.org and rootkit.nl OWASP 40
Slide 41: Secure Configuration And Deployment OWASP 41
Slide 42: Secure Deployment And Configuration Items Ensure the server configuration is secure Only essential services, server hardening policies Protect Access To Application Files/Data XML files, property files, scripts, databases, directories Enable Auditing And Logging Enable all secure auditing and logging, protect logs Enforce Change Management Controls Don’t allow configuration changes without oversight Audit configuration data Release Securely Don’t allow releases to ship without a security review OWASP 42
Slide 43: Metrics And Measurements OWASP 43
Slide 44: Application Security Defect Tracking and Metrics Define where and how security metrics is collected Tracking security defects throughout the SDLC Report the root causes: requirements, design, code, application Report the type of the issues, the severity and whether has been fixed or no Metrics What lifecycle stage are most flaws originating in? What security mechanisms/controls are we having trouble implementing? What security vulnerabilities are we having trouble fixing? OWASP 44
Slide 45: Examples of Application Security Metrics Process Metrics Management Metrics  Is a SDL is used are security gates enforced?  Is code validated against security standards?  Security posture of a new application before delivery  Security Officers Sign Off?  Test For Security Vulnerabilities Executed?  All high risk issues closed?  Risk assessments completed?  % of developers trained, using organizational security best practice technology, architecture and processes  % of applications rated “business-critical” that have been security tested  % of projects that where developed with the SDL  % of security issues identified by lifecycle phase  % of issues whose risk has been accepted  % of security issues being fixed  Average time to correct vulnerabilities  Business impact of critical security incidents. OWASP 45
Slide 46: Examples of Security Metrics: Trailing MS Bulletins OWASP 46
Slide 47: Security Metrics Goals The Good and The Bad  Good: if goals when are “SMART” that is Specific, Measurable, Attainable, Realistic, Traceable and Appropriate  Example: reducing the overall number of vulnerabilities by 30% by fixing all low hanging fruits with source code analysis during construction  Bad: if the goals justify the means to obtain the goals OWASP 47
Slide 48: Business Case OWASP 48
Slide 49: Business Cases for Your Organization  Tie the metrics to the business cases and support the project stakeholders agendas:  Developer Leads: show that software can be build more securely and efficiently  Project Managers: shows that projects are on schedule and moving on target for the delivery dates and are getting better during tests  Information Security Officers: provides a level of assurance that security standard compliance is addressed through the security review processes within the organization.  Benefits:  Cost savings  Risk measurement and reduction  Compliance reporting OWASP 49
Slide 50: Business Cases And Software Security Strategy  Be realistic on what can be achieved Organization is not yet ready (e.g. mature) Engineers are not trained in software security There are no tools available  Adapt the strategy to reality Build upon your company strenghts Get stakeholders buy in (CIOs, ISOs, PM, Developers, Architects) Set achieveable goals: reduce 30% of vulnerabilities found through ethical hacking via source code analysys  Perform a gap analysis and proceed with process improvement cycles: Tailor to the initiative to the company culture Be risk management driven Introduce metrics and prove results OWASP 50