Building Security into the Software Life CycleA Business Case

Marco M. MoranaSenior Consultant

Foundstone Professional Services, a Division of McAfee

2

Outline » Glossary» What is at risk, what we do about it and when» Is software complexity the root cause?» Vulnerability management challenges» Application security vs. software security» A change of perspective: the Software Security Life Cycle (SDLC)» Security-enhancing lifecycle process models» CLASP, activities, phases and roles» Secure-SDLC requirements, how we get there?» Secure software best practices and activities» Guidelines for building secure software» The Secure-SDLC touch-point Model» Secure software best practices and software development models» In summary: take away lessons» Resources

3

Glossary

» Risk: the probability that a particular threat-source will exercise a particular information system vulnerability and the resulting impact if this should occur

» Threat: any circumstance or event with the potential to harm an information system through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.

» Vulnerability: a weakness in system security requirements, design, implementation, or operation, that could be accidentally triggered or intentionally exploited

» Security Defects: implementation vulnerabilities and design vulnerabilities» Security Bugs: implementation-level security software problem» Security Flaw: design-level security software problem

4

What is at risk?

5

What we do about it

1) Security defects discovered BEFORE the product release gets into production:- Found during functional tests- Dealt with as bugs- Fixed with changes into the product - Deployed with product release

2) Vulnerabilities discovered AFTER the product release gets into production:- Found during operation & maintenance- Dealt with as security defects- Fixed with new security patches- Deployed in all products already released

6

When we do something about it?

» Today most people test after software is built!

7

Is software complexity the root cause? » Software is getting bigger and more complex:

– Windows complexity• ~ 2 million lines of code in Windows 3.1 (1990)• ~ 20 million lines of code in Windows 95 (1997)• ~ 40 million lines of code in Windows XP (2001)

» More lines of code means more security bugs:- Average Security Bugs in Code: 6 every one Thousand Line Of Code (KLOC) - Millions of LOC => Thousands of Security Bugs

» Network centric approach means a penetrate and patch mentality:- 47% of security defects that are exploitable are preventable (@stake)

» Lack of focus on secure software development best practices:- Best designed applications have 80% fewer defects than the worst designed (@stake)

8

Application Security vs. Software Security

» Penetrate and patch» Look at the issue» Just in time solution:

fix one application in one single time

» Network Security Centric Perspective

» Information Security Knowledge» Short term tactical solutions (e.g.

penetration tests)» Security as an afterthought,

consider risks only when you are exposed

» High risk low ROI activities

» Manage software security risks» Looks at the root cause» Lifecycle solution: from start (e,g,

inception) to end (e.g. de-commissioning)

» Software Security EngineeringPerspective

» Software Security Knowledge» Long term strategic solution (e.g.

software security best practices)» Security thought early on,

consider risks from software inception

» Low risk High ROI activities

9

Change of perspective: software security life cycle

10

Security-enhancing Lifecycle Process Models

» Repetitive and measurable processes» Provide guidance on secure software activities» Apply development best practices to various software artifacts» Integrate with “foundational” software security activities» Include tactical resources » Provision the use of automation tools» Provide a framework for mapping security activities into SDLC such as:

– SDLC phases, tasks and checkpoints (e.g. M. Howard SDL)– Roles, process phases and interactions (e.g. J. Viega CLASP) – Risk management, knowledge and touchpoints (e.g. Gary Mc Graw)

11

Comprehensive Lightweight Application Security Process (CLASP)

12

Mapping Security Activities, Phases and Roles with CLASP1. Institute a security awareness program ���� Planning ���� Project Manager2. Monitor security metrics ���� On going � Project Manager3. Specify operational environment ���� Analysis & Design ���� Requirement Specifier4. Identify global security policy ���� Planning � Requirement Specifier5. Identify resources and trust boundaries ���� Requirements � Architect6. Identify user roles and resource capability ���� Analysis & Design � Requirement Specifier7. Document security-relevant requirements ���� Requirements � Requirement Specifier8. Detail misuse cases ���� Inception & Elaboration � Requirement Specifier9. Identify attack surface ���� Evaluation � Designer10. Apply security principles to design ���� Analysis & Design � Designer11. Research and assess security posture of tech. solutions ���� Ongoing � Architect12. Annotate class designs with security properties ���� Analysis & Design � Designer13. Specify database security configuration ���� Implementation ���� Designer14. Threat Modeling ���� Analysis & Design � Security Auditor15. Integrate security analysis into source management proc. ���� Implementation ���� Integrator16. Implement interface contracts ���� Implementation ���� Implementor17. Implement and elaborate resource policies and tech. ���� Implementation � Implementor18. Address reported security issues ���� Test � Designer19. Perform source level security review ���� Evaluation � Security Auditor20. Identify, implement, and perform security tests ���� Test � Designer21. Verify security attributes of resources ���� Evaluation � Integrator/Tester22. Perform code signing ���� Transition � Integrator23. Build operational security guide ���� Deploy & Maintain � Integrator/Tester24. Manage security issue disclosure ���� Deploy & Maintain � Project Manager

13

HACME Secure-SDLC requirements

1. Be complaint with HACME security policies and guidelines (e.g. regulatory compliance, information security policy, information risk management guideline)

2. Define security activities that are both strategic (e.g. long term objectives) and tactical (e.g. short term goals)

3. Provide guidance on each security activity with clear objectivesartifacts to be produced and dependencies

4. Show how you map security activities into different software development methodologies (e.g waterfall, AGILE, XP, RUP)

14

How we get there?

