IT-Risk-Management. Secure Software Design Secure Development Lifecycle

Transcription

1 IT-Risk-Management V13: Secure Software Design Secure Development Lifecycle R. Grimm Institut für Wirtschafts- und Verwaltungsinformatik Universität Koblenz R. Grimm 1 / Content 1. SDL Concept Secure Development Lifecycle SDL Phases and Practices OWASP Open Web Application Security Project Agile Secure Software Development Other Software and System Design Methods R. Grimm 2 /63 Seite 1 1

2 2 Microsoft Security Development Lifecycle Quoted from: MS SDL: Simplified Implementation of the Microsoft SDL. Updated November 4, [ ] R. Grimm 3 /63 SDL Applicability Software design in these application areas: Secure software development not orgs see ISO 27001, or BSI-Grundschutz not certification see Common Criteria not functional development see software engineering Business Sensitive data Internet [MS DSL, Nov 2010, p. 5] R. Grimm 4 /63 Seite 2

3 3 Three SDL Core Concepts Education Continuous process improvement Accountability [MS DSL, Nov 2010, p. 3] R. Grimm 5 /63 MS SDL Capability Areas and Levels of Maturity 5 Capability Areas (cf., 7 Phases) Figure 1. SDL Optimization Model with capability and maturity levels [MS DSL, Nov 2010, p.5] R. Grimm 6 /63 Seite 3

4 4 SDL Roles Advisors, Experts External Consulting Auditing Team Champions Internal Project Team [MS DSL, Nov 2010, p. 5-6] R. Grimm 7 /63 MS SDL Lifecycle Phases Figure 2: The Microsoft Security Development Lifecycle Simplified [MS DSL, Nov 2010, p. 6] R. Grimm 8 /63 Seite 4

5 5 SDL Process Illustration [MS DSL, Nov 2010, Appendix, p. 17] R. Grimm 9 /63 Content 1. SDL Concept Secure Development Lifecycle 2. SDL Phases and Practices 3. OWASP Open Web Application Security Project 4. Agile Secure Software Development 5. Other Software and System Design Methods R. Grimm 10 /63 Seite 5

6 6 Pre-SDL Requirements SDL Phases and Practices SDL Practice 1: Training Requirements Phase One: Requirements SDL Practice 2: Security Requirements SDL Practice 3: Quality Gates/Bug Bars SDL Practice 4: Security and Privacy Risk Assessment Phase Two: Design SDL Practice 5: Design Requirements SDL Practice 6: Attack Surface Reduction SDL Practice 7: Threat Modeling [MS DSL, Nov 2010, pp. 7-12] R. Grimm 11 /63 SDL Phases and Practices Phase Three: Implementation SDL Practice 8: Use Approved Tools SDL Practice 9: Deprecate Unsafe Functions SDL Practice 10: Static Analysis Phase Four: Verification SDL Practice 11: Dynamic Program Analysis SDL Practice 12: Fuzz Testing SDL Practice 13: Threat Model and Attack Surface Review Phase Five: Release SDL Practice 14: Implement Incident Response Plan SDL Practice 15: Final Security Review SDL Practice 16: Release/Archive After Release: Response: Execute Incident Response Plan [MS DSL, Nov 2010, pp. 7-12] R. Grimm 12 /63 Seite 6

7 7 Pre-SDL Requirements: Basic Security Training SDL Practice 1: Training Requirements Basics: Secure design Threat Modelling Secure Coding Security Testing Privacy [MS DSL, Nov 2010, pp. 7-8] R. Grimm 13 /63 Pre-SDL Requirements: Advanced Security Training SDL Practice 1: Training Requirements Advanced: Advanced security design and architecture Trusted user interface design Security vulnerabilities in detail Implementing custom threat mitigations [MS DSL, Nov 2010, pp. 7-8] R. Grimm 14 /63 Seite 7

8 8 SDL Practice 1, Basic Training Secure Design Secure Design Attack surface reduction Defense in depth Principle of least privilege Secure defaults [MS DSL, Nov 2010, pp. 7-8] R. Grimm 15 /63 SDL Practice 1, Basic Training Threat Modelling Threat modeling (*): Overview of threat modeling Design implications of a threat model Coding constraints based on a threat model (*) For a deeper insight, see: John B. Dickson, CISSP, Denim Group: Threat Modeling Categorizing the nature and severity of system vulnerabilities [24 March 2015] R. Grimm 16 /63 Seite 8

9 9 Dickson, Threat Modelling Covers Assets, Threats, Vulnerabilities Threats against Networks (e.g. spoofed packets) Hosts (e.g. buffer overflows, illicit paths) Applications (e.g. SQL injection, XSS, input tampering) Identify, classify, rate threats STRIDE Classification Scheme (Microsoft) DREAD Rating Scheme (Microsoft) [Dickson, Threat Modelling] R. Grimm 17 /63 STRIDE (Threat Modelling) STRIDE Classification Scheme (Microsoft) Threats: Spoofing Identity Tampering with Data Repudiation Information Disclosure Denial of Service Elevation of Privilege Requirements: Originality Integrity Non-Repudiation Confidentiality Availability Least Privilege [Dickson, Threat Modelling, p. 13] R. Grimm 18 /63 Seite 9

10 10 DREAD (Threat Modelling) DREAD Rating Scheme (Microsoft) Impact: Damage Potential Reproducibility Exploitability Affected Users Discoverability Value: How bad can an exploit hurt? How reliably can the flaw be exploited? How easy is the flaw to exploit? How many users can be impacted by an exploit? How visible is the vulnerability? The final rating scores DREAD is the average of all scores. [Dickson, Threat Modelling, p. 17] R. Grimm 19 /63 DREAD (Threat Modelling): Impact and Value! DREAD Rating Scheme (Microsoft) Impact: Damage Potential Reproducibility Exploitability Affected Users Discoverability Value: How bad can an exploit hurt? How reliably can the flaw be exploited? How easy is the flaw to exploit? How many users can be impacted by an exploit? How visible is the vulnerability? The final rating scores DREAD is the average of all scores. R.G.: Compare these questions with the risk of potential damage Risk = Σ((Damage Value) x (Probability of Damage Event)) R. Grimm 20 /63 Seite 10

11 11 SDL Practice 1, Basic Training Secure Coding Buffer overruns (for applications using C and C++) Integer arithmetic errors (for applications using C and C++) Cross-site scripting (for managed code and Web applications) SQL injection (for managed code and Web applications) Weak cryptography [MS DSL, Nov 2010, pp. 7-8] R. Grimm 21 /63 SDL Practice 1, Basic Training Secure Testing Differences between security testing and functional testing Risk assessment Security testing methods [MS DSL, Nov 2010, pp. 7-8] R. Grimm 22 /63 Seite 11

12 12 SDL Practice 1, Basic Training Privacy Types of privacy-sensitive data Privacy design best practices Risk assessment Privacy development best practices Privacy testing best practices [MS DSL, Nov 2010, pp. 7-8] R. Grimm 23 /63 Phase One: Requirements and Practices SDL Practice 2: Security Requirements SDL Practice 3: Quality Gates/Bug Bars SDL Practice 4: Security and Privacy Risk Assessment [MS DSL, Nov 2010, pp. 8-9] R. Grimm 24 /63 Seite 12

13 13 SDL Practice 2, Security Requirements Security and privacy requirements To be stated in the beginning of the project Specification of minimum security requirements for the application to run in its planned operational environment Specification and deployment of a security vulnerability/work item tracking system [MS DSL, Nov 2010, p. 8] R. Grimm 25 /63 SDL Practice 3, Quality Gates/Bug Bars Quality gates and bug bars = minimum acceptable levels of security and privacy quality e.g., all compiler warnings must be triaged and fixed prior to code check-in Quality gates for each development phase Compliance with quality gates checked by Final Security Review (FSR, see below SDL 15). [MS DSL, Nov 2010, p. 8] R. Grimm 26 /63 Seite 13

14 14 SDL Practice 4, Security and Privacy Risk Assessment Security and Privacy impact rating (high, moderate, low) To answer these questions: 1. Which portions of the project will require threat models before release? 2. Which portions of the project will require security design reviews before release? 3. Which portions of the project (if any) will require penetration testing by a mutually agreed upon group that is external to the project team? 4. Are there any additional testing or analysis requirements the security advisor deems necessary to mitigate security risks? 5. What is the specific scope of the fuzz testing requirements? [MS DSL, Nov 2010, p. 9] R. Grimm 27 /63 Phase Two: Design SDL Practice 5: Design Requirements SDL Practice 6: Attack Surface Reduction SDL Practice 7: Threat Modeling [MS DSL, Nov 2010, pp. 9-10] R. Grimm 28 /63 Seite 14

15 15 SDL Practice 5, Design Requirements To be stated in the beginning of the project Before coding!! 1. Security and privacy concerns in functional design ( secure features ) Examples: separation of duty, least privilege, robust implementation Specify how to deploy the feature or function in a secure fashion 2. Security and privacy functional design ( security features ) Examples: access control, authentication methods, content encryption Specify the intended use of a security feature or function [MS DSL, Nov 2010, pp. 9-10] R. Grimm 29 /63 SDL Practice 6, Attack Surface Reduction Associated with threat modeling, see SDL 7 All means of reducing risk by giving attackers less opportunity to exploit vulnerabilities Shutting off or restricting access to system service, applying the principle of least privilege employing layered defenses wherever possible [MS DSL, Nov 2010, p. 10] R. Grimm 30 /63 Seite 15

16 16 SDL Practice 7, Threat Modeling Team exercise Structured document for discussion Structured security analysis task performed during the software design stage To address: security implications of designs in the context of their planned operational environments security issues at the component or application level Uses STRIDE classification and DREAD rating (see above, SDL 1 and Dickson Threat Modelling ) [MS DSL, Nov 2010, pp. 10] R. Grimm 31 /63 Phase Three: Implementation SDL Practice 8: Use Approved Tools SDL Practice 9: Deprecate Unsafe Functions SDL Practice 10: Static Analysis of source code, with tools to be augmented with human (manual) code review [MS DSL, Nov 2010, pp ] R. Grimm 32 /63 Seite 16

17 17 Phase Four: Verification SDL Practice 11: Dynamic Program Analysis SDL Practice 12: Fuzz Testing SDL Practice 13: Threat Model and Attack Surface Review [MS DSL, Nov 2010, p. 11] R. Grimm 33 /63 SDL Practice 11, Dynamic Program Analysis Run-time verification of software programs Monitor application behavior for security problems, e.g. memory corruption user privilege issues Use tools, e.g. AppVerifier of SDL [MS DSL, Nov 2010, p. 11] R. Grimm 34 /63 Seite 17

18 18 SDL Practice 12, Fuzz Testing A specialized form of dynamic analysis Provoke program failure by deliberately introducing malformed or random data Examples: Buffer overflows Fake identities Wrong formats Sudden interruptions Cross site scripting more [MS DSL, Nov 2010, p. 11] R. Grimm 35 /63 SDL Practice 13, Threat Model and Attack Surface Review Compare Implementation with Design (SDL 6 and 7) Compliance of implementation with design, incl. all changes All attack vectors are reviewed and mitigated [MS DSL, Nov 2010, p. 11] R. Grimm 36 /63 Seite 18

19 19 Phase Five: Release SDL Practice 14: Incident Response Plan SDL Practice 15: Final Security Review (FSR) SDL Practice 16: Release/Archive [MS DSL, Nov 2010, pp ] R. Grimm 37 /63 SDL Practice 14, Incident Response Plan To identify: A sustained engineering (SE) team for engineering, marketing, communications, and management to act as points of first contact in a security emergency On-call contacts with decision-making authority 24/7 Security servicing plans for code inherited from other groups within your organization Security servicing plans for licensed third-party code including file names, versions, source code, third-party contact information, and contractual permission to make changes [MS DSL, Nov 2010, p. 11] R. Grimm 38 /63 Seite 19

20 20 SDL Practice 15, FSR Final Security Review FSR includes examination of threat models exception requests tool output and performance against the previously determined quality gates or bug bars FSR results in one of three different outcomes: Passed FSR Passed FSR with exceptions FSR with escalation [MS DSL, Nov 2010, p. 12] R. Grimm 39 /63 SDL Practice 16, Release/Archive Archive all data necessary to perform post-release servicing tasks, incl.: Source code, binaries Private symbols Threat models Documentation Emergency response plans License and servicing terms for any third-party software To be certified by security advisor (using FSR, see SDL 15) [MS DSL, Nov 2010, p. 12] R. Grimm 40 /63 Seite 20

21 21 Additional (optional) Security Activities Manual Code Review Penetration Testing Vulnerability Analysis of Similar Applications [MS DSL, Nov 2010, pp ] R. Grimm 41 /63 Root Cause Analysis Other Process Requirements Upon discovery of a previously unknown vulnerability Identify root cause, incl. human error, tool failure, and policy failure Periodic Process Updates [MS DSL, Nov 2010, p. 13] R. Grimm 42 /63 Seite 21

22 22 Application Security Verification Process Simulation by a realistic application scenario Realistic with respect to the security and privacy requirements of the organization the functional and technical requirements of the application under development the application s operational context Security advisors check the appropriateness of the scenario and data the appropriateness of behavior, e.g. only authorized personnel can use the application strong separation between roles [MS DSL, Nov 2010, pp ] R. Grimm 43 /63 Content 1. SDL Concept Secure Development Lifecycle 2. SDL Phases and Practices 3. OWASP Open Web Application Security Project 4. Agile Secure Software Development 5. Other Software and System Design Methods R. Grimm 44 /63 Seite 22

23 23 OWASP The Open Web Application Security Project OWASP is a worldwide non-profit organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks. [ R. Grimm 45 /63 OWASP Projects OWASP Developer Guide 2005/2014 OWASP Application Security Verification Standard OWASP Code Review Guide OWASP Testing Guide [ R. Grimm 46 /63 Seite 23

24 24 The OWASP Developer Guide 2014 The Developer Guide 2014 is a "first principles" book it's not specific to any one language or framework, as they all borrow ideas and syntax from each other. There are highly specific issues in different languages, such as PHP configuration settings or Spring MVC (*) issues, but we need to look past these differences and apply the basic tenets of secure system engineering to application security. (*) Spring MVC ( Model-View-Controller ): Java framework for the development of dynamic Web applications [ ] R. Grimm 47 /63 Major Themes of Developer Guide 2014 Developing Software includes: Foundation Architecture Design Build Configure Operate Modern Web Applications include Ajax and RESTful (*) API Mobile Applications (*) Representational State Transfer (REST): an architectural style, light-weight SOAP, clean HTTP [ ] R. Grimm 48 /63 Seite 24

25 25 A Guide to Building Secure Web Applications and Services, 2005 (1) Within OWASP, Free Software Foundation, Black Hat Edition 2.0, July 27, 2005 Chapters (I): Web Applications Security Architecture and Design Policy Frameworks Incl. Development Methodology, Coding Standards, Secure Code Control Security Coding Principles incl. Asset Classification, Security Architecture, Security Principles Threat Risk Modelling incl. Microsoft Threat Modelling Process (STRIDE/DREAD), Risk Modelling, Other Modelling Systems R. Grimm 49 /63 A Guide to Building Secure Web Applications and Services, 2005 (2) Free Software Foundation, Black Hat Edition 2.0, July 27, 2005 Chapters (II): Handling E-Commerce Payments Phishing Web Services Authentication Authorization Session Management Data Validation Interpreter Injection Canonicalization, Locale and Unicode Error Handling, Auditing and Logging R. Grimm 50 /63 Seite 25

26 26 A Guide to Building Secure Web Applications and Services, 2005 (3) Free Software Foundation, Black Hat Edition 2.0, July 27, 2005 Chapters (III): File System Buffer Overflows Administrative Interfaces Cryptography Configuration Incl. platforms, default passwords, secure strings, encrypted data, database security Maintenance Denial of Service Attacks GNU Free Documentation License PHP Guidelines incl. Cross-Site Scripting, SQL-, Code-, Command-Injection R. Grimm 51 /63 Content 1. SDL Concept Secure Development Lifecycle 2. SDL Phases and Practices 3. OWASP Open Web Application Security Project 4. Agile Secure Software Development 5. Other Software and System Design Methods R. Grimm 52 /63 Seite 26

27 27 Agile Secure Software Development In a Presentation Feb 3, 2014, at Fraunhofer SIT, Darmstadt, Lotfi Othmane (Technische Universiteit Eindhoven) asks: Is it possible to develop secure software using the agile software development approach? R. Grimm 53 /63 What is Agile Software Development? Created in February 2001, in Utah, USA by 17 developers [ The approach has four values: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan Known methods: Scrum and XP R. Grimm 54 /63 Seite 27

28 28 L. Othmane s Answer: Yes, we can It is possible to develop secure software using the agile software development life-cycle Solution: Use security assurance cases to trace the impacts of software changes on the security of the software Integrate security engineering activities into the agile development life-cycle [Othmane, Feb 2014, #21] R. Grimm 55 /63 Use security assurance cases Related to User story Change Verify Software component Evaluate Security assessment technique Generate User stories and security policies are added as the software evolves Security countermeasure Mitigated by Related to Justifies Argument Supports Security evidence Threat Compose Security Claim (Goal) Violated by Describe Specify decomposition approach Security policy Context Strategy [Othmane, Feb 2014, #11] R. Grimm 56 /63 Seite 28

29 29 Security engineering activities (top line) integrated in agile development life-cycle (bottom) agile development life-cycle [Othmane, Feb 2014, #18] R. Grimm 57 /63 Content 1. SDL Concept Secure Development Lifecycle 2. SDL Phases and Practices 3. OWASP Open Web Application Security Project 4. Agile Secure Software Development 5. Other Software and System Design Methods R. Grimm 58 /63 Seite 29

30 30 Other Software and System Design Methods Secure IT Systems: Security Requirements Engineering Secure Software Following Common Criteria: Requirements and Evaluation Phases Secure Organizations Following ISO 27001, IT-Grundschutz Requirements, Installation, Responsibilities, Verification see [Bodden et mult alt. 2012] R. Grimm 59 /63 Security Requirements Engineering Part of Requirements Engineering Subject to research, e.g.: International Workshop Series "RE - Requirements Engineering", newest: RE'14-22nd IEEE International Requirements Engineering Conference, August, Karlskrona, Sweden Phase of Secure System Design, Requirements Implementation Configuration Evaluation e.g., Microsoft SDL Phase 2, see above e.g., Common Criteria: Security Problem Definition, Security Objectives, Security Requirements of a Protection Profile or of a Security Target Methodology under Research, e.g., Simic-Draws, D. et mult.alt. (2013): Holistic and Law Compatible IT Security Evaluation. In IJISP, 7/3, 2013, e.g., Bräunlich, K.; and Grimm, R. (2013): A Formal Model for the Requirement of Verifiability in Electronic Voting by means of a Bulletin Board. In: VoteID 2013, July 2013, University of Surrey, Guildford, UK. R. Grimm 60 /63 Seite 30

31 31 Secure Software: Common Criteria Internationally standardized methodology for the specification of security requirements and for the evaluation of implemented security functions Specification of values, threats and security objectives Security functional requirements in protection profiles: statement of requirements in security targets: products to be evaluated No guide for security design Mapping of security measures on security requirements Assurance levels w.r.t. the strength of measures the quality of evaluation R. Grimm 61 /63 Secure Organizations: Information Security Management Systems (ISMS) ISO/IEC Requirements for ISMS ISO/IEC Code of practice of ISMS ISO/IEC Information security risk management ISO/IEC Requirements for auditing and certification of ISMS IT-BASIC Protection ( BSI Grundschutz ) Check list for the security of the IT building blocks in an organization Both for improving the security, and for security evaluation/certification R. Grimm 62 /63 Seite 31

32 32 Secure Organizations: Standards for the usage of IT CoBIT Control Objectives for Information and Related Technology ITIL IT Infrastructure Library Binding contracts of a an IT service with its users/customers E.g., Change Management, Security Management, IDW PS 330 Institute of certified public accountants (Wirtschaftsprüfer) Final check of information technology in use of the audited firm [For details of CoBIT, ITIL, and IDW, see references list] R. Grimm 63 /63 Questions to check your knowledge 1. List and explain shortly the core concepts of SDL. (three) 2. List and explain shortly the phases of SDL. (seven, related to five capability areas) 3. Explain the SDL practices of quality gates. (SDL 3) 4. Explain the difference between security features and secure features. Give examples. (SDL 5) 5. Explain the STRIDE and DREAD schemes of threat modelling. (SDL 7) 6. What does fuzz testing do? Give examples. (SDL 12) 7. In which situation is root cause analysis required, and what does it do? (SDL Other Process Requirements) 8. Which main activities does Lotfi Othmane (TU Eindhoven, 2014) suggest to enable agile secure software development? R. Grimm 64 /63 Seite 32

33 33 References (1, Software Development) Eric Bodden et mult. alt. (2013): Entwicklung sicherer Software durch Security bydesign. Fraunhofer SIT Technical Reports SIT-TR Microsoft Security Development Lifecycle (SDL): Simplified Implementation of the Microsoft SDL. Updated November 4, 2010, [24 March 2015] Microsoft: Security development lifecycle (sdl) process guidance version 4.1aa, April b20353f97122 [24 March 2015] Howard, Michael and Steve Lipner: The Security Development Lifecycle. Microsoft Press, John B. Dickson, CISSP, Denim Group: ThreatModeling Categorizing the nature and severity of system vulnerabilities. [24 March 2015] OWASP, The Open Web Application Security Project: OWASP Developer Guide [25 March 2015] OWASP: A Guide to Building Secure Web Applications and Web Services. Editors: A. Wiesmann, M. Curphey, A. v.d. Stock, R. Stirbei. 2.0 Black Hat Edition, 27 July [ ] Sven Türpe (2012): Point-and-shoot security design: can we build better tools for developers? NSPW 2012, pp Lotfi Othmane, TU Eindhoven (2014): Extending the Agile Development Life-cycle to Develop Secure Software. Presentation Feb 3, 2014, at Fraunhofer SIT, Darmstadt. The Agile Software Development Manifesto [24 March 2015] R. Grimm 65 /63 References (2, System and Organization Security) BSI Bundesamt für Sicherheit in der Informationstechnik (2014): IT-Grundschutz-Kataloge. 14. Ergänzungslieferung, 2014 (PDF, ca. 14 MB). [ ] BSI (2008): BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise, Version 2.0. Bundesanzeiger-Verlag, Köln, Institut für Wirtschaftsprüfer (2002): IDW PS 330 Abschlussprüfung bei Einsatz von Informationstechnologie, WPg 21/2002, S ff., FN-IDW 11/2002, S. 604 ff. Verlautbarungen IDW Prüfungsstandards [ ] ISO/IEC 27001:2013: Information technology - Security techniques - Information security management systems - Requirements. [ ] ITIL The IT Infrastrucure Library. see also Dazu BSI (2005): ITIL und Informationssicherheit. Möglichkeitenund Chancendes Zusammenwirkensvon IT-Sicherheitund IT-Service-Management. Studie des BSI, 32 Seiten, 2005, [ ] Common Criteria (2006): Common Criteria and Common Evaluation Methodology v2.3, also registered as ISO/IEC 15408:2005. And: Common Criteria and Common Evaluation Meth-odology Version 3.1 Release 2. [ ] COBIT 5 (April 2012): Control Objectives for Information and Related Technology. A Business Framework for the Governance and Management of Enterprise IT. [ ] R. Grimm 66 /63 Seite 33