©2009 Gotham Digital Science, LLC

Software Assurance with SAMM21 Sept 2009, SOURCE Barcelona

Matt Bartoldusmatt@gdssecurity.com

22

Introduction

o Meo Who Are You?

– Assessment (Penetration Tester; Security Auditors)

– QA Tester– Architect– Developer– Management– Business Owner– Consultant (two or more above)– Other

33

Agenda

o Overview of Software Security Issues• It is all so very young!

o Introducing SAMMo Uses of SAMMo SAMM Core Functions / Activitieso Use Case – SAMM to Measureo Use Case – SAMM to Implemento Future of SAMM

44

Overview of Software Security Issues

55

Software Security Issues

o Relatively Same Drivers Across Industries– Compliance

• PCI-DSS, SOX, DPA, etc

– Protection• Brand/reputation; from criminals (cyber-

crime)

– Governance• Function of good corporate governance

66

Software Security Issues

»What does ‘it’ look like?»How can we understand and manage

‘this’?»Do we have enough resources / skills to

do ‘this’?»How does ‘this’ fit in with the Security

function, shouldn’t they do ‘it’?»We are used to security projects that

implement tools or systems but now we need to change our processes?

» Isn’t there an established method or model for all ‘this’?

77

Young Discipline in a Young Industry

o BS7799 came out mid-90s o Shifting Focus within Industry

– PBX to Infrastructure to Database/Application

o PCI-DSS– CISP – 2001 – mention of change control as a

best practice item– PCI-DSS v1.2 – late 2008 – Requirement 6

88

So what is ‘this’ discipline called?

» Software Assurance» SSA - Software Security Assurance» SDL – Security Development Lifecycle» SDLC – to confuse everyone» sSDLC – secure Software Development

Lifecycle» SPLC – Secure Project Lifecycle» CLASP - Comprehensive, Lightweight

Application Security Process» 7 Touchpoints» SSF – System Security Framework

9

9

Other approaches to Security in the SDLC

1010

Motivation for a maturity model approach

o Changing an organisation is hardSimple, well-defined, measurable

preferred overcomplex, nuanced, ethereal

o Software security is a result of many activities– Combination of people, process, and automation

o There is no single formula for all organisations– Business risk from software depends on the nature of the

business

o An assurance program must be built over time– Organisations can’t change overnight. Use a phased

approach.

1111

The Software Assurance Maturity Model (SAMM)

1212

The Software Assurance Maturity Model

o Collaboratively written by experts within this field with review and feedback.

o Funded by Fortify Software

o Beta released in Aug 2008

o Creative Commons Attribution-Share Alike License (ie: open)

1313

Goals and Purpose

o To define building blocks for an assurance program

– Delineate all functions within an organisation that could be improved over time

o To allow organisations to create customized roadmaps

– Each organisation can choose the order and extent they improve each function

o To provide sample roadmaps for common types of organisations

– Each roadmap is a baseline that can be tweaked based on the specific concerns of a given organisation

1414

Uses for SAMM

o Guidanceo What needs to be done; general idea of skills and resource needs

o Measurement – Assurance program scorecardo Scores /metrics against activities against defined objectiveso Gaps against best practiceo Demonstrate quantifiable improvement

o Context / Framework for Businesso Communicate outside of security officeo Substantiate business requirement / riskso Set out a common understanding (get everyone on the same page)

o Build Implementation Roadmapo Use Guidanceo Measure o Put into business context (for funding and management support)

1515

What SAMM in NOT

o Prescriptive ‘howto’ document

o ‘One size fits all’ methodology

o Audit checklist for secure development

1616

SAMM Core Functions?

17

Business Functions and Security Practices

o Almost any organisation involved with software development must fulfill each of the Business Functions to some degree.

o Security Practices that are the independent silos for improvement that map underneath the Business Functions of software development.

17

1818

Conduct technical security awareness

training

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.

Create formal application security support

portal

Utilize security coaches to enhance project

teams

Establish role-based

examination/certification

Conduct role-specific application security

training

Build and maintain technical guidance

EG.1 EG.2 EG.3

Sec

urity

Pra

ctic

eO

bjec

tives

Act

iviti

es

For example, Education & Guidance:

1919

Policy and Compliance - PC

o Understand standards and compliance drivers of the organisation in order to meet their needs.

o Set out compliance gates

2020

Security Requirements - SR

o In order to plan for information security to be built in to software, it has to be detailed as requirements so they can be developed and tested in the same way as functional requirements

o Security requirements need to be tailored based on several risk factors such as the type of software being developed, data that will be processed or who will have access.

2121

Threat Assessment - TA

o Threat Assessment is an activity performed in order to focus on what the threats are to an application and likely attacks it may face once developed and deployed.

o Information security requirements are then matched up against the identified threats in order to determine whether such security requirements have addressed all identified threats appropriately.

2222

Design Review - DR

o The review of software designs and architecture models for potential security related deficiencies.

o The security requirements developed for the project as well as either the organisation’s security architecture or best practices are used as the basis for the review.

2323

Code Review – CR

o Source code analysis for information security related issues within code.

o Use checklists and sampling

o Automated tools for deeper inspection

2424

Security Testing – ST

o This activity is the one that is most recognisable in the industry as it has been performed for many years.

o Includes traditional penetration testing such as black-box and white box testing.

o SAMM also suggests performing more tailored testing based on test cases derived from the security requirements

2525

Using SAMM to Measure

2626

BSIMM

o Research conducted by Cigital and Fortify Software

o Based on activities undertaken by Adobe, EMC, Google, Microsoft, QUALCOMM, Wells Fargo, and the DTCC (and two unnamed organisations)

o Released March 2009o Creative Commons Attribution-Share Alike

License (ie: open)o http://bsi-mm.como EU based study in progress

2727

Measuring for Implementation – EU Financial Organisation

o Discussed software development and related security processes within the organisation

o Measured against SAMM activities

o Used CMMI type scores for each activity (think COBIT controls measurement)

2828

Using SAMM to Implement

2929

Implementing SAMM – Large EU Organisation

o Used measurement results to perform planning

o Determined goals based on measurement results and chose initial activities needed to implement

o Put all into context to talk with management for support

o Enabled us to see dependencies on other areas of the business

3030

31

About Gotham Digital Science

o Gotham Digital Science (GDS) is an international security services company specializing in Application and Network Infrastructure security, and Information Security Risk Management. GDS clients number among the largest financial services institutions and software development companies in the world.

o Offices in London and New York City