» Adopt an activity driven approach» Define and document security activities derived by best practices:

– Preliminary Software Risk Analysis– Secure Requirements Engineering– Security Risk Driven Design– Secure Code Implementation– Security Tests– Secure Configuration & Deployment– Metrics & Measurements – Training & Awareness

» Define dependencies and prerequisites (e.g. activities and artifacts)» Define entry scenarios for the activities (e.g. events and reasons)» Position the activities w.r.t. SDLC methodologies and roadmaps (e.g.

new development vs. legacy)

15

Secure Software Best Practices and Activities

» Preliminary Software Risk Analysis- Define use and misuse cases

requires: Business Requirements, Security Requirementsdepends on: noneproduces: Misuse Cases Diagrams and descriptions

» Security Requirements Engineering- Define Security Requirements

requires: Business requirements, Functional requirements, Industry Regulations, Organizational Policies, Technical Standards

depends on: Misuse casesproduces: Security Requirement Document

16

Secure Software Best Practices and Activities» Security Risk Driven Design

- Secure Architecture & Design Patternsrequires: Requirements, Architecture Documentationdepends on: Security Requirementsproduces: Secure Architecture Documents

- Threat Modelingrequires: Architecture Documents, Data Classification, Requirementsdepends on: Misuse casesproduces: Threat Profile

17

Secure Software Best Practices and Activities» Security Risk Driven Design

- Secure Architecture Reviewrequires: Functional Requirements, Architecture Diagrams,

Network Diagrams, Data Flow Diagramsdepends on: Security Architecture & Design Patterns, Threat Modelproduces: Security Architecture Review Findings

- Security Test Planningrequires: Requirements, Architecture & Network diagrams,

Data Flow Diagrams, Test Tools & Frameworks depends on: Security Requirements, Misuse cases, Threat Modelproduces: Security Test Plan

18

Secure Software Best Practices and Activities

» Secure Code Implementation- Peer Code Review

requires: Source code, Coding standards, Architecture documents,depends on: Threat Modelproduces: Code Review Findings

- Automated static & dynamic code reviewrequires: Source code, Components and Libraries, Builddepends on: Threat Modelproduces: Automated Code Review Findings

- Security Unit Testsrequires: Source code, Unit Test Frameworksdepends on: Security Requirements, Test Casesproduces: Unit Test Results

19

Secure Software Best Practices and Activities

» Security Tests- Functional- Risk Driven- System- Component- White Box - Black Box

all require: Source code, Architecture documents, Data flow Diagrams, Test Environment

all depend on: Security Test Planning, Threat Model, Security Requirements

all produce: Test reports

20

Secure Software Best Practices and Activities

» Secure Configuration & Deployment- Secure Configuration

requires: Operational data and services, source code, build environment, account and password policies, configuration files

depends on: noneproduces: Secure Configuration Guide/Checklist

- Secure Deployment requires: Application files and directories, auditing and logging

services, registry entries, authentication services, service components, network configuration, service accounts

depends on: noneproduces: Secure Deployment Guide/Checklist

21

Secure Software Best Practices and On Going Activities

» Security Training & Awareness- Security Awareness Training- Secure Architecture Design- Secure Coding- Operational Security- Security QA- Ethical hacking

» Metrics & Measurements- Number of bugs vs. flaws- Time to fix bugs vs. flaws- Number of vulnerabilities- Time to respond to incident- Support statistical data

» Information Risk Management- Investigate Preliminary Risks- Business Analysis- Asset Classification- Threat & Vulnerability Analysis- Business Impact Analysis- Risk Determination- Risk Strategy Selection

» Vulnerability management- Policy Compliance- Vulnerability Assessment- Security Configuration- IT Security Risk Management

22

Guidelines for Building Secure Software

1.Threat ModelingThe purpose of this exercise is to ensure that all known threats to the application are adequately addressed. During design, you will gather information such as requirements and design artifacts to analyze your application from the prospective of the impacts of potential threats. The main outcome at this activity is a threat profile that identifies and categorizes you application threats, recommends countermeasures and identifies application vulnerabilities. Further information on how this activity should be conducted is covered in the Guideline For Conducting Threat Modeling

23

Secure-SDLC Touchpoint Model

24

Secure Software Best Practices and the Waterfall Model

25

Secure Software Best Practices and the Spiral Model

26

Secure Software Best Practices and the RUP Model

27

In Summary: Take Away Lessons

» Software and organizations are not homogenous (e.g. X divisions, Y software applications running on Z platforms implement N software technologies)

» Building security into the SDLC is a formal process:- Top Down (organization driven from CIO)- Bottom up (gap analysis from managers and auditors)

» S-SDLC and Information Risk Management are integrated processes:- S-SDLC � Manage Software Security Risks - Technical Risk Management � Information Risk Management

» There is no silver bullet for software security:- Strategic and tactical plans- Roadmaps: short term, near term and long term (e.g. maturity levels)

» Clients that care about software security know that:- Application Security != Software Security- Security = Commitment x (Best Practices^2 + Tools)

28

Resources

» Foundstone Resources, Whitepapers, Articleswww.foundstone.com

» Comprehensive, Lightweight Application Security (CLASP) Process http://www.securesoftware.com/process/

» DHS Build Security Inhttps://buildsecurityin.us-cert.gov

» Most recent books on software security:- Gary McGraw “ Software Security”, January 2006 Addison Wesley- M. Howard and S. Lipner: “The Security Development Lifecycle”, May 2006

Microsoft Press

29

Thanks You For Listening!