Development*Process*for*Secure* So2ware
Development Processes ( Lecture outline ) • Emphasis on „building secure software” as opposed to „building security software” • Major methodologies – Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints • Building Security In Maturity Model – BSIMM 492*
Development Processes ( Lecture outline ) • Emphasis on „building secure software” as opposed to „building security software” • Major methodologies – Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints • Building Security In Maturity Model – BSIMM 493*
Microsoft Security Development Cycle • http://www.microsoft.com/security/sdl/default.aspx 494*
Development Processes ( Lecture outline ) • Emphasis on „building secure software” as opposed to „building security software” • Major methodologies – Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints • Building Security In Maturity Model – BSIMM 495*
Open Web Application Security Project OWASP https://www.owasp.org/ – Injection • Collect resources – Cross-site Scripting ( XSS ) for Web applications – Broken authentication and session – Top ten security flaws management – Various security testing tools – Insecure direct object references – Cross-site request forgery (CSRF) – Various security control means – Security misconfiguration – Insecure cryptographic storage • e.g., code review guide – Failure to restrict URL access – Insufficient transport layer protection – Unvalidated redirects and forwards • CLASP – Comprehensive Lightweight Application Security Process 496*
Open Web Application Security Project OWASP https://www.owasp.org/ – Injection • Collect resources – Cross-site Scripting ( XSS ) for Web applications – Broken authentication and session – Top ten security flaws management – Various security testing tools – Insecure direct object references – Cross-site request forgery (CSRF) – Various security https://www.owasp.org/index.php/ control means – Security misconfiguration OWASP_Appsec_Tutorial_Series – Insecure cryptographic storage • e.g., code review guide – Failure to restrict URL access – Insufficient transport layer protection – Unvalidated redirects and forwards • CLASP – Comprehensive Lightweight Application Security Process 497*
CLASP https://www.owasp.org/index.php/Category:OWASP_CLASP_Project • Goal : – move security concerns into the early stages of the software development lifecycle, whenever possible • Set of process pieces that can be integrated into any software development process – Introduction to the Concepts behind CLASP to get started – Seven key Best Practices – High-level Security Services (authorisation, authentication, … ) – Core Security Principles – Roles – Activities – Process engineering and roadmaps – Checklisted Coding Guidelines – Vulnerabilities that occur in source code – Searchable Vulnerability Checklist 498*
CLASP Best Practices • Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures • Define and monitor metrics • Publish operational security guidelines 499*
CLASP Best Practices • Institute awareness • People should consider programs security to be an important project goal • Perform application • Train all team members assessments • Make people aware of • Capture security security setting requirements • Institute accountability for • Implement secure security issues development practices • Appoint a project security • Build vulnerability officer remediation procedures • Institute rewards for handling of security • Define and monitor metrics issues • Publish operational security guidelines 500*
CLASP Best Practices • Institute awareness programs • Perform application assessments • Capture security • Security analysis of requirements requirements and design • Implement secure – Threat modelling development practices • Source-level security review • Build vulnerability • Security tests remediation procedures • Define and monitor metrics • Publish operational security guidelines 501*
CLASP Best Practices • Institute awareness programs • Treat security requirements • Perform application same way as functional assessments requirements • Capture security • Define security policy requirements • Identify attack surface • Implement secure • Identify resources and trust development practices boundaries • Build vulnerability • Identify misuse cases remediation procedures • Specify operational • Define and monitor metrics environment • Publish operational security guidelines 502*
CLASP Best Practices • Institute awareness programs • Perform application assessments • Annotate classes with • Capture security security properties requirements • Apply principles of secure • Implement secure design development practices • Manage resources • Build vulnerability • Manage contracts and remediation procedures interfaces • Define and monitor metrics • Publish operational security guidelines 503*
CLASP Best Practices • Institute awareness programs • Perform application assessments • Capture security • Address reported security requirements issues • Implement secure • Manage security issue development practices disclosure process • Build vulnerability remediation procedures • Define and monitor metrics • Publish operational security guidelines 504*
CLASP Best Practices • Institute awareness programs • Perform application assessments • Capture security requirements • Select metrics • Implement secure • Collect data development practices • Evaluate results • Build vulnerability remediation procedures • Define and monitor metrics • Publish operational security guidelines 505*
CLASP Best Practices • Institute awareness programs • Perform application assessments • Capture security • Build operational security requirements guide • Implement secure • Specify database security development practices configuration • Build vulnerability remediation procedures • Define and monitor metrics • Publish operational security guidelines 506*
Development Processes ( Lecture outline ) • Emphasis on „building secure software” as opposed to „building security software” • Major methodologies – Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints • Building Security In Maturity Model – BSIMM 507*
Seven Security Touchpoints G. McGraw, “Software Security: Building Security In” “All software projects produce at least one artifact: source code” 508*
Seven Security Touchpoints G. McGraw, “Software Security: Building Security In” “All software projects produce at least one artifact: source code” 1. Code review (tools) 5. Abuse analysis 2. Risk analysis 6. Security requirements 3. Penetration test 7. Security attacks 4. Risk-based security test * External analysis 509*
Code review (tools) • Aim: catching implementation bugs early • Tool helps to achieve good code coverage • Aim for good, not perfect 510*
Risk analysis • Create description of • Ambiguity analysis architecture – Discover new risks – Start with one page – Find unclear parts in how the system works – Forest-level view – Trust, data sensitivity, threat • Attack resistance models – Use checklists of known attacks • Weakness analysis – Example: Microsoft STRIDE – Impact of external software • Spoofing, Tampering, dependencies Repudiation, Info disclosure, Denial of service, Elevation of – Platform (hardware, OS) privilege – Frameworks – Called services Combine risks and consider business impact Rank risks Find solutions 511*
Penetration test Attack on a system with the intention of finding security weaknesses, potentially gaining access to it, its functionality and data • Use the source • Use in-house QA department – Otherwise people send time on reverse- – They already know the engineering system system • Apply business – Use tools and training to add security testing skills priorities • Test more than once – Logic flaw vs. XSS flaw – XSS is important if it contributes towards • Incorporate the findings compromising business back into development logic 512*
Risk-based security test • Test based on priorities – Architectural risks – Risks discovered during code review • Test malicious input – Use fuzzing tool 513*
Abuse analysis and Security requirement • Security is not a set of features • How system should react to illegitimate use • Like use cases, but with malicious users 514*
1. Input validation and 5 . Error Handling Representation 6. Code Quality 2. API Abuse 7. Encapsulation 3. Security Features 4. Time and State * Environment Seven Pernicious Kingdoms * 515 ** Tsipenyuk* et#al., *2005*
External analysis • Unfortunately – Software architects, developers, and testers are largely unaware of the software security problems • Good news – They acknowledge that security problems exists! • Bad news – Barely begun to apply the security solutions 516*
Recommend
More recommend
