Secure Development Lifecyle

BSIMM and OpenSAMM

Lucas v. Stockhausen
Software Security Consultant
Fortify

Agenda
50 minutes

The Problem
BSIMM
OpenSAMM
SSA

10 minutes
Questions

Attackers

$288 Billion Global IT

Security Spend 2007

PCs

Network
Software

Intellectual
Property

Customer
Data

Business
Processes

Corporate Trade
Secrets

$165 million, or 0.0579%

3

What happens, if valuable stuff gets lost?

People remember !

Case Study: Heartland Payment Systems

About Heartland
Full payment processing for 2,500+ small/mid-size clients
1997 they were #62 in U.S.
2009 they were #4 in U.S., #8 in world
Latest in the line of largest ever breaches
Highly organized
94 million credit & debit card data stolen
Visa revokes PCI Compliant status
Share price drops 80%
Overall costs so far > US$ 140 Mill.

Case Study: Heartland Payment Systems

Case Study: Heartland Payment Systems

Outsourced attack tool

discovers vulnerable app

SQL Injection
Access to corporate
network

Open over months

94 million card data stolen

Case Study: RBS Worldpay Breach

RBS WorldPay is the US-based payment processing division
of the Royal Bank of Scotland
Personal and financial account information of 1.5 million
cardholders as well as 1.1 million social security numbers
were potentially compromised.
As well around 100 full credit card information was stolen
Over 130 different ATM machines in 49 cities in 16 countries
were accessed in a 30-minute period on November 8th 2008
Hackers also seemed to be able to change the limit on the
cards and the number of transactions being done, as within
these 30 minutes US$ 9 Million have been taken out of the
ATMs
This makes US$ 90.000 on average for each credit card.
8

Case Study: RBS Worldpay Breach

The end of the story
http://www.heise.de/newsticker/meldung/Estland-liefertmutmasslichen-Computerkriminellen-an-die- USA-aus1052240.html
09. August 2010: Estland turned the people behind it to the
US.

SDLC
Secure Development Lifecycle
Humans Processes Technology

Security in the Development Lifecycle

11

Maturity Models

12

BSIMM
Contains four domains

Governance
Intelligence
SSDL Touchpoints
Deployment

Each domain contains three practices

13

BSIMM

14

BSIMM
There are three levels for every practice
Level 1: straigtforward and simple
Level 2: more difficult, requiring more coordination
Level 3: rocket science

There are 109 activities across the 12 practices and 3

Levels

15

BSIMM: Example Training

Level 1: Create the software security satellite. (4 Activities)
Activity 1: Provide awareness training.

Level 2: Make customized, role-based training available on

demand. (5 Activities)
Activity 1: Offer role-specific advanced curriculum (tools,
technology stacks, bug parade)

Level 3: Provide recognition for skills and career path

progression (4 Activities)
Activity 1: Reward progression through curriculum (certification or
HR)

16

OpenSAMM
Contains four business functions

Governance
Construction
Verification
Deployment

Each business function defines three Security Practices

17

OpenSAMM

18

OpenSAMM
Each Security Practice contains 3 Maturity Levels
Level 1: Initial understanding and ad hoc provision of Security
Practice
Level 2: Increase efficiency and/or effectiveness of the Security
Practice
Level 3: Comprehensive mastery of the Security Practice at scale

Each Level has associated Objectives, Activities and Goals

19

OpenSAMM Example E&G

Level 1: Offer development staff access to resources
around the topics of secure programming and deployment
Activity 1: Conduct technical security awareness training

Level 2: Educate all personnel in the software life-cycle

with role-specific guidance on secure development.
Activity 1: Conduct role-specific application security training

Level 3: Mandate comprehensive security training and

certify personnel for baseline knowledge
Activity 1: Create formal application security support portal

20

Comparison of Activities
BSIMM

OpenSAMM
Activity 1: Conduct
technical security
awareness training
Activity 1: Conduct rolespecific application
security training
Activity 1: Create formal
application security
support portal
Activity 2: Establish rolebased
examination/certification

Activity 1: Provide
awareness training.
Activity 1: Offer role-specific
advanced curriculum (tools,
technology stacks, bug
parade)
Activity 1: Reward
progression through
curriculum (certification or
HR)

21

Can we build an SDLC right now?

22

We definitely have the tools

23

What do we need?
We need to know, what we we want to implement
Good idea is to look what other companies in our sector do
BSIMM is a great help here

Scorecard
Blank
Scorecard

Industry
Best Practices

Enterprise
Scoring

Prioritized
Roadmap

Objective 3

Objective 2

2
5

Objective 1

Objective 0

Strat&
Met

Poli&
Comp

Edu&Gui

ThreatAss

Governance

SecReq

SecureArch

Construction

DesignRev

CodeRev

SecTesting

Verification

VulMgmt EnvHarden OpsEnable

Deployment

25

Lets have a more detailed look at

OpenSAMM

27

Objectives
Strategy and Metrics
Establish unified strategic roadmap for software security within the Organization
Measure relative value of data and software assets and choose risk tolerance
Align security expenditure with relevant business indicators and asset value
Policy & Compliance
Understand relevant governance and compliance drivers to the organization
Establish security and compliance baseline and understand per-project risks
Require compliance and measure projects against organization-wide policies and standards
Education & Guidance
Offer development staff access to resources around the topics of secure programming and
deployment
Educate all personnel in the software life-cycle with role-specific guidance on secure
development
Mandate comprehensive security training and certify personnel for baseline knowledge

28

29

Objectives
Threat Assessment
Identify and understand high-level threats to the organization and individual projects
Increase accuracy of threat assessment and improve granularity of per-project understanding
Concretely tie compensating controls to each threat against internal and third-party software
Security Requirements
Consider security explicitly during the software requirements process
Increase granularity of security requirements derived from business logic and known risks
Mandate security requirements process for all software projects and third-party dependencies
Security Architecture
Insert consideration of proactive security guidance into the software design process
Direct the software design process toward known-secure services and secure-by-default designs
Formally control the software design process and validate utilization of secure components

30

31

Objectives
Design Review
Support ad hoc reviews of software design to ensure baseline mitigations for known risks
Offer assessment services to review software design against comprehensive best practices for
security
Require assessments and validate artifacts to develop detailed understanding of protection
mechanisms
Code Review
Opportunistically find basic code-level vulnerabilities and other high-risk security issues
Make code review during development more accurate and efficient through automation
Mandate comprehensive code review process to discover language-level and applicationspecific risks
Security Testing
Establish process to perform basic security tests based on implementation and software
requirements
Make security testing during development more complete and efficient through automation
Require application-specific security testing to ensure baseline security before deployment
32

33

Objectives
Vulnerability Management
Understand high-level plan for responding to vulnerability reports or incidents
Elaborate expectations for response process to improve consistency and communications
Improve analysis and data gathering within response process for feedback into proactive
planning
Environment Hardening
Understand baseline operational environment for applications and software components
Improve confidence in application operations by hardening the operating environment
Validate application health and status of operational environment against known best practices
Operational Enablement
Enable communications between development teams and operators for critical securityrelevant data
Improve expectations for continuous secure operations through provision of detailed
procedures
Mandate communication of security information and validate artifacts for completeness
34

How to implement
Software Security Assurance

How do Security Practices map to the

development stages
Initiate

Define

Design

Develop

Test

Implement

Operate

Strategy & Metrics

Policy & Compliance

Governance

Education & Guidance

Threat Assessment
Construction Security Requirements

Secure Architecture
Design Review
Code
Review

Verification

Security Testing
Vulnerability Management

Vulnerability Management
Environment
Hardening

Deployment

Operational Enablement
36

SSA Best Practice Approach

Key Principles
Rapid identification and remediation of critical vulnerabilities

Dont forget to fix or boil the ocean

Prevent introduction of new vulnerabilities

Integrate into existing SDLC with minimal process

changes
Provide flexibility to integrate with new SDL as it
rolls-out
Provide support for the developers

Training in the context of their own code base

Mentoring as required
Monitor and control

Automate gathering of vulnerability statistics and

publish
Enforcement via security gate
Continuous Improvement
37

SSA Best Practice Approach

Assess

Pilot

Assess

Establish
SSA Team

38

Roll-out

Mature

SSA Best Practice Approach

Assess

Pilot

Assess

Roll-out

Mature

Establish
SSA Team
Baseline assessment against SSA Maturity Model

Where you are

SSA End-State Vision

Where you want to be

SSA High-Level Roadmap

How you are going to get there

Implementation Plan for first phase

Next step

39

SSA Best Practice Approach

Assess

Pilot

Assess

Establish
SSA Team
Establish and manage the SA program

Requires senior management support

Define Policies
Application Security center of excellence

Support for the development teams

Define SDLC Controls

Establish initial security gates

Set-up Governance Module

Application Catalogue
Compliance Reporting
40

Roll-out

Mature

Example Security Policy

All developers should be trained in Secure Development techniques
At definition phase, risk assessment is required to classify the security
level of the app based on the data it is accessing and the attack
surface.
For high risk apps:
A security review is required as part of the design phase
All code additions/changes must be reviewed by somebody other than the
code author prior to release
All source code must be analyzed using Fortify Static Code Analyzer and
results audited weekly
All OWASP Top 10 vulnerabilities must be removed from the source code
prior to release

41

SSA Best Practice Approach

Pilot

Assess

Assess

Establish
SSA Team
Work with Pilot Application/Team

Fortify Infrastructure Set-Up

Base-line Audit

Fortify 360 Training

Mentoring
Capture Metrics
Business As Usual Process Integration

Remediation Support

Gain knowledge and expertise

Artefacts created are input to SSA Program

42

Roll-out

Mature

SSA Best Practice Approach

Assess

Pilot

Assess

Roll-out

Mature

Establish
SSA Team
Review Baseline assessment against SSA Maturity Model

Where you are

Review SSA End-State Vision

Where you want to be

Review SSA High-Level Roadmap

How you are going to get there

Review Implementation Plan for next phase

Next step

43

SSA Best Practice Approach

Assess

Pilot

Assess

Establish
SSA Team
Publicise SSA Program

Use Pilot team as a reference

Roll-out across enterprise prioritised by business risk

For each team

Base-line Audit
Fortify 360 Training
Mentoring
BAU Process Integration

Publish Metrics

44

Roll-out

Mature

SSA Best Practice Approach

Assess

Pilot

Assess

Roll-out

Mature

Establish
SSA Team
Increase maturity level across all functions
Raise the security bar
Establish Continuous Improvement Loop

45

Goals and benefits for Software Security

Assurance SSA
Assess

Pilot

Assess

Roll-out

Mature

Establish
SSA Team

A successful software security initiative leads to:

Measurably reduced risk from existing applications
A controlled process for preventing new vulnerabilities in
new releases
Reduced costs, delays, and wasted effort from emergency
bug fixes and incident clean-up
46

Thank you