Building Security into the Software Life Cycle

Building Security into the Software Life Cycle

A Business Case

Marco M. Morana

Senior Consultant

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

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

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

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)

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 Engineering Perspective

» Software Security Knowledge

» Long term strategic solution (e.g. software security best practices)

» Security thought early on, consider risks from software inception

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)

Comprehensive Lightweight Application Security

Process (CLASP)

Mapping Security Activities, Phases and Roles with CLASP

1. Institute a security awareness program Planning Project Manager

2. Monitor security metrics On going Project Manager

3. Specify operational environment Analysis & Design Requirement Specifier

4. Identify global security policy Planning Requirement Specifier

5. Identify resources and trust boundaries Requirements Architect

6. Identify user roles and resource capability Analysis & Design Requirement Specifier

7. Document security-relevant requirements Requirements Requirement Specifier

8. Detail misuse cases Inception & Elaboration Requirement Specifier

9. Identify attack surface Evaluation Designer 10. Apply security principles to design Analysis & Design Designer 11. Research and assess security posture of tech. solutions Ongoing Architect 12. Annotate class designs with security properties Analysis & Design Designer

13. Specify database security configuration Implementation Designer

14. Threat Modeling Analysis & Design Security Auditor

15. Integrate security analysis into source management proc. Implementation Integrator

16. Implement interface contracts Implementation Implementor

17. Implement and elaborate resource policies and tech. Implementation Implementor

18. Address reported security issues Test Designer

19. Perform source level security review Evaluation Security Auditor

20. Identify, implement, and perform security tests Test Designer

21. Verify security attributes of resources Evaluation Integrator/Tester

22. Perform code signing Transition Integrator

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 objectives

artifacts to be produced and dependencies

4.

Show how you map security activities into different software

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)

Secure Software Best Practices and Activities

- Define use and misuse cases

requires: Business Requirements, Security Requirements depends on: none

produces: 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 cases

Secure Software Best Practices and Activities

- Secure Architecture & Design Patterns

requires: Requirements, Architecture Documentation depends on: Security Requirements

produces: Secure Architecture Documents - Threat Modeling

requires: Architecture Documents, Data Classification, Requirements depends on: Misuse cases

Secure Software Best Practices and Activities

- Secure Architecture Review

requires: Functional Requirements, Architecture Diagrams, Network Diagrams, Data Flow Diagrams

depends on: Security Architecture & Design Patterns, Threat Model produces: Security Architecture Review Findings

- Security Test Planning

requires: Requirements, Architecture & Network diagrams, Data Flow Diagrams, Test Tools & Frameworks depends on: Security Requirements, Misuse cases, Threat Model

Secure Software Best Practices and Activities

- Peer Code Review

requires: Source code, Coding standards, Architecture documents, depends on: Threat Model

produces: Code Review Findings

- Automated static & dynamic code review

requires: Source code, Components and Libraries, Build depends on: Threat Model

produces: Automated Code Review Findings - Security Unit Tests

Secure Software Best Practices and Activities

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

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

Secure Software Best Practices and Activities

- Secure Configuration

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

configuration files depends on: none

produces: 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

Secure Software Best Practices and On Going Activities

- 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

Guidelines for Building Secure Software

1.Threat Modeling

The 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

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

Resources

» Foundstone Resources, Whitepapers, Articles

www.foundstone.com

» Comprehensive, Lightweight Application Security (CLASP) Process

http://www.securesoftware.com/process/

» DHS Build Security In

https://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