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

(1)

/63 © R. Grimm

1

V13: Secure Software Design –

Secure Development Lifecycle

R. Grimm

Institut für Wirtschafts- und Verwaltungsinformatik Universität Koblenz

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

(2)

/63

Microsoft Security Development Lifecycle

Quoted from:

MS SDL: Simplified Implementation of the Microsoft SDL. Updated November 4, 2010

http://www.microsoft.com/security/sdl/resources/publications.aspx [24.3.2015]

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]

(3)

/63

Three SDL Core Concepts

• Education

• Continuous process improvement

• Accountability

[MS DSL, Nov 2010, p. 3]

MS SDL Capability Areas and Levels of Maturity

Figure 1. SDL Optimization Model with capability and maturity levels [MS DSL, Nov 2010, p.5] 5 Capability Areas (cf., 7 Phases)

(4)

/63

SDL Roles

• Advisors, Experts – External – Consulting – Auditing • Team Champions – Internal – Project Team [MS DSL, Nov 2010, p. 5-6] © R. Grimm 7

MS SDL Lifecycle Phases

Figure 2: The Microsoft Security Development Lifecycle – Simplified [MS DSL, Nov 2010, p. 6]

(5)

/63

SDL Process Illustration

[MS DSL, Nov 2010, Appendix, p. 17]

Content

1. SDL Concept – Secure Development Lifecycle

2. SDL Phases and Practices

(6)

/63

SDL Phases and Practices

• Pre-SDL Requirements

– 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]

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]

(7)

/63

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

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]

(8)

/63

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]

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 http://www.denimgroup.com/media/pdfs/ISSAthreat_modeling.pdf [24 March 2015]

(9)

/63

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]

STRIDE (Threat Modelling)

STRIDE ClassificationScheme (Microsoft)

Threats: Requirements:

Spoofing Identity Originality

Tampering with Data Integrity

Repudiation Non-Repudiation

Information Disclosure Confidentiality

Denial of Service Availability

Elevation of Privilege Least Privilege

[Dickson, Threat Modelling, p. 13]

(10)

/63

DREAD (Threat Modelling)

DREAD RatingScheme (Microsoft)

Impact: Value:

Damage Potential How bad can an exploit hurt?

Reproducibility How reliably can the flaw be exploited?

Exploitability How easy is the flaw to exploit?

Affected Users How many users can be impacted by an

exploit?

Discoverability How “visible” is the vulnerability?

The final rating scores DREAD is the average of all scores.

[Dickson, Threat Modelling, p. 17]

DREAD (Threat Modelling): Impact and Value!

DREAD RatingScheme (Microsoft)

Impact: Value:

Damage Potential How bad can an exploit hurt?

Reproducibility How reliably can the flaw be exploited?

Exploitability How easy is the flaw to exploit?

Affected Users How many users can be impacted by an exploit?

Discoverability 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))

(11)

/63

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]

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]

(12)

/63

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]

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]

(13)

/63

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]

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]

(14)

/63

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]

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]

(15)

/63

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]

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]

(16)

/63

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]

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. 10-11]

(17)

/63

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]

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]

(18)

/63

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]

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]

(19)

/63

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. 11-12]

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]

(20)

/63

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]

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]

(21)

/63

Additional (optional) Security Activities

• Manual Code Review

• Penetration Testing

• Vulnerability Analysis of Similar Applications

[MS DSL, Nov 2010, pp. 12-13]

Other Process Requirements

• Root Cause Analysis

– 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]

(22)

/63

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. 13-14]

Content

3. OWASP – Open Web Application Security Project

(23)

/63

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.

[https://www.owasp.org/index.php/Main_Page]

OWASP Projects

• OWASP Developer Guide 2005/2014

• OWASP Application Security Verification Standard

• OWASP Code Review Guide

• OWASP Testing Guide

[https://www.owasp.org/index.php/OWASP_Guide_Project]

(24)

/63

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

https://www.owasp.org/index.php/OWASP_Guide_Project [24.3.2015]

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” https://www.owasp.org/index.php/OWASP_Guide_Project [24.3.2015]

(25)

/63

A Guide to Building Secure Web Applications and

Services, 2005 (1)

Within OWASP, http://www.taurean.net/docs/OWASPGuide2.0.1.pdf:

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

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

(26)

/63

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

Content

4. Agile Secure Software Development

(27)

/63

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?”

What is „Agile Software Development“?

• Created in February 2001, in Utah, USA by 17 developers

• [http://agilemanifesto.org/]

• 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

(28)

/63

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]

Use security assurance cases

User story Software component Security assessment technique Security evidence Security countermeasure Change Threat Evaluate Security Claim (Goal) Argument Supports Related to Justifies Compose Security policy Violated by Related to Mitigated by Generate Context Strategy Describe Specify decomposition approach Verify

User stories and security policies are added as the software evolves

(29)

/63

Security engineering activities (top line)

integrated in agile development life-cycle (bottom)

agile development life-cycle

Content

5. Other Software and System Design Methods

(30)

/63

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]

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, 25-29

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, 16-35.

– 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, 17-19 July 2013, University of Surrey, Guildford, UK.

(31)

/63

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

Secure Organizations: Information Security

Management Systems (ISMS)

• ISO/IEC 27001

– Requirements for ISMS

• ISO/IEC 27002

– Code of practice of ISMS

• ISO/IEC 27005

– Information security risk management

• ISO/IEC 27006

– 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

(32)

/63

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]

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”?

(33)

/63 Eric Bodden et mult. alt. (2013): Entwicklung sicherer Software durch Security by Design. Fraunhofer SIT Technical Reports SIT-TR-2013-01.

Microsoft Security Development Lifecycle (SDL): Simplified Implementation of the Microsoft SDL. Updated November 4, 2010, http://www.microsoft.com/security/sdl/resources/publications.aspx [24 March 2015]

Microsoft: Security development lifecycle (sdl) process guidance version 4.1aa, April 2010.

http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=d045a05a-c1fc-48c3-b4d5-b20353f97122 [24 March 2015]

Howard, Michael and Steve Lipner: The Security Development Lifecycle. Microsoft Press, 2006.

John B. Dickson, CISSP, Denim Group: Threat Modeling Categorizing the nature and severity of system vulnerabilities. http://www.denimgroup.com/media/pdfs/ISSAthreat_modeling.pdf

[24 March 2015]

OWASP, The Open Web Application Security Project: OWASP Developer Guide 2014. https://www.owasp.org/index.php/OWASP_Guide_Project [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 2005. http://www.taurean.net/docs/OWASPGuide2.0.1.pdf [29.4.2015]

Sven Türpe (2012): Point-and-shoot security design: can we build better tools for developers? NSPW 2012, pp. 27-42. 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 http://agilemanifesto.org [24 March 2015]

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).

https://www.bsi.bund.de/DE/Themen/ITGrundschutz/itgrundschutz_node.html [23.3.2015] BSI (2008): BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise, Version 2.0. Bundesanzeiger-Verlag, Köln, 2008.

Institut für Wirtschaftsprüfer (2002): IDW PS 330 – Abschlussprüfung bei Einsatz von Informationstechnologie, WPg 21/2002, S. 1167 ff., FN-IDW 11/2002, S. 604 ff. http://www.idw.de/ „Verlautbarungen IDW Prüfungsstandards“ [24.3.2015]

ISO/IEC 27001:2013: Information technology - Security techniques - Information security management systems - Requirements. http://www.iso.org [24.3.2015]

ITIL – The IT Infrastrucure Library. http://www.itil-officialsite.com/, see also http://www.itsmfi.org/ Dazu BSI (2005): ITIL und Informationssicherheit. Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und IT-Service-Management. Studie des BSI, 32 Seiten, 2005,

https://www.bsi.bund.de/DE/Publikationen/Studien/ITinf/index_htm.html [24.3.2015]

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. http://www.commoncriteriaportal.org/cc/ [24.3.2015]

COBIT 5 (April 2012): Control Objectives for Information and Related Technology . A Business Framework for the Governance and Management of Enterprise IT. http://www.isaca.org/COBIT/Pages/FAQs.aspx [24.3.2015]