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 4 IBM Reduces 82% of Defects Before Testing Starts 4 HP Found 80% of Defects Found Were Not Likely To Be Caught in Testing 4100 Times More Expensive to Fix Security Bug at Production Than Design” – IBM Systems Sciences Institute <Promoting People Looking at Code 4 Improvement Earlier in SDLC 4 Fix at Right Place; the Source 4 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: 4 Create Value 4 Controll Risk <Create Cx. O elevator pitches OWASP 6
Web Application Security SDLC Elevator Pitch <Between 70% and 90% of web applications have serious vulnerabilities because 4…the average developer is still not trained well enough. 4… of the way they came to be. <Embedding application security controls into development and deployment will 4 Allow for higher uptime, less TCO 4 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 4 Which controls are necessary 4 When are they necessary (applicability) 4 Why are they necessary (e. g. SEC, SOX, etc. ) § Easy to use reference for requirements teams 4 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 4 Must include all security mechanisms 4 Must address all common vulnerabilities 4 Can be use (or misuse) cases 4 Address all driving requirements (regulation, standards, best practices, etc. ) <Tailoring examples… 4 Specify how authentication will work 4 Detail the access control matrix (roles, assets, functions, permissions) 4 Define the input validation rules OWASP 4 Choose error handling logging approach 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 < 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, level 0 <contains the major processes, system boundaries <. . interactions with external entities OWASP 18
Categorizing and Quantifying Threats <Most known: Microsoft stride, dread 4 spoofing, tampering, repudiation, information disclosure, denial of service, escalation of privileges 4 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: 4 Prevent security design flaws 4 Identify & address greatest risks 4 Increased risk awareness and understanding 4 Mechanism for reaching consensus 4 Cost justification and support for needed controls 4 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 (*) 4 4 4 4 4 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-Mc. Graw 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 4 Check to ensure design meets requirements 4 Also check to make sure you didn’t miss a requirement <Assemble a team 4 Experts in the technology 4 Security-minded team members 4 Do a high-level penetration test against the design 4 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: 4 Improves code quality 4 Prevents security bugs 4 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 4 Static (against source or compiled code) § Security focused static analysis tools § Peer review process § Formal security code review 4 Dynamic (against running code) § Scanning § Penetration testing <Goal 4 Ensure completeness (across all vulnerability areas) 4 Ensure accuracy (minimize false alarms) OWASP 31
Application Security Testing <Identify security flaws during testing <Develop security test cases 4 Based on requirements 4 Be sure to include “negative” tests 4 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” 4 XML files, property files, scripts, databases, directories <How do you control and audit this data? 4 Design configuration data for audit 4 Put all configuration data in CM 4 Audit configuration data regularly 4 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 4 Find the source of the problem § Bad or missed requirement, design flaw, poor implementation, etc… 4 ISSUE: can you track security defects the same way as other defects <Metrics 4 What lifecycle stage are most flaws originating in? 4 What security mechanisms are we having trouble implementing? 4 What security vulnerabilities are we having trouble avoiding? OWASP 36
Deployment Web. App. Sec Controls OWASP 37
Software security tollgates in the SDLC ity x abil Risk reat = Th lner x Vu Security requirements d to e nee test, do w What w o And h Design w tools revie Code Design Review Risk analysis Requirements and use cases t Cos Risk-based security tests Test plans Code Review Static analysis (tools) Code Iterative approach Penetration testing Test results Field feedback OWASP 38
Web. App. Sec 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 • Fire. Fox 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 4 Web. Goat 4 Web. Scarab <Remember: 4 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: 4 Framework Architectures J 2 EE, . NET 4 Security Patterns 4 Leverage PKI, IAM initiatives 4 Vulnerability Scanners 4 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: 4 First business case! 4 Then Bootstrap! OWASP 46
Business Case <For use throughout the lifecycle and the entire software portfolio: 4 Contracting Phase 4 Development Phase 4 Deployment/Production Phase 4 Audit Phase <Benefits: 4 Cost savings 4 Risk measurement and reduction 4 Compliance reporting OWASP 47
Cost Savings <Significantly reduce the costs associated with new and deployed products : 4 A flaw that costs $1 to fix in the design and development phase will cost $100 to correct once it is deployed 4 Reduce development time and number of cycles 4 Patch management costs 4 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: 4 Comply with legal and regulatory requirements 4 Regularly assess risk, disclose vulnerabilities and weaknesses, and prove progress both internally and for compliance requirements < Scope & application 4 Risk assessments are mandatory for most regulations, including application vulnerability detection 4 Example internal control frameworks: Cobi. T, ISO 17799 4 Example regulations: Basel II, FISMA (NIST 800 -53), Do. D 8500. 2, Sarbanes-Oxley, FDA, HIPAA … OWASP 50
Boot. Strap! <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: 4 Tailor to Company Culture! 4 Driven by Risk Management! 4 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**: 4 Vulnerability severity by project, by organization 4 Vulnerabilities by category by project, by organization 4 Vulnerability +/- over time by project 4 % of flaws by lifecycle phase (based on when testing occurs) Source: * Web. Methods, ** Fortify Software OWASP 53
Web Application Security Roles and Responsibilities OWASP 54
Get involved <Security Analyst: 4 Get involved early in SDLC. Security is a function of the asset we want to secure, what's it worth? 4 Understanding the information held in the application and the types of users is half the battle. 4 Involve an analyst in the design phase and thereafter. <Developer: 4 Embrace secure application development. (Educate) 4 Quality is not just “Does it work” Security is a measure of quality also. OWASP 55
Get involved <QA: 4 Security vulnerabilities are to be considered bugs, the same way as a functional bug, and tracked in the same manner. <Managers: 4 Factor some time into the project plan for security. 4 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): 4 ensure security goals are reached during all cycles of the development process 4 create awareness within development teams, business 4 bridge function to "IT Security" 4 mentor the security engineers and project leaders < Role of security engineer (part of project team) 4 SPOC within development team for all security related matters. < Search for Champions! OWASP 57
Round up OWASP 58
Where to start? <Awareness and Training 42 -hour course: $100 -200/seat 4 Seeing the look on the IT VPs’ faces when they get SQL Injection: Priceless <Policies and Standards <Application Assessments and Reviews 4 Get some data 4 Strive to be consistent and uniform <Support Development Teams OWASP 59
Скачать презентацию Embed within SDLC Module to be combined OWASP
547bbdd9d7ba736a61f9196dccdd7144.ppt