Software Assurance

Maturity Model
A guide to building security into software development
Version 1.1
For the latest version and additional info, please see the project web site at
http://www.opensamm.org

Acknowledgements
This document is currently maintained and updated through the OpenSAMM Project led by Pravir
Chandra ([email protected]), an independent software security consultant. Creation of the first draft
was made possible through funding from Fortify Software, Inc. This document is currently maintained
and updated through the OpenSAMM Project led by Pravir Chandra. Since the initial release of SAMM,
this project has become part of the Open Web Application Security Project (OWASP). Thanks also go
to many supporting organizations that are listed on back cover.

Contributors & Reviewers

This work would not be possible without the support of many individual reviewers and experts that
offered contributions and critical feedback.
• Fabio Arciniegas • Sebastien Deleersnyder • Carsten Huth • Andy Steingruebl
• Matt Bartoldus • Justin Derry • Bruce Jenkins • John Steven
• Jonathan Carter • Bart De Win • Daniel Kefer • Chad Thunberg
• Darren Challey • John Dickson • Yan Kravchenko • Colin Watson
• Brian Chess • Alexios Fakos • James McGovern • Jeff Williams
• Justin Clarke • David Fern • Matteo Meucci • Steven Wierckx
• Dan Cornell • Brian Glas • Jeff Payne
• Michael Craigue • Kuai Hinojosa • Gunnar Peterson
• Dinis Cruz • Jerry Hoff • Jeff Piper

This is an OWASP Project

OWASP
The Open Web Application Security Project

OWASP is an international organization and the OWASP Foundation supports OWASP efforts around
the world. OWASP is an open community dedicated to enabling organizations to conceive, develop,
acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents,
forums, and chapters are free and open to anyone interested in improving application security. We
advocate approaching application security as a people, process, and technology problem because the
most effective approaches to application security include improvements in all of these areas. We can be
found at https://www.owasp.org.

License
This work is licensed under the Creative Commons Attribution-Share Alike 4.0
License. To view a copy of this license, visit https://creativecommons.org/licenses/
bysa/4.0/ or send an email to [email protected]. or send a letter to
Creative Commons, PO Box 1866, Mountain View, CA 94042.
 Executive Summary

The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and
implement a strategy for software security that is tailored to the specific risks facing the organization. The re-
sources provided by SAMM will aid in:
✦
✦Evaluating an organization’s existing software security practices
✦
✦Building a balanced software security assurance program in well-defined iterations
✦
✦Demonstrating concrete improvements to a security assurance program
✦
✦Defining and measuring security-related activities throughout an organization

Version 1.1 of SAMM expands and restructures its predecessor into 4 complementary resources: this document
that describes the core SAMM model, the How To Guide that explains how to apply the model, the Quick Start
Guide which combines a set of best practices, and the toolbox that joins a number of useful tools. Furthermore,
a number of elements have been renamed to better represent their purpose.
SAMM was defined with flexibility in mind such that it can be utilized by small, medium, and large organizations
using any style of development. Additionally, this model can be applied organization-wide, for a single line-of-
business, or even for an individual project. Beyond these traits, SAMM was built on the following principles:
✦ organization’s behavior changes slowly over time - A successful software security program should be specified
✦An
in small iterations that deliver tangible assurance gains while incrementally working toward long-term goals.
✦
✦There is no single recipe that works for all organizations - A software security framework must be flexible and
allow organizations to tailor their choices based on their risk tolerance and the way in which they build and
use software.
✦
✦Guidance related to security activities must be prescriptive - All the steps in building and assessing an assurance
program should be simple, well-defined, and measurable. This model also provides roadmap templates for
common types of organizations.
The foundation of the model is built upon the core business functions of software development with security
practices tied to each (see diagram below).The building blocks of the model are the three maturity levels defined
for each of the twelve security practices. These define a wide variety of activities in which an organization could
engage to reduce security risks and increase software assurance. Additional details are included to measure suc-
cessful activity performance, understand the associated assurance benefits, estimate personnel and other costs.
As an open project, SAMM content shall always remain vendor-neutral and freely available for all to use.

- v1.1
SAMM Overview
Software
Development SAMM / softwAre AssurAnce MAturity Model  - v1.1

Business Functions
Governance Construction Operations

Security Practices
Strategy & Education & Security Design Security Environment
Metrics Guidance Requirements Review Testing Hardening

Policy & Threat Secure Implementation Issue Operational

Compliance Assessment Architecture Review Management Enablement

3
 Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Understanding the Model    6
Business Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Assessment worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

The Security Practices    22

Strategy & Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Policy & Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Education & Guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Threat Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Secure Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Design Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Implementation Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Security Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Issue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Environment Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Operational Enablement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
- v1.1
SAMM / softwAre AssurAnce MAturity Model  - v1.1

4
5
SAMM / softwAre AssurAnce MAturity Model  - v1.1 - v1.1
Understanding
the Model
A view of the big picture
SAMM is built upon a collection of Security Practices that are tied back into the core Business
Functions involved in software development. This section introduces those Business Functions
and the corresponding Security Practices for each. After covering the high-level framework, the
Maturity Levels for each Security Practice are also discussed briefly in order to paint a picture
of how each can be iteratively improved over time.
 Business Functions

At the highest level, SAMM defines four critical Business Functions. Each Business Function (listed below) is a category of
activities related to the nuts-and-bolts of software development, or stated another way, any organization involved with software
development must fulfill each of these Business Functions to some degree.
For each Business Function, SAMM defines three Security Practices. Each Security Practice (listed opposite) is an area of
security-related activities that build assurance for the related Business Function. So overall, there are twelve Security Practices that
are the independent silos for improvement that map underneath the Business Functions of software development.
For each Security Practice, SAMM defines three Maturity Levels as Objectives. Each Level within a Security Practice is char-
acterized by a successively more sophisticated Objective defined by specific activities and more stringent success metrics than the
previous level. Additionally, each Security Practice can be improved independently, though related activities can lead to optimizations.

Governance
Governance is centered on the processes and activities related to how an organization manages overall software development
activities. More specifically, this includes concerns that impact cross-functional groups involved in development as well as business
processes that are established at the organization level.

Strategy & Metrics involves the overall Policy & Compliance involves setting Education & Guidance involves increas-
strategic direction of the software assurance up a security, compliance, and audit control ing security knowledge amongst personnel in
program and instrumentation of processes framework throughout an organization to software development through training and
and activities to collect metrics about an or- achieve increased assurance in software un- guidance on security topics relevant to indi-
ganization’s security posture. der contruction and in operation. vidual job functions.
...more on page 10

Construction
Construction concerns the processes and activities related to how an organization defines goals and creates software within
development projects. In general, this will include product management, requirements gathering, high-level architecture specifica-
tion, detailed design, and implementation.

Threat Assessment involves accurately Security Requirements involves pro- Secure Architecture involves bolstering
identifying and characterizing potential attacks moting the inclusion of security-related re- the design process with activities to promote
upon an organization’s software in order to quirements during the software development secure-by-default designs and control over
better understand the risks and facilitate risk process in order to specify correct functional- technologies and frameworks upon which
management. ity from inception. software is built.
...more on page 12
SAMM / Understanding the Model - v1.1

Verification
Verification is focused on the processes and activities related to how an organization checks and tests artifacts produced through-
out software development. This typically includes quality assurance work such as testing, but it can also include other review and
evaluation activities.

Design Review involves inspection of the Implementation Review involves as- SecurityTesting involves testing the orga-
artifacts created from the design process to sessment of an organization’s source code to nization’s software in its runtime environment
ensure provision of adequate security mecha- aid vulnerability discovery and related mitiga- in order to both discover vulnerabilities and
nisms and adherence to an organization’s ex- tion activities as well as establish a baseline for establish a minimum standard for software
pectations for security. secure coding expectations. releases.
...more on page 14

8
 Operations
Operations entails the processes and activities related to how an organization manages release of software that has been cre-
ated. This can involve shipping products to end users, deploying products to internal or external hosts, and normal operations of
software in the runtime environment.

Issue Management involves establishing Environment Hardening involves Operational Enablement involves
consistent processes for managing internal implementing controls for the operating identifying and capturing security-relevant
and external vulnerability reports to limit ex- environment surrounding an organiza- information needed by an operator to
posure and gather data to enhance the secu- tion’s software to bolster the security properly configure, deploy, and run an or-
rity assurance program. posture of applications that have been ganization’s software.
deployed.
...more on page 16

Maturity Levels Notation

Each of the twelve Security Practices has three defined Maturity Levels and an implicit Throughout this document, the follow-
starting point at zero. The details for each level differs between the Practices, but they ing capitalized terms will be reserved
generally represent: words that refer to the SAMM com-
ponents defined in this section. If these

0 0 Implicit starting point representing the activities in the Practice being unfulfilled
terms appear without capitalization,
they should be interpreted based on

1
the their context:
1 Initial understanding and ad hoc provision of Security Practice
✦
✦Business Function also as Function

2 2 Increase efficiency and/or effectiveness of the Security Practice

✦
✦Security
✦
✦Maturity
Practice also as Practice
Level also as Level, Objective

3 3 Comprehensive mastery of the Security Practice at scale

Existing assurance programs might not always consist of activities that neatly fall on a boundary between Maturity Levels, e.g. an
organization that assesses to a Level 1 for a given Practice might also have additional activities in place but not such that Level 2 is
completed. For such cases, the organization’s score should be annotated with a “+” symbol to indicate there’s additional assurances
in place beyond those indicated by the Level obtained. For example, an organization that is performing all Level 1 Activities for Op-
erational Enablement as well as one Level 2 or 3 Activity would be assigned a “1+” score. Likewise, an organization performing all
Activities for a Security Practice, including some beyond the scope of SAMM, would be given a "3+" score.Operational Enablement
SAMM / Understanding the Model - v1.1

0 0+ 1 1+ 2 2+ 3 3+
assessment scores

9
 Governance
Description of Security Practices

Strategy & Metrics

The Strategy & Metrics (SM) Practice is focused on establishing the framework within an organization
for a software security assurance program. This is the most fundamental step in defining security goals
in a way that’s both measurable and aligned with the organization’s real business risk.
By starting with lightweight risk profiles, an organization grows into more advanced risk classification
schemes for application and data assets over time. With additional insight on relative risk measures,
an organization can tune its project-level security goals and develop granular roadmaps to make the
security program more efficient. At the more advanced levels within this Practice, an organization draws
upon many data sources, both internal and external, to collect metrics and qualitative feedback on the
security program. This allows fine tuning of cost outlay versus the realized benefit at the program level.

Policy & Compliance

The Policy & Compliance (PC) Practice is focused on understanding and meeting external legal and
regulatory requirements while also driving internal security standards to ensure compliance in a way
that’s aligned with the business purpose of the organization.
A driving theme for improvement within this Practice is focus on project-level audits that gather in-
formation about the organization’s behavior in order to check that expectations are being met. By
introducing routine audits that start out lightweight and grow in depth over time, organizational change
is achieved iteratively.
In a sophisticated form, provision of this Practice entails organization-wide understanding of both in-
ternal standards and external compliance drivers while also maintaining low-latency checkpoints with
project teams to ensure no project is operating outside expectations without visibility.

Education & Guidance

The Education & Guidance (EG) Practice is focused on arming personnel involved in the software life-
SAMM / Understanding the Model - v1.1

cycle with knowledge and resources to design, develop, and deploy secure software. With improved
access to information, project teams will be better able to proactively identify and mitigate the specific
security risks that apply to their organization.
One major theme for improvement across the Objectives is providing training for employees, either
through instructor-led sessions or computer-based modules. As an organization progresses, a broad
base of training is built by starting with developers and moving to other roles throughout the organiza-
tion, culminating with the addition of role-based certification to ensure comprehension of the material.
In addition to training, this Practice also requires pulling security-relevant information into guidelines
that serve as reference information to staff. This builds a foundation for establishing a baseline expec-
tation for security practices in your organization, and later allows for incremental improvement once
usage of the guidelines has been adopted.

10
 Governance
Activities overview

Strategy & Metrics ...more on page 24

SM 1 SM 2 SM 3
Objective Establish unified strategic Measure relative value of Align security expenditure
roadmap for software security data and software assets with relevant business
within the organization and choose risk tolerance indicators and asset value

Activities A. Estimate overall business A. Classify data and applications A. Conduct periodic industry-
risk profile based on business risk wide cost comparisons
B. Build and maintain assurance B. Establish and measure per- B. Collect metrics for
program roadmap classification security goals historic security spend

Policy & Compliance ...more on page 28

PC 1 PC 2 PC 3
Objective Understand relevant Establish security and Require compliance
governance and compliance compliance baseline and and measure projects
drivers to the organization understand per-project risks against organization-wide
policies and standards

Activities A. Identify and monitor external A. Build policies and standards A. Create compliance
compliance drivers for security and compliance gates for projects
B. Build and maintain B. Establish project audit practice B. Adopt solution for
compliance guidelines audit data collection

Education & Guidance ...more on page 32

1 2 3
SAMM / Understanding the Model - v1.1

EG EG EG

Objective Offer development staff Educate all personnel in Mandate comprehensive

access to resources around the software life-cycle with security training and
the topics of secure role-specific guidance on certify personnel for
programming and deployment secure development baseline knowledge

Activities A. Conduct technical security A. Conduct role-specific A. Create formal application

awareness training application security training security support portal
B. Build and maintain B. Utilize security coaches to B. Establish role-based
technical guidelines enhance project teams examination/certification

11
 Construction
Description of Security Practices

Threat Assessment

The Threat Assessment (TA) Practice is centered on identification and understanding the project-level
risks based on the functionality of the software being developed and characteristics of the runtime
environment. From details about threats and likely attacks against each project, the organization as a
whole operates more effectively through better decisions about prioritization of initiatives for security.
Additionally, decisions for risk acceptance are more informed, therefore better aligned to the business.
By starting with simple threat models and building to more detailed methods of threat analysis and
weighting, an organization improves over time. Ultimately, a sophisticated organization would maintain
this information in a way that is tightly coupled to the compensating factors and pass-through risks from
external entities. This provides greater breadth of understanding for potential downstream impacts
from security issues while keeping a close watch on the organization’s current performance against
known threats.

Security Requirements

The Security Requirements (SR) Practice is focused on proactively specifying the expected behavior
of software with respect to security. Through addition of analysis activities at the project level, security
requirements are initially gathered based on the high-level business purpose of the software.As an orga-
nization advances, more advanced techniques are used such as access control specifications to discover
new security requirements that may not have been initially obvious to development.
In a sophisticated form, provision of this Practice also entails pushing the security requirements of the
organization into its relationships with suppliers and then auditing projects to ensure all are adhering
to expectations with regard to specification of security requirements.

Secure Architecture

The Secure Architecture (SA) Practice is focused on proactive steps for an organization to design and
SAMM / Understanding the Model - v1.1

build secure software by default. By enhancing the software design process with reusable services and
components, the overall security risk from software development can be dramatically reduced.
Beginning from simple recommendations about software frameworks and explicit consideration of
secure design principles, an organization evolves toward consistently using design patterns for security
functionality. Also, activities encourage project teams to increased utilization of centralized security
services and infrastructure.
As an organization evolves over time, sophisticated provision of this Practice entails organizations build-
ing reference platforms to cover the generic types of software they build. These serve as frameworks
upon which developers can build custom software with less risk of vulnerabilities.

12
 Construction
Activities overview

Threat Assessment ...more on page 36

TA 1 TA 2 TA 3
Objective Identify and understand Increase accuracy of Concretely tie
high-level threats to threat assessment and compensating controls to
the organization and improve granularity of per- each threat against internal
individual projects project understanding and third-party software

Activities A. Build and maintain application- A. Build and maintain abuse- A. Explicitly evaluate risk from
specific threat models case models per project third-party components
B. Develop attacker profile B. Adopt a weighting system for B. Elaborate threat models
from software architecture measurement of threats with compensating controls

Security Requirements ...more on page 40

SR 1 SR 2 SR 3
Objective Consider security explicitly Increase granularity of security Mandate security
during the software requirements derived from requirements process for
requirements process business logic and known risks all software projects and
third-party dependencies

Activities A. Derive security requirements A. Build an access control matrix A. Build security requirements
from business functionality for resources and capabilities into supplier agreements
B. Evaluate security and compliance B. Specify security requirements B. Expand audit program for
guidance for requirements based on known risks security requirements

Secure Architecture ...more on page 44

1 2 3
SAMM / Understanding the Model - v1.1

SA SA SA

Objective Insert consideration Direct the software design Formally control the
of proactive security process toward known- software design process
guidance into the software secure services and secure- and validate utilization
design process by-default designs of secure components

Activities A. Maintain list of recommended A. Identify and promote security A. Establish formal reference
software frameworks services and infrastructure architectures and platforms
B. Explicitly apply security B. Identify security design B. Validate usage of frameworks,
principles to design patterns from architecture patterns, and platforms

13
 Verification
Description of Security Practices

Design Review

The Design Review (DR) Practice is focused on assessment of software design and architecture for se-
curity-related problems.This allows an organization to detect architecture-level issues early in software
development and thereby avoid potentially large costs from refactoring later due to security concerns.
Beginning with lightweight activities to build understanding of the security-relevant details about an
architecture, an organization evolves toward more formal inspection methods that verify completeness
in provision of security mechanisms. At the organization level, design review services are built and of-
fered to stakeholders.
In a sophisticated form, provision of this Practice involves detailed, data-level inspection of designs and
enforcement of baseline expectations for conducting design assessments and reviewing findings before
releases are accepted.

Implementation Review

The Implementation Review (IR) Practice is focused on inspection of software at the source code
and configuration level in order to find security vulnerabilities. Code-level vulnerabilities are generally
simple to understand conceptually, but even informed developers can easily make mistakes that leave
software open to potential compromise.
To begin, an organization uses lightweight checklists and for efficiency, only inspects the most critical
software modules. However, as an organization evolves it uses automation technology to dramatically
improve coverage and efficacy of implementation review activities.
Sophisticated provision of this Practice involves deeper integration of implementation review into the
development process to enable project teams to find problems earlier. This also enables organizations
to better audit and set expectations for implementation review findings before releases can be made.

Security Testing

The Security Testing (ST) Practice is focused on inspection of software in the runtime environment
SAMM / Understanding the Model - v1.1

in order to find security problems. These testing activities bolster the assurance case for software by
checking it in the same context in which it is expected to run, thus making visible operational miscon-
figurations or errors in business logic that are difficult to otherwise find.
Starting with penetration testing and high-level test cases based on the functionality of software, an
organization evolves toward usage of security testing automation to cover the wide variety of test cases
that might demonstrate a vulnerability in the system.
In an advanced form, provision of this Practice involves customization of testing automation to build
a battery of security tests covering application-specific concerns in detail. With additional visibility at
the organization level, security testing enables organizations to set minimum expectations for security
testing results before a project release is accepted.

14
 Verification
Activities overview

Design Review ...more on page 48

DR 1 DR 2 DR 3
Objective Support ad hoc reviews Offer assessment services Require assessments and
of software design to to review software design validate artifacts to develop
ensure baseline mitigations against comprehensive best detailed understanding of
for known risks practices for security protection mechanisms

Activities A. Identify software attack surface A. Inspect for complete provision A. Develop data-flow diagrams
B. Analyze design against known of security mechanisms for sensitive resources
security requirements B. Deploy design review B. Establish release gates
service for project teams for design review

Implementation Review ...more on page 52

IR 1 IR 2 IR 3
Objective Opportunistically find basic Make implementation Mandate comprehensive
code-level vulnerabilities and review during development implementation review
other high-risk security issues more accurate and efficient process to discover
through automation language-level and
application-specific risks

Activities A. Create review checklists from A. Utilize automated code A. Customize code analysis for
known security requirements analysis tools application-specific concerns
B. Perform point-review B. Integrate code analysis into B. Establish release gates
of high-risk code development process for code review

Security Testing ...more on page 56

1 2 3
SAMM / Understanding the Model - v1.1

ST ST ST

Objective Establish process to perform Make security testing Require application-

basic security tests based during development more specific security testing to
on implementation and complete and efficient ensure baseline security
software requirements through automation before deployment

Activities A. Derive test cases from known A. Utilize automated A. Employ application-specific
security requirements security testing tools security testing automation
B. Conduct penetration testing B. Integrate security testing B. Establish release gates
on software releases into development process for security testing

15
 Operations
Description of Security Practices

Issue Management

The Issue Management (IM) Practice is focused on the processes within an organization with respect
to handling issue reports and operational incidents. By having these processes in place, an organization’s
projects will have consistent expectations and increased efficiency for handling these events, rather than
chaotic and uninformed responses.
Starting from lightweight assignment of roles in the event of an incident, an organization grows into a
more formal incident response process that ensures visibility and tracking on issues that occur. Com-
munications are also improved to improve overall understanding of the processes.
In an advanced form, issue management involves thorough dissecting of incidents and issue reports to
collect detailed metrics and other root-cause information to feedback into the organization’s down-
stream behavior.

Environment Hardening

The Environment Hardening (EH) Practice is focused on building assurance for the runtime environ-
ment that hosts the organization’s software. Since secure operation of an application can be deterio-
rated by problems in external components, hardening this underlying infrastructure directly improves
the overall security posture of the software.
By starting with simple tracking and distributing of information about the operating environment to
keep development teams better informed, an organization evolves to scalable methods for managing
deployment of security patches and instrumenting the operating environment with early-warning de-
tectors for potential security issues before damage is done.
As an organization advances, the operating environment is further reviewed and hardened by deploy-
ment of protection tools to add layers of defenses and safety nets to limit damage in case any vulner-
abilities are exploited.

Operational Enablement

The Operational Enablement (OE) Practice is focused on gathering security critical information from
SAMM / Understanding the Model - v1.1

the project teams building software and communicating it to the users and operators of the software.
Without this information, even the most securely designed software carries undue risks since impor-
tant security characteristics and choices will not be known at a deployment site.
Starting from lightweight documentation to capture the most impactful details for users and operators,
an organization evolves toward building complete operational security guides that are delivered with
each release.
In an advanced form, operational enablement also entails organization-level checks against individual
project teams to ensure that information is being captured and shared according to expectations.

16
 Operations
Activities overview

Issue Management ...more on page 60

IM 1 IM 2 IM 3
Objective Understand high-level plan Elaborate expectations Improve analysis and data
for responding to issue for response process gathering within response
reports or incidents to improve consistency process for feedback into
and communications proactive planning

Activities A. Identify point of contact A. Establish consistent issue A. Conduct root cause
for security issues reponse process analysis for for issues
B. Create informal security B. Adopt a security issue B. Collect per-issue metrics
response team(s) disclosure process

Environment Hardening ...more on page 64

EH 1 EH 2 EH 3
Objective Understand baseline Improve confidence in Validate application health
operational environment application operations by and status of operational
for applications and hardening the operating environment against
software components environment known best practices

Activities A. Maintain operational A. Establish routine patch A. Identify and deploy relevant
environment specification management process operations protection tools
B. Identify and install critical B. Monitor baseline environment B. Expand audit program for
security upgrades and patches configuration status environment configuration

Operational Enablement ...more on page 68

1 2 3
SAMM / Understanding the Model - v1.1

OE OE OE

Objective Enable communications Improve expectations Mandate communication

between development teams for continuous secure of security information
and operators for critical operations through provision and validate artifacts
security-relevant data of detailed procedures for completeness

Activities A. Capture critical security A. Create per-release change A. Expand audit program for
information for deployment management procedures operational information
B. Document procedures for B. Maintain formal operational B. Perform code signing for
typical application alerts security guides application components

17
 Governance
Assessment worksheet

Strategy & Metrics Yes/No

✦ there a software security assurance program in place?
✦Is
✦
✦Are development staff aware of future
plans for the assurance program?
✦ the business stakeholders understand
✦Do
your organization’s risk profile?
✦
✦Are many of your applications and resources categorized by risk?
SM 1
✦
✦Are risk ratings used to tailor the required assurance activities?
✦
✦Does the organization know about what’s
required based on risk ratings?
✦ per-project data for the cost of assurance activities collected?
✦Is
SM 2
✦
✦Does your organization regularly compare your
security spend with that of other organizations?
SM 3
Policy & Compliance Yes/No
✦ project stakeholders know their project’s compliance status?
✦Do
✦
✦Are compliance requirements specifically

1
considered by project teams?
PC
✦
✦Does the organization utilize a set of policies and
standards to control software development?
✦
✦Are project teams able to request an audit for
compliance with policies and standards?
✦
✦Are projects periodically audited to ensure a baseline
PC 2
of compliance with policies and standards?
✦
✦Does the organization systematically use audits to

3
collect and control compliance evidence?
PC

Education & Guidance Yes/No

✦
✦Have developers been given high-level security awareness training?
SAMM / Understanding the Model - v1.1

✦
✦Does each project team understand where to find

1
secure development best-practices and guidance?
EG
✦
✦Are those involved in the development process given
role-specific security training and guidance?
✦
✦Are stakeholders able to pull in security

2
coaches for use on projects?
EG
✦ security-related guidance centrally controlled and
✦Is
consistently distributed throughout the organization?
✦
✦Are developers tested to ensure a baseline skill-

3
set for secure development practices?
EG

18
 Construction
Assessment worksheet

Threat Assessment Yes/No

✦ projects in your organization consider
✦Do
and document likely threats?
✦
✦Does your organization understand and

1
document the types of attackers it faces?
TA
✦ project teams regularly analyze functional
✦Do
requirements for likely abuses?
✦ project teams use a method of rating
✦Do
threats for relative comparison?

2
✦
✦Are stakeholders aware of relevant threats and ratings?
TA
✦ project teams specifically consider risk from external software?
✦Do
✦
✦Are the majority of the protection mechanisms and

3
controls captured and mapped back to threats?
TA

Security Requirements Yes/No

✦ project teams specify security
✦Do
requirements during development?
✦ project teams pull requirements from best
✦Do

1
practices and compliance guidance?
SR
✦ stakeholders review access control
✦Do
matrices for relevant projects?
✦ project teams specify requirements based on
✦Do
feedback from other security activities?
✦ stakeholders review vendor agreements
✦Do
SR 2
for security requirements?
✦
✦Are audits performed against the security
requirements specified by project teams?
SR 3
Secure Architecture Yes/No
✦
✦Are project teams provided with a list of
recommended third-party components?
SAMM / Understanding the Model - v1.1

✦
✦Are project teams aware of secure design principles

1
and do they apply them consistently?
SA
✦ you advertise shared security services
✦Do
with guidance for project teams?
✦
✦Are project teams provided with prescriptive design
patterns based on their application architecture?
✦ project teams build software from centrally-
✦Do
SA 2
controlled platforms and frameworks?
✦
✦Are project teams audited for the use of
secure architecture components?
SA 3
19
 Verification
Assessment worksheet

Design Review Yes/No

✦ project teams document the attack
✦Do
perimeter of software designs?
✦ project teams check software designs
✦Do

1
against known security risks?
DR
✦ project teams specifically analyze design
✦Do
elements for security mechanisms?
✦
✦Are project stakeholders aware of how to
obtain a formal secure design review?
✦
✦Does the secure design review process
DR 2
incorporate detailed data-level analysis?
✦
✦Does a minimum security baseline exist
for secure design review results?
DR 3
Implementation Review Yes/No
✦ project teams have review checklists based
✦Do
on common security related problems?

1
✦ project teams review selected high-risk code?
✦Do
IR
✦
✦Can project teams access automated code
analysis tools to find security problems?
✦ stakeholders consistently review results from code reviews?
✦Do

✦ project teams utilize automation to check code

✦Do
against application-specific coding standards?
IR 2
3
✦
✦Does a minimum security baseline exist for code review results?
IR

Security Testing Yes/No

✦ projects specify security testing based
✦Do
on defined security requirements?
SAMM / Understanding the Model - v1.1

✦ penetration testing performed on high

✦Is
risk projects prior to release?
✦
✦Are stakeholders aware of the security test status prior to release?

✦ projects use automation to evaluate security test cases?

✦Do
ST 1
✦ projects follow a consistent process to evaluate
✦Do
and report on security tests to stakeholders?
✦
✦Are security test cases comprehensively
ST 2
generated for application-specific logic?

3
✦
✦Does a minimum security baseline exist for security testing?
ST
20
 Operations
Assessment worksheet

Issue Management Yes/No

✦ projects have a point of contact for security issues or incidents?
✦Do
✦
✦Does your organization have an assigned security response team?
✦
✦Are project teams aware of their security point(s)

1
of contact and response team(s)?
IM
✦
✦Does the organization utilize a consistent process
for incident reporting and handling?
✦
✦Are project stakeholders aware of relevant security

2
disclosures related to their software projects?
IM
✦
✦Are incidents inspected for root causes to
generate further recommendations?
✦ projects consistently collect and report
✦Do
data and metrics related to incidents?
IM 3
Environment Hardening Yes/No
✦ projects document operational
✦Do
environment security requirements?
✦ projects check for security updates to
✦Do

1
third-party software components?
EH
✦ a consistent process used to apply upgrades
✦Is
and patches to critical dependencies?
✦ projects leverage automation to check
✦Do

2
application and environment health?
EH
✦
✦Are stakeholders aware of options for additional tools
to protect software while running in operations?
✦
✦Does a minimum security baseline exist for
environment health (versioning, patching, etc)?
EH 3
Operational Enablement Yes/No
✦
✦Are security notes delivered with each software release?
SAMM / Understanding the Model - v1.1

✦
✦Are security-related alerts and error conditions

1
documented on a per-project basis?
OE
✦ projects utilize a change management
✦Do
process that’s well understood?
✦ project teams deliver an operational security
✦Do
guide with each product release?
✦
✦Are project releases audited for appropriate
OE 2
operational security information?
✦ code signing routinely performed on software
✦Is
components using a consistent process?
OE 3
21
The Security
Practices
An explanation of the details
This section defines the building blocks of SAMM, the Maturity Levels under each Security
Practice. For each Practice, the three Levels are covered in a summary table. Following that, the
description for each Level includes detailed explanations of the required activities, results an or-
ganization can expect from attaining the Level, success metrics to gauge performance, required
ongoing personnel investment, and additional associated costs.
 Strategy & Metrics

SM 1 SM 2 SM 3
Objective Establish unified strategic Measure relative value of Align security expenditure
roadmap for software security data and software assets with relevant business
within the organization and choose risk tolerance indicators and asset value

Activities A. Estimate overall business A. Classify data and applications A. Conduct periodic industry-
risk profile based on business risk wide cost comparisons
B. Build and maintain assurance B. Establish and measure per- B. Collect metrics for
program roadmap classification security goals historic security spend

Assessment ✦✦Is there a software security ✦✦Are many of your applications and ✦✦Is per-project data for the cost
assurance program in place? resources categorized by risk? of assurance activities collected?
✦✦Are development staff ✦✦Are risk ratings used to tailor the ✦✦Does your organization
aware of future plans for required assurance activities? regularly compare your
the assurance program? ✦✦Does the organization security spend with that
✦✦Do the business stakeholders know about what’s required of other organizations?
understand your based on risk ratings?
organization’s risk profile?

Results ✦✦Concrete list of the most ✦✦Customized assurance plans ✦✦Information to make informed
critical business-level risks per project based on core case-by-case decisions on
caused by software value to the business security expenditures
✦✦Tailored roadmap that ✦✦Organization-wide understanding ✦✦Estimates of past loss
addresses the security of security-relevance of data due to security issues
needs for your organization and application assets ✦✦Per-project consideration
with minimal overhead ✦✦Better informed stakeholders of security expense
✦✦Organization-wide understanding with respect to understanding versus loss potential
of how the assurance program and accepting risks ✦✦Industry-wide due diligence
will grow over time with regard to security
SAMM / The Security Practices - v1.1

24
 Strategy & Metrics SM 1
Establish unified strategic roadmap for software security within the organization

Activities
A. Estimate overall business risk profile Assessment
Interview business owners and stakeholders and create a list of worst-case scenarios across ✦✦Is there a software security
the organization’s various application and data assets. Based on the way in which your assurance program in place?
organization builds, uses, or sells software, the list of worst-case scenarios can vary widely, ✦✦Are development staff aware of future
but common issues include data theft or corruption, service outages, monetary loss, reverse plans for the assurance program?
engineering, account compromise, etc. ✦✦Do the business stakeholders understand
your organization’s risk profile?
After broadly capturing worst-case scenario ideas, collate and select the most important
based on collected information and knowledge about the core business. Any number can be Results
selected, but aim for at least 3 and no more than 7 to make efficient use of time and keep ✦✦Concrete list of the most critical
the exercise focused. business-level risks caused by software
Elaborate a description of each of the selected items and document details of contributing ✦✦Tailored roadmap that addresses the
worst-case scenarios, potential contributing factors, and potential mitigating factors for the security needs for your organization
organization. with minimal overhead
✦✦Organization-wide understanding
The final business risk profile should be reviewed with business owners and other stakehold- of how the assurance program
ers for understanding. will grow over time

Success Metrics
B. Build and maintain assurance program roadmap ✦✦>80% of stakeholders briefed on
Understanding the main business risks to the organization, evaluate the current performance business risk profile in past 6 months
of the organization against each the twelve Practices. Assign a score for each Practice from ✦✦>80% of staff briefed on assurance
1, 2, or 3 based on the corresponding Objective if the organization passes all the cumulative program roadmap in past 3 months
success metrics. If no success metrics are being met, assign a score of 0 to the Practice. ✦✦>1 assurance program strategy
session in past 3 months
Once a good understanding of current status is obtained, the next goal is to identify the Prac-
tices that will be improved in the next iteration. Select them based on business risk profile, Costs
other business drivers, compliance requirements, budget tolerance, etc. Once Practices are ✦✦Buildout and maintenance
selected, the goals of the iteration are to achieve the next Objective under each. of business risk profile
Iterations of improvement on the assurance program should be approximately 3-6 months, ✦✦Quarterly evaluation of
but an assurance strategy session should take place at least every 3 months to review prog- assurance program
ress on activities, performance against success metrics and other business drivers that may
Personnel
require program changes.
✦✦Developers
✦✦Architects
✦✦Managers
✦✦Business Owners
✦✦QA Testers
SAMM / The Security Practices - v1.1

✦✦Security Auditor

Related Levels
✦✦Policy & Compliance - 1
✦✦Threat Assessment - 1
✦✦Security Requirements - 2

25
 SM 2 Strategy & Metrics
Measure relative value of data and software assets and choose risk tolerance

Activities
Assessment
A. Classify data and applications based on business risk
✦✦Are many of your applications and
resources categorized by risk? Establish a simple classification system to represent risk-tiers for applications. In its simplest
✦✦Are risk ratings used to tailor the form, this can be a High/Medium/Low categorization. More sophisticated classifications can
required assurance activities? be used, but there should be no more than seven categories and they should roughly repre-
✦✦Does the organization know about sent a gradient from high to low impact against business risks.
what’s required based on risk ratings? Working from the organization’s business risk profile, create project evaluation criteria that
maps each project to one of the risk categories. A similar but separate classification scheme
Results
should be created for data assets and each item should be weighted and categorized based
✦✦Customized assurance plans per project on potential impact to business risks.
based on core value to the business
✦✦Organization-wide understanding Evaluate collected information about each application and assign each a risk category based
of security-relevance of data upon overall evaluation criteria and the risk categories of data assets in use. This can be
and application assets done centrally by a security group or by individual project teams through a customized
✦✦Better informed stakeholders questionnaire to gather the requisite information.
with respect to understanding An ongoing process for application and data asset risk categorization should be established
and accepting risks
to assign categories to new assets and keep the existing information updated at least bian-
Success Metrics nually.
✦✦>90% applications and data assets
evaluated for risk classification
in past 12 months
B. Establish and measure per-classification security goals
✦✦>80% of staff briefed on relevant With a classification scheme for the organization’s application portfolio in place, direct secu-
application and data risk rity goals and assurance program roadmap choices can be made more granular.
ratings in past 6 months
The assurance program’s roadmap should be modified to account for each application risk
✦✦>80% of staff briefed on
category by specifying emphasis on particular Practices for each category. For each iteration
relevant assurance program
roadmap in past 3 months
of the assurance program, this would typically take the form of prioritizing more higher-level
Objectives on the highest risk application tier and progressively less stringent Objectives for
Costs lower/other categories.
✦✦Buildout or license of application and This process establishes the organization’s risk tolerance since active decisions must be
data risk categorization scheme made as to what specific Objectives are expected of applications in each risk category. By
✦✦Program overhead from more choosing to keep lower risk applications at lower levels of performance with respect to the
granular roadmap planning Security Practices, resources are saved in exchange for acceptance of a weighted risk. How-
ever, it is not necessary to arbitrarily build a separate roadmap for each risk category since
Personnel
that can leads to inefficiency in management of the assurance program itself.
✦✦Architects
✦✦Managers
✦✦Business Owners
SAMM / The Security Practices - v1.1

✦✦Security Auditor

Related Levels
✦✦Policy & Compliance - 2
✦✦Threat Assessment - 2
✦✦Design Review - 2

26
 Strategy & Metrics SM 3
Align security expenditure with relevant business indicators and asset value

Activities
Assessment
A. Conduct periodic industry-wide cost comparisons
✦✦Is per-project data for the cost of
Research and gather information about security costs from intra-industry communication assurance activities collected?
forums, business analyst and consulting firms, or other external sources. In particular, there ✦✦Does your organization regularly
are a few key factors that need to be identified. compare your security spend with
First, use collected information to identify the average amount of security effort being ap- that of other organizations?
plied by similar types of organizations in your industry. This can be done either top-down Results
from estimates of total percentage of budget, revenue, etc. or it can be done bottom-up by
identifying security-related activities that are considered normal for your type of organiza- ✦✦Information to make informed case-by-
case decisions on security expenditures
tion. Overall, this can be hard to gauge for certain industries, so collect information from as
✦✦Estimates of past loss due
many relevant sources as are accessible.
to security issues
The next goal of researching security costs is to determine if there are potential cost savings ✦✦Per-project consideration of security
on third-party security products and services that your organization currently uses. When expense versus loss potential
weighing the decision of switching vendors, account for hidden costs such as retraining staff ✦✦Industry-wide due diligence
or other program overhead. with regard to security
Overall, these cost-comparison exercises should be conducted at least annually prior to the Success Metrics
subsequent assurance program strategy session. Comparison information should be pre-
✦✦>80% of projects reporting
sented to stakeholders in order to better align the assurance program with the business.
security costs in past 3 months
✦✦>1 industry-wide cost
comparison in past 1 year
B. Collect metrics for historic security spend
✦✦>1 historic security spend
Collect project-specific information on the cost of past security incidents. For instance, time evaluation in past 1 year
and money spent in cleaning up a breach, monetary loss from system outages, fines and fees
to regulatory agencies, project-specific one-off security expenditures for tools or services, Costs
etc. ✦✦Buildout or license industry
Using the application risk categories and the respective prescribed assurance program road- intelligence on security programs
maps for each, a baseline security cost for each application can be initially estimated from the ✦✦Program overhead from cost
estimation, tracking, and evaluation
costs associated with the corresponding risk category.
Combine the application-specific cost information with the general cost model based on risk Personnel
category, and then evaluate projects for outliers, i.e. sums disproportionate to the risk rating. ✦✦Architects
These indicate either an error in risk evaluation/classification or the necessity to tune the ✦✦Managers
organization’s assurance program to address root causes for security cost more effectively. ✦✦Business Owners
The tracking of security spend per project should be done quarterly at the assurance pro- ✦✦Security Auditor
gram strategy session, and the information should be reviewed and evaluated by stakehold-
ers at least annually. Outliers and other unforeseen costs should be discussed for potential Related Levels
SAMM / The Security Practices - v1.1

affect on assurance program roadmap. ✦✦Issue Management - 1

27
 Policy & Compliance

PC 1 PC 2 PC 3
Objective Understand relevant Establish security and Require compliance
governance and compliance compliance baseline and and measure projects
drivers to the organization understand per-project risks against organization-wide
policies and standards

Activities A. Identify and monitor external A. Build policies and standards A. Create compliance
compliance drivers for security and compliance gates for projects
B. Build and maintain B. Establish project audit practice B. Adopt solution for
compliance guidelines audit data collection

Assessment ✦✦Do project stakeholders know ✦✦Does the organization utilize a ✦✦Are projects periodically
their project’s compliance status? set of policies and standards to audited to ensure a
✦✦Are compliance requirements control software development? baseline of compliance with
specifically considered ✦✦Are project teams able to policies and standards?
by project teams? request an audit for compliance ✦✦Does the organization
with policies and standards? systematically use audits
to collect and control
compliance evidence?

Results ✦✦Increased assurance for ✦✦Awareness for project teams ✦✦Organization-level visibility
handling third-party audit regarding expectations for of accepted risks due
with positive outcome both security and compliance to non-compliance
✦✦Alignment of internal ✦✦Business owners that better ✦✦Concrete assurance
resources based on priority understand specific compliance for compliance at
of compliance requirements risks in their product lines the project level
✦✦Timely discovery of evolving ✦✦Optimized approach ✦✦Accurate tracking of past
regulatory requirements that for efficiently meeting project compliance history
affect your organization compliance with opportunistic ✦✦Efficient audit process
security improvement leveraging tools to
cut manual effort
SAMM / The Security Practices - v1.1

28
 Policy & Compliance PC 1
Understand relevant governance and compliance drivers to the organization

Activities
Assessment
A. Identify and monitor external compliance drivers
✦✦Do project stakeholders know their
While an organization might have a wide variety of compliance requirements, this activity is project’s compliance status?
specifically oriented around those that either directly or indirectly affect the way in which ✦✦Are compliance requirements specifically
the organization builds or uses software and/or data. Leverage internal staff focused on considered by project teams?
compliance if available.
Results
Based on the organization’s core business, conduct research and identify third-party regula-
tory standards with which compliance is required or considered an industry norm. Possibili- ✦✦Increased assurance for handling third-
ties include the Sarbanes-Oxley Act (SOX), the Payment Card Industry Data Security Stan- party audit with positive outcome
dards (PCI-DSS), the Health Insurance Portability and Accountability Act (HIPAA), etc. After ✦✦Alignment of internal resources based
on priority of compliance requirements
reading and understanding each third-party standard, collect specific requirements related to
software and data and build a consolidated list that maps each driver (third-party standard) ✦✦Timely discovery of evolving
regulatory requirements that
to each of its specific requirements for security. At this stage, try to limit the amount of re-
affect your organization
quirements by dropping anything considered optional or only recommended.
At a minimum, conduct research at least biannually to ensure the organization is keeping up- Success Metrics
dated on changes to third-party standards. Depending upon the industry and the importance ✦✦>1 compliance discovery
of compliance, this activity can vary in effort and personnel involvement, but should always meeting in past 6 months
be done explicitly. ✦✦Compliance checklist completed
and updated within past 6 months
✦✦>1 compliance review meeting with
B. Build and maintain compliance guidelines stakeholders in past 6 months
Based upon the consolidated list of software and data-related requirements from compliance Costs
drivers, elaborate the list by creating a corresponding response statement to each require-
✦✦Initial creation and ongoing
ment. Sometimes called control statements, each response should capture the concept of
maintenance of compliance checklist
what the organization does to ensure the requirement is met (or to note why it does not
apply). Personnel
Since typical audit practice often involves checking a control statement for sufficiency and ✦✦Architects
then measuring the organization against the control statement itself, it is critical that they ✦✦Managers
accurately represent actual organizational practices. Also, many requirements can be met by ✦✦Business Owners
instituting simple, lightweight process elements to cover base-line compliance prior to evolv-
ing the organization for better assurance down the road. Related Levels
Working from the consolidated list, identify major gaps to feed the future planning efforts ✦✦Strategy & Metrics - 1
with regard to building the assurance program. Communicate information about compliance
gaps with stakeholders to ensure awareness of the risk from non-compliance.
At a minimum, update and review control statements with stakeholders at least biannually.
Depending on the number of compliance drivers, it may make sense to perform updates
SAMM / The Security Practices - v1.1

more often.

29
 PC 2 Policy & Compliance
Establish security and compliance baseline and understand per-project risks

Activities
Assessment
A. Build policies and standards for security and compliance
✦✦Does the organization utilize a
set of policies and standards to Beginning with a current compliance guidelines, review regulatory standards and note any
control software development? optional or recommended security requirements. Also, the organization should conduct a
✦✦Are project teams able to request small amount of research to discover any potential future changes in compliance require-
an audit for compliance with ments that are relevant.
policies and standards?
Augment the list with any additional requirements based on known business drivers for se-
Results curity. Often it is simplest to consult existing guidance being provided to development staff
and gather a set of best practices.
✦✦Awareness for project teams
regarding expectations for both Group common/similar requirements and rewrite each group as more generalized/simplified
security and compliance statements that meet all the compliance drivers as well as provide some additional security
✦✦Business owners that better value. Work through this process for each grouping with the goal of building a set of inter-
understand specific compliance nal policies and standards that can be directly mapped back to compliance drivers and best
risks in their product lines practices.
✦✦Optimized approach for efficiently
meeting compliance with opportunistic
It is important for the set of policies and standards to not contain requirements that are
security improvement too difficult or excessively costly for project teams to comply. A useful heuristic is that ap-
proximately 80% of projects should be able to comply with minimal disruption. This requires
Success Metrics a good communications program being set up to advertise the new policies/standards and
✦✦>75% of staff briefed on policies assist teams with compliance if needed.
and standards in past 6 months
✦✦>80% stakeholders aware of compliance
status against policies and standards B. Establish project audit practice
Create a simple audit process for project teams to request and receive an audit against inter-
Costs
nal standards. Audits are typically performed by security auditors but can also be conducted
✦✦Internal standards buildout or license by security-savvy staff as long as they are knowledgeable about the internal standards.
✦✦Per-project overhead from compliance
with internal standards and audit Based upon any known business risk indicators, projects can be prioritized concurrently with
audit queue triage such that high-risk software is assessed sooner or more frequently. Ad-
Personnel ditionally, low-risk projects can have internal audit requirements loosened to make the audit
✦✦Architects practice more cost-effective.
✦✦Managers Overall, each active project should undergo an audit at least biannually. Generally, subse-
✦✦Security Auditors quent audits after the initial will be simpler to perform if sufficient audit information about
the application is retained.
Related Levels
Advertise this service to business owners and other stakeholders so that they may request
✦✦Education & Guidance - 1 & 3
an audit for their projects. Detailed pass/fail results per requirement from the internal
✦✦Strategy & Metrics - 2 standards should be delivered to project stakeholders for evaluation. Where practical, audit
SAMM / The Security Practices - v1.1

✦✦Security Requirements - 1 & 3 results should also contain explanations of impact and remediation recommendations.
✦✦Secure Architecture - 3
✦✦Implementation Review - 3
✦✦Design Review - 3
✦✦Environment Hardening - 3

30
 Policy & Compliance PC 3
Require compliance and measure projects against organization-wide policies and standards

Activities
Assessment
A. Create compliance gates for projects
✦✦Are projects periodically audited
Once an organization has established internal standards for security, the next level of en- to ensure a baseline of compliance
forcement is to set particular points in the project life-cycle where a project cannot pass with policies and standards?
until it is audited against the internal standards and found to be in compliance. ✦✦Does the organization systematically
Usually, the compliance gate is placed at the point of software release such that they are not use audits to collect and control
compliance evidence?
allowed to publish a release until the compliance check is passed. It is important to provide
enough time for the audit to take place and remediation to occur, so generally the audit Results
should begin earlier, for instance when a release is given to QA.
✦✦Organization-level visibility of accepted
Despite being a firm compliance gate, legacy or other specialized projects may not be able to risks due to non-compliance
comply, so an exception approval process must also be created. No more than about 20% ✦✦Concrete assurance for
of all projects should have exception approval. compliance at the project level
✦✦Accurate tracking of past
project compliance history
B. Adopt solution for audit data collection ✦✦Efficient audit process leveraging
Organizations conducting regular audits of project teams generate a large amount of audit tools to cut manual effort
data over time. Automation should be utilized to assist in automated collection, manage col- Success Metrics
lation for storage and retrieval, and to limit individual access to sensitive audit data.
✦✦>80% projects in compliance with
For many concrete requirements from the internal standards, existing tools such as code policies and standards as seen by audit
analyzers, application penetration testing tools, monitoring software, etc. can be customized ✦✦<50% time per audit as
and leveraged to automate compliance checks against internal standards. The purpose of compared to manual
automating compliance checks is to both improve efficiency of audit as well as enable more
staff to self-check for compliance before a formal audit takes place. Additionally, automated Costs
checks are less error-prone and allow for lower latency on discovery of problems. ✦✦Buildout or license tools to automate
audit against internal standards
Information storage features should allow centralized access to current and historic audit
data per project. Automation solutions must also provide detailed access control features to ✦✦Ongoing maintenance of audit
gates and exception process
limit access to approved individuals with valid business purpose for accessing the audit data.
All instructions and procedures related to accessing compliance data as well as requesting Personnel
access privileges should be advertised to project teams. Additional time may be initially re- ✦✦Developers
quired from security auditors to bootstrap project teams. ✦✦Architects
✦✦Managers

Related Levels
✦✦Education & Guidance - 3
✦✦Implementation Review - 2
SAMM / The Security Practices - v1.1

✦✦Security Testing - 2

31
 Education & Guidance

EG 1 EG 2 EG 3
Objective Offer development staff Educate all personnel in Mandate comprehensive
access to resources around the software life-cycle with security training and
the topics of secure role-specific guidance on certify personnel for
programming and deployment secure development baseline knowledge

Activities A. Conduct technical security A. Conduct role-specific A. Create formal application

awareness training application security training security support portal
B. Build and maintain B. Utilize security coaches to B. Establish role-based
technical guidelines enhance project teams examination/certification

Assessment ✦✦Have developers been given high- ✦✦Are those involved in ✦✦Is security-related guidance
level security awareness training? the development process centrally controlled and
✦✦Does each project team given role-specific security consistently distributed
understand where to find training and guidance? throughout the organization?
secure development best- ✦✦Are stakeholders able to ✦✦Are developers tested
practices and guidance? pull in security coaches to ensure a baseline
for use on projects? skill-set for secure
development practices?

Results ✦✦Increased developer awareness ✦✦End-to-end awareness of the ✦✦Efficient remediation of

on the most common issues that leads to security vulnerabilities in both ongoing
problems at the code level vulnerabilities at the product, and legacy code bases
✦✦Maintain software with design, and code levels ✦✦Quickly understand and
rudimentary security best- ✦✦Build plans to remediate mitigate against new
practices in place vulnerabilities and design attacks and threats
✦✦Set baseline for security know- flaws in ongoing projects ✦✦Judge security-savvy of
how among technical staff ✦✦Enable qualitative security staff and measure against
✦✦Enable qualitative security checks checkpoints at requirements, a common standard
for baseline security knowledge design, and development stages ✦✦Establish fair incentives
✦✦Deeper understanding of toward security awareness
security issues encourages more
proactive security planning
SAMM / The Security Practices - v1.1

32
 Education & Guidance EG 1
Offer development staff access to resources around the topics of secure programming and deployment

Activities
Assessment
A. Conduct technical security awareness training
✦✦Have developers been given high-
Either internally or externally sourced, conduct security training for technical staff that cov- level security awareness training?
ers the basic tenets of application security. Generally, this can be accomplished via instructor- ✦✦Does each project team understand
led training in 1-2 days or via computer-based training with modules taking about the same where to find secure development
amount of time per developer. best-practices and guidance?
Course content should cover both conceptual and technical information. Appropriate topics Results
include high-level best practices surrounding input validation, output encoding, error han-
dling, logging, authentication, authorization. Additional coverage of commonplace software ✦✦Increased developer awareness on the
most common problems at the code level
vulnerabilities is also desirable such as a Top 10 list appropriate to the software being devel-
✦✦Maintain software with rudimentary
oped (web applications, embedded devices, client-server applications, back-end transaction
security best-practices in place
systems, etc.). Wherever possible, use code samples and lab exercises in the specific pro-
✦✦Set baseline for security know-
gramming language(s) that applies.
how among technical staff
To rollout such training, it is recommended to mandate annual security training and then ✦✦Enable qualitative security checks
hold courses (either instructor-led or computer-based) as often as required based on devel- for baseline security knowledge
opment head-count.
Success Metrics
✦✦>50% development staff briefed on
B. Build and maintain technical guidelines security issues within past 1 year
For development staff, assemble a list of approved documents, web pages, and technical notes ✦✦>75% senior development/
architect staff briefed on security
that provide technology-specific security advice. These references can be assembled from
issues within past 1 year
many publicly available resources on the Internet. In cases where very specialized or pro-
✦✦Launch technical guidance within
prietary technologies permeate the development environment, utilize senior, security-savvy
3 months of first training
staff to build security notes over time to create such a knowledge base in an ad hoc fashion.
Ensure management is aware of the resources and briefs oncoming staff about their ex- Costs
pected usage.Try to keep the guidelines lightweight and up-to-date to avoid clutter and irrel- ✦✦Training course buildout or license
evance. Once a comfort-level has been established, they can be used as a qualitative checklist ✦✦Ongoing maintenance of
to ensure that the guidelines have been read, understood, and followed in the development technical guidance
process.
Personnel
✦✦Developers
✦✦Architects

Related Levels
✦✦Policy & Compliance - 2
✦✦Security Requirements - 1
SAMM / The Security Practices - v1.1

✦✦Secure Architecture - 1

33
 EG 2 Education & Guidance
Educate all personnel in the software life-cycle with role-specific guidance on secure development

Activities
Assessment
A. Conduct role-specific application security training
✦✦Are those involved in the development
process given role-specific Conduct security training for staff that highlights application security in the context of each
security training and guidance? role’s job function. Generally, this can be accomplished via instructor-led training in 1-2 days
✦✦Are stakeholders able to pull in or via computer-based training with modules taking about the same amount of time per
security coaches for use on projects? person.

Results For managers and requirements specifiers, course content should feature security require-
ments planning, vulnerability and incident management, threat modeling, and misuse/abuse
✦✦End-to-end awareness of the issues case design.
that leads to security vulnerabilities at
the product, design, and code levels Tester and auditor training should focus on training staff to understand and more effectively
✦✦Build plans to remediate vulnerabilities analyze software for security-relevant issues. As such, it should feature techniques for code
and design flaws in ongoing projects review, architecture and design analysis, runtime analysis, and effective security test planning.
✦✦Enable qualitative security Expand technical training targeting developers and architects to include other relevant topics
checkpoints at requirements,
such as security design patterns, tool-specific training, threat modeling and software assess-
design, and development stages
ment techniques.
✦✦Deeper understanding of
security issues encourages more To rollout such training, it is recommended to mandate annual security awareness training
proactive security planning and periodic specialized topics training. Course should be available (either instructor-led or
computer-based) as often as required based on head-count per role.
Success Metrics
✦✦>60% development staff
trained within past 1 year B. Utilize security coaches to enhance project teams
✦✦>50% management/analyst staff Using either internal or external experts, make security-savvy staff available to project teams
trained within past 1 year
for consultation. Further, this coaching resource should be advertised internally to ensure
✦✦>80% senior development/architect
that staff are aware of its availability.
staff trained within past 1 year
✦✦>3.0 Likert on usefulness The coaching staff can be created by recruiting experienced individuals within the organiza-
of training courses tion to spend some percentage of their time, around 10% maximum, performing coaching
activities. The coaches should communicate between one another to ensure they are aware
Costs of each other’s area of expertise and route questions accordingly for efficiency.
✦✦Training library build-out or license While coaches can be used at any point in the software life-cycle, appropriate times to use
✦✦Security-savvy staff for hands-on coaching the coaches include during initial product conception, before completion of functional or de-
Personnel tailed design specification(s), when issues arise during development, test planning, and when
operational security incidents occur.
✦✦Developers
✦✦Architects Over time, the internal network of coaching resources can be used as points-of-contact for
communicating security-relevant information throughout the organization as well as being
✦✦Managers
local resources that have greater familiarity with the ongoing project teams than a purely
SAMM / The Security Practices - v1.1

✦✦Business Owners
centralized security team might.
✦✦QA Testers
✦✦Security Auditors

Related Levels
✦✦Issue Management - 1
✦✦Design Review - 2
✦✦Secure Architecture - 2

34
 Education & Guidance EG 3
Mandate comprehensive security training and certify personnel for baseline knowledge

Activities
Assessment
A. Create formal application security support portal
✦✦Is security-related guidance centrally
Building upon written resources on topics relevant to application security, create and ad- controlled and consistently distributed
vertise a centralized repository (usually an internal web site). The guidelines themselves throughout the organization?
can be created in any way that makes sense for the organization, but an approval board and ✦✦Are developers tested to ensure
straightforward change control processes must be established. a baseline skill-set for secure
development practices?
Beyond static content in the form of best-practices lists, tool-specific guides, FAQs, and other
articles, the support portal should feature interactive components such as mailing lists, web- Results
based forums, or wikis to allow internal resources to cross-communicate security relevant
✦✦Efficient remediation of vulnerabilities
topics and have the information cataloged for future reference.
in both ongoing and legacy code bases
The content should be cataloged and easily searchable based upon several common fac- ✦✦Quickly understand and mitigate
tors such as platform, programming language, pertinence to specific third party libraries or against new attacks and threats
frameworks, life-cycle stage, etc. Project teams creating software should align themselves ✦✦Judge security-savvy of staff and
early in product development to the specific guidelines that they will follow. In product as- measure against a common standard
sessments, the list of applicable guidelines and product-related discussions should be used ✦✦Establish fair incentives toward
as audit criteria. security awareness

Success Metrics
B. Establish role-based examination/certification ✦✦>80% staff certified within past 1 year
Either per role or per training class/module, create and administer aptitude exams that test Costs
people for comprehension and utilization of security knowledge. Typically, exams should be
✦✦Certification examination
created based on the role-based curricula and target a minimum passing score around 75%
build-out or license
correct. While staff should be required to take applicable training or refresher courses an-
✦✦Ongoing maintenance and change control
nually, certification exams should be required biannually at a minimum.
for application security support portal
Based upon pass/fail criteria or exceptional performance, staff should be ranked into tiers ✦✦Human-resources and overhead cost for
such that other security-related activities could require individuals of a particular certifica- implementing employee certification
tion level to sign-off before the activity is complete, e.g. an uncertified developer cannot pass
a design into implementation without explicit approval from a certified architect. This pro- Personnel
vides granular visibility on an per-project basis for tracking security decisions with individual ✦✦Developers
accountability. Overall, this provides a foundation for rewarding or penalizing staff for making ✦✦Architects
good business decisions regarding application security. ✦✦Managers
✦✦Business Owners
✦✦QA Testers
✦✦Security Auditors

Related Levels
SAMM / The Security Practices - v1.1

✦✦Policy & Compliance - 2 & 3

35
 Threat Assessment

TA 1 TA 2 TA 3
Objective Identify and understand Increase accuracy of Concretely tie
high-level threats to threat assessment and compensating controls to
the organization and improve granularity of per- each threat against internal
individual projects project understanding and third-party software

Activities A. Build and maintain application- A. Build and maintain abuse- A. Explicitly evaluate risk from
specific threat models case models per project third-party components
B. Develop attacker profile B. Adopt a weighting system for B. Elaborate threat models
from software architecture measurement of threats with compensating controls

Assessment ✦✦Do projects in your ✦✦Do project teams regularly ✦✦Do project teams
organization consider and analyze functional requirements specifically consider risk
document likely threats? for likely abuses? from external software?
✦✦Does your organization ✦✦Do project teams use a ✦✦Are the majority of the
understand and document the method of rating threats protection mechanisms
types of attackers it faces? for relative comparison? and controls captured and
✦✦Are stakeholders aware of mapped back to threats?
relevant threats and ratings?

Results ✦✦High-level understanding ✦✦Granular understanding of likely ✦✦Deeper consideration

of factors that may lead threats to individual projects of full threat profile for
to negative outcomes ✦✦Framework for better tradeoff each software project
✦✦Increased awareness of threats decisions within project teams ✦✦Detailed mapping of
amongst project teams ✦✦Ability to prioritize development assurance features to
✦✦Inventory of threats for efforts within a project team established threats against
your organization based on risk weighting each software project
✦✦Artifacts to document
due diligence based on
business function of
each software project
SAMM / The Security Practices - v1.1

36
 Threat Assessment TA 1
Identify and understand high-level threats to the organization and individual projects

Activities
Assessment
A. Build and maintain application-specific threat models
✦✦Do projects in your organization
Based purely on the business purpose of each software project and the business risk profile consider and document likely threats?
(if available) identify likely worst-case scenarios for the software under development in each ✦✦Does your organization understand and
project team. This can be conducted using simple attack trees or through a more formal document the types of attackers it faces?
threat modeling process such as Microsoft’s STRIDE, Trike, etc.
Results
To build attack trees, identify each worst-case scenario in one sentence and label these as
the high-level goals of an attacker. From each attacker goal identified, identify preconditions ✦✦High-level understanding of factors
that must hold in order for each goal to be realized. This information should be captured in that may lead to negative outcomes
branches underneath each goal where each branch is either a logical AND or a logical OR of ✦✦Increased awareness of threats
amongst project teams
the statements contained underneath. An AND branch indicates that each directly attached
child nodes must be true in order to realize the parent node. An OR branch indicates that ✦✦Inventory of threats for your organization
any one of the directly attached child nodes must be true in order to achieve the parent Success Metrics
node.
✦✦>50% of project stakeholders briefed
Regardless of the threat modeling approach, review each current and historic functional on the threat models of relevant
requirement to augment the attack tree to indicate security failures relevant to each. Brain- projects within past 12 months
storm by iteratively dissecting each failure scenario into all the possible ways in which an ✦✦>75% of project stakeholders
attacker might be able to reach one of the goals. After initial creation, the threat model for briefed on attacker profiles
an application should be updated when significant changes to the software are made. This for relevant architectures
assessment should be conducted with senior developers and architects as well as one or
more security auditors.
Costs
✦✦Buildout and maintenance of project
artifacts for threat models
B. Develop attacker profile from software architecture
Personnel
Initially, conduct an assessment to identify all likely threats to the organization based on ✦✦Business Owners
software projects. For this assessment, consider threats to be limited to agents of malicious
✦✦Developers
intent and omit other risks such as known vulnerabilities, potential weaknesses, etc.
✦✦Architects
Begin by generally considering external agents and their corresponding motivations for at- ✦✦Security Auditors
tack. To this list, add internal roles that could cause damage and their motivations for insider ✦✦Managers
attack. Based on the architecture of the software project(s) under consideration, it can be
more efficient to conduct this analysis once per architecture type instead of for each project Related Levels
individually since applications of architecture and business purpose will generally be suscep- ✦✦Strategy & Metrics - 1
tible to similar threats. ✦✦Security Requirements - 2
This assessment should be conducted with business owners and other stakeholders but also
include one or more security auditors for additional perspective on threats. In the end, the
goal is to have a concise list of threat agents and their corresponding motivations for attack.
SAMM / The Security Practices - v1.1

37
 TA 2 Threat Assessment
Increase accuracy of threat assessment and improve granularity of per-project understanding

Activities
Assessment A. Build and maintain abuse-case models per project
✦✦Do project teams regularly analyze Further considering the threats to the organization, conduct a more formal analysis to deter-
functional requirements for likely abuses? mine potential misuse or abuse of functionality. Typically, this process begins with identifica-
✦✦Do project teams use a method of tion of normal usage scenarios, e.g. use-case diagrams if available.
rating threats for relative comparison?
✦✦Are stakeholders aware of
If a formal abuse-case technique isn’t used, generate a set of abuse-cases for each scenario
relevant threats and ratings? by starting with a statement of normal usage and brainstorming ways in which the statement
might be negated, in whole or in part. The simplest way to get started is to insert the word
Results “no” or “not” into the usage statement in as many ways as possible, typically around nouns
✦✦Granular understanding of likely and verbs. Each usage scenario should generate several possible abuse-case statements.
threats to individual projects Further elaborate the abuse-case statements to include any application-specific concerns
✦✦Framework for better tradeoff based on the business function of the software. The ultimate goal is for the completed set
decisions within project teams of abuse statements to form a model for usage patterns that should be disallowed by the
✦✦Ability to prioritize development software. If desired, these abuse cases can be combined with existing threat models.
efforts within a project team
based on risk weighting After initial creation, abuse-case models should be updated for active projects during the
design phase. For existing projects, new requirements should be analyzed for potential abuse,
Success Metrics and existing projects should opportunistically build abuse-cases for established functionality
✦✦>75% of project teams with where practical.
identified and rated threats
✦✦>75% of project stakeholders briefed
on threat and abuse models of relevant B. Adopt a weighting system for measurement of threats
projects within past 6 months
Based on the established attacker profiles, identify a rating system to allow relative compari-
Costs son between the threats. Initially, this can be a simple high-medium-low rating based upon
business risk, but any scale can be used provided that there are no more than 5 categories.
✦✦Project overhead from maintenance of
threat models and attacker profiles After identification of a rating system, build evaluation criteria that allow each threat to be
assigned a rating. In order to do this properly, additional factors about each threat must
Personnel be considered beyond motivation. Important factors include capital and human resources,
✦✦Security Auditor inherent access privilege, technical ability, relevant goals on the threat model(s), likelihood of
✦✦Business Owner successful attack, etc.
✦✦Managers After assigning each threat to a rating, use this information to prioritize risk mitigation activi-
ties within the development life-cycle. Once built for a project team, it should be updated
Related Levels
during design of new features or refactoring efforts.
✦✦Strategy & Metrics - 2
✦✦Secure Architecture - 2
SAMM / The Security Practices - v1.1

38
 Threat Assessment TA 3
Concretely tie compensating controls to each threat against internal and third-party software

Activities
Assessment
A. Explicitly evaluate risk from third-party components
✦✦Do project teams specifically consider
Conduct an assessment of your software code-base and identify any components that are of risk from external software?
external origin. Typically, these will include open-source projects, purchased COTS software, ✦✦Are the majority of the protection
and online services which your software uses. mechanisms and controls captured
For each identified component, elaborate attacker profiles for the software project based and mapped back to threats?
upon potential compromise of third-party components. Based upon the newly identified Results
attacker profiles, update software threat models to incorporate any likely risks based upon
new attacker goals or capabilities. ✦✦Deeper consideration of full threat
profile for each software project
In addition to threat scenarios, also consider ways in which vulnerabilities or design flaws in ✦✦Detailed mapping of assurance
the third-party software might affect your code and design. Elaborate your threat models features to established threats
accordingly with the potential risks from vulnerabilities and knowledge of the updated at- against each software project
tacker profile. ✦✦Artifacts to document due diligence
based on business function of
After initially conducted for a project, this must be updated and reviewed during the design
each software project
phase or every development cycle. This activity should be conducted by a security auditor
with relevant technical and business stakeholders. Success Metrics
✦✦>80% of project teams with
updated threat models prior to
B. Elaborate threat models with compensating controls every implementation cycle
Conduct an assessment to formally identify factors that directly prevent preconditions for ✦✦>80% of project teams with
compromise represented by the threat models. These mitigating factors are the compensat- updated inventory of third-party
ing controls that formally address the direct risks from software. Factors can be technical components prior to every release
features in the software itself, but can also be process elements in the development life-cycle, ✦✦>50% of all security incidents identified a
infrastructure features, etc. priori by threat models in past 12 months

If using attack trees, the logical relationship represented by each branch will be either an Costs
AND or an OR. Therefore, by mitigating against just one precondition on an AND branch, ✦✦Project overhead from maintenance
the parent and all connected leaf nodes can be marked as mitigated. However, all child nodes of detailed threat models and
on an OR node must be prevented before the parent can be marked as mitigated. expanded attacker profiles
Regardless of threat modeling technique, identify compensating controls and annotate the ✦✦Discovery of all third-party dependencies
threat models directly.The goal is to maximize coverage in terms of controls that mark parts
Personnel
of the threat model as mitigated. For any viable paths remaining, identify potential compen-
sating controls for feedback into organizational strategy. ✦✦Business Owners
✦✦Developers
After initially conducted for a project, this must be updated and reviewed during the design
✦✦Architects
phase or every development cycle. This activity should be conducted by a security auditor
✦✦Security Auditors
with relevant technical and business stakeholders.
SAMM / The Security Practices - v1.1

✦✦Managers

Related Levels
✦✦Security Requirements - 2 & 3

39
 Security Requirements

SR 1 SR 2 SR 3
Objective Consider security explicitly Increase granularity of security Mandate security
during the software requirements derived from requirements process for
requirements process business logic and known risks all software projects and
third-party dependencies

Activities A. Derive security requirements A. Build an access control matrix A. Build security requirements
from business functionality for resources and capabilities into supplier agreements
B. Evaluate security and compliance B. Specify security requirements B. Expand audit program for
guidance for requirements based on known risks security requirements

Assessment ✦✦Do project teams specify ✦✦Do stakeholders review ✦✦Do stakeholders review
security requirements access control matrices vendor agreements for
during development? for relevant projects? security requirements?
✦✦Do project teams pull ✦✦Do project teams specify ✦✦Are audits performed against
requirements from best practices requirements based on feedback the security requirements
and compliance guidance? from other security activities? specified by project teams?

Results ✦✦High-level alignment ✦✦Detailed understanding of attack ✦✦Formally set baseline for
of development effort scenarios against business logic security expectations
with business risks ✦✦Prioritized development from external code
✦✦Ad hoc capturing of industry effort for security features ✦✦Centralized information on
best-practices for security based on likely attacks security effort undertaken
as explicit requirements ✦✦More educated decision- by each project team
✦✦Awareness amongst stakeholders making for tradeoffs between ✦✦Ability to align resources
of measures being taken to features and security efforts to projects based on
mitigate risk from software ✦✦Stakeholders that can better application risk and desired
avoid functional requirements security requirements
that inherently have security flaws
SAMM / The Security Practices - v1.1

40
 Security Requirements SR 1
Consider security explicitly during the software requirements process

Activities
Assessment
A. Derive security requirements from business functionality
✦✦Do project teams specify security
Conduct a review of functional requirements that specify the business logic and overall requirements during development?
behavior for each software project. After gathering requirements for a project, conduct an ✦✦Do project teams pull requirements from
assessment to derive relevant security requirements. Even if software is being built by a best practices and compliance guidance?
third-party, these requirements, once identified, should be included with functional require-
ments delivered to vendors. Results
For each functional requirement, a security auditor should lead stakeholders through the ✦✦High-level alignment of development
process of explicitly noting any expectations with regard to security. Typically, questions to effort with business risks
clarify for each requirement include expectations for data security, access control, transac- ✦✦Ad hoc capturing of industry
best-practices for security as
tion integrity, criticality of business function, separation of duties, uptime, etc.
explicit requirements
It is important to ensure that all security requirements follow the same principles for writing ✦✦Awareness amongst stakeholders
good requirements in general. Specifically, they should be specific, measurable, and reason- of measures being taken to
able. mitigate risk from software
Conduct this process for all new requirements on active projects. For existing features, it is Success Metrics
recommended to conduct the same process as a gap analysis to fuel future refactoring for
✦✦>50% of project teams with explicitly
security.
defined security requirements

Costs
B. Evaluate security and compliance guidance for requirements
✦✦Project overhead from addition
Determine industry best-practices that project teams should treat as requirements. These of security requirements to
can be chosen from publicly available guidelines, internal or external guidelines/standards/ each development cycle
policies, or established compliance requirements.
Personnel
It is important to not attempt to bring in too many best-practice requirements into each
✦✦Security Auditor
development iteration since there is a time trade-off with design and implementation. The
✦✦Business Owners
recommended approach is to slowly add best-practices over successive development cycles
✦✦Managers
to bolster the software’s overall assurance profile over time.
✦✦Architects
For existing systems, refactoring for security best practices can be a complex undertaking.
Where possible, add security requirements opportunistically when adding new features. At Related Levels
a minimum, conducting the analysis to identify applicable best practices should be done to ✦✦Education & Guidance - 1
help fuel future planning efforts. ✦✦Policy & Compliance - 2
This review should be performed by a security auditor with input from business stakehold- ✦✦Design Review - 1
ers. Senior developers, architects, and other technical stakeholders should also be involved ✦✦Implementation Review - 1
to bring design and implementation-specific knowledge into the decision process. ✦✦Security Testing - 1
SAMM / The Security Practices - v1.1

41
 SR 2 Security Requirements
Increase granularity of security requirements derived from business logic and known risks

Activities
Assessment A. Build an access control matrix for resources and capabilities
✦✦Do stakeholders review access control Based upon the business purpose of the application, identify user and operator roles. Ad-
matrices for relevant projects? ditionally, build a list of resources and capabilities by gathering all relevant data assets and
✦✦Do project teams specify application-specific features that are guarded by any form of access control.
requirements based on feedback
from other security activities? In a simple matrix with roles on one axis and resources on the other, consider the relation-
ships between each role and each resource and note in each intersection the correct behav-
Results ior of the system in terms of access control according to stakeholders.
✦✦Detailed understanding of attack For data resources, it is important to note access rights in terms of creation, read access,
scenarios against business logic update, and deletion. For resources that are features, gradation of access rights will likely
✦✦Prioritized development effort for be application-specific, but at a minimum note if the role should be permitted access to the
security features based on likely attacks
feature.
✦✦More educated decision-
making for tradeoffs between This permission matrix will serve as an artifact to document the correct access control
features and security efforts rights for the business logic of the overall system. As such, it should be created by the project
✦✦Stakeholders that can better teams with input from business stakeholders. After initial creation, it should be updated by
avoid functional requirements that business stakeholders before every release, but usually toward the beginning of the design
inherently have security flaws phase.
Success Metrics
✦✦>75% of all projects with updated abuse- B. Specify security requirements based on known risks
case models within past 6 months
Explicitly review existing artifacts that indicate organization or project-specific security risk
Costs in order to better understand the overall risk profile for the software. When available, draw
on resources such as the high-level business risk profile, individual application threat models,
✦✦Project overhead from buildout and
maintenance of abuse-case models findings from design review, code review, security testing, etc.
In addition to review of existing artifacts, use abuse-case models for an application to serve
Personnel as fuel for identification of concrete security requirements that directly or indirectly mitigate
✦✦Security Auditor the abuse scenarios.
✦✦Managers
This process should be conducted by business owners and security auditors as needed.
✦✦Architects Ultimately, the notion of risks leading to new security requirements should become a built-
✦✦Business Owners in step in the planning phase whereby newly discovered risks are specifically assessed by
project teams.
Related Levels
✦✦Threat Assessment - 1 & 3
✦✦Strategy & Metrics - 1
SAMM / The Security Practices - v1.1

42
 Security Requirements SR 3
Mandate security requirements process for all software projects and third-party dependencies

Activities
Assessment
A. Build security requirements into supplier agreements
✦✦Do stakeholders review vendor
Beyond the kinds of security requirements already identified by previous analysis, additional agreements for security requirements?
security benefits can be derived from third-party agreements. Typically, requirements and ✦✦Are audits performed against the security
perhaps high-level design will be developed internally while detailed design and implementa- requirements specified by project teams?
tion is often left up to suppliers.
Results
Based on the specific division of labor for each externally developed component, identify
specific security activities and technical assessment criteria to add to the vendor contracts. ✦✦Formally set baseline for security
Commonly, this is a set of activities from the Design Review, Code Review, and Security expectations from external code
Testing Practices. ✦✦Centralized information on security
effort undertaken by each project team
Modifications of agreement language should be handled on a case-by-case basis with each ✦✦Ability to align resources to projects
supplier since adding additional requirements will generally mean an increase in cost. The based on application risk and
cost of each potential security activity should be balanced against the benefit of the activity desired security requirements
as per the usage of the component or system being considered.
Success Metrics
✦✦>80% of projects passing security
B. Expand audit program for security requirements requirements audit in past 6 months
Incorporate checks for completeness of security requirements into routine project audits. ✦✦>80% of vendor agreements
Since this can be difficult to gauge without project-specific knowledge, the audit should focus analyzed for contractual security
requirements in past 12 months
on checking project artifacts such as requirements or design documentation for evidence
that the proper types of analysis were conducted. Costs
Particularly, each functional requirement should be annotated with security requirements ✦✦Increased cost from outsourced
based on business drivers as well as expected abuse scenarios. The overall project require- development from additional
ments should contain a list of requirements generated from best-practices in guidelines and security requirements
standards. Additionally, there should be a clear list of unfulfilled security requirements and an ✦✦Ongoing project overhead from release
estimated timeline for their provision in future releases. gates for security requirements

This audit should be performed during every development iteration, ideally toward the end Personnel
of the requirements process, but it must be performed before a release can be made. ✦✦Security Auditor
✦✦Managers
✦✦Business Owners

Related Levels
✦✦Threat Assessment - 3
✦✦Policy & Compliance - 2
SAMM / The Security Practices - v1.1

43
 Secure Architecture

SA 1 SA 2 SA 3
Objective Insert consideration Direct the software design Formally control the
of proactive security process toward known- software design process
guidance into the software secure services and secure- and validate utilization
design process by-default designs of secure components

Activities A. Maintain list of recommended A. Identify and promote security A. Establish formal reference
software frameworks services and infrastructure architectures and platforms
B. Explicitly apply security B. Identify security design B. Validate usage of frameworks,
principles to design patterns from architecture patterns, and platforms

Assessment ✦✦Are project teams provided ✦✦Do you advertise shared ✦✦Do project teams build
with a list of recommended security services with software from centrally-
third-party components? guidance for project teams? controlled platforms
✦✦Are project teams aware of ✦✦Are project teams provided with and frameworks?
secure design principles and do prescriptive design patterns based ✦✦Are project teams audited
they apply them consistently? on their application architecture? for the use of secure
architecture components?

Results ✦✦Ad hoc prevention of unexpected ✦✦Detailed mapping of assets to ✦✦Customized application
dependencies and one-off user roles to encourage better development platforms
implementation choices compartmentalization in design that provide built-in
✦✦Stakeholders aware of increased ✦✦Reusable design building security protections
project risk due to libraries blocks for provision of security ✦✦Organization-wide
and frameworks chosen protections and functionality expectations for proactive
✦✦Established protocol ✦✦Increased confidence for software security effort in development
within development for projects from use of established ✦✦Stakeholders better able
proactively applying security design techniques for security to make tradeoff decisions
mechanisms to a design based on business need
for secure design
SAMM / The Security Practices - v1.1

44
 Secure Architecture SA 1
Insert consideration of proactive security guidance into the software design process

Activities
Assessment
A. Maintain list of recommended software frameworks
✦✦Are project teams provided with a list of
Across software projects within the organization identify commonly used third-party soft- recommended third-party components?
ware libraries and frameworks in use. Generally, this need not be an exhaustive search for ✦✦Are project teams aware of
dependencies, but rather focus on capturing the high-level components that are most often secure design principles and do
used. they apply them consistently?
From the list of components, group them into functional categories based on the core fea- Results
tures provided by the third-party component. Also, note the usage prevalence of each com-
ponent across project teams to weight the reliance upon the third-party code. Using this ✦✦Ad hoc prevention of unexpected
dependencies and one-off
weighted list as a guide, create a list of components to be advertised across the development
implementation choices
organization as recommended components.
✦✦Stakeholders aware of increased
Several factors should contribute to decisions for inclusion on the recommended list. Al- project risk due to libraries
though a list can be created without conducting research specifically, it is advisable to inspect and frameworks chosen
each for incident history, track record for responding to vulnerabilities, appropriateness of ✦✦Established protocol within
functionality for the organization, excessive complexity in usage of the third-party compo- development for proactively applying
nent, etc. security mechanisms to a design

This list should be created by senior developers and architects, but also include input from Success Metrics
managers and security auditors. After creation, this list of recommended components ✦✦>80% of development staff
matched against functional categories should be advertised to the development organization. briefed on software framework
Ultimately, the goal is to provide well-known defaults for project teams. recommendations in past 1 year
✦✦>50% of projects self-
reporting application of security
B. Explicitly apply security principles to design principles to design
During design, technical staff on the project team should use a short list of guiding security Costs
principles as a checklist against detailed system designs. Typically, security principles include
defense in depth, securing the weakest link, use of secure defaults, simplicity in design of secu- ✦✦Buildout, maintenance, and awareness of
software framework recommendations
rity functionality, secure failure, balance of security and usability, running with least privilege,
✦✦Ongoing project overhead from analysis
avoidance of security by obscurity, etc.
and application of security principles
In particular for perimeter interfaces, the design team should consider each principle in the
context of the overall system and identify features that can be added to bolster security Personnel
at each such interface. Generally, these should be limited such that they only take a small ✦✦Architects
amount of extra effort beyond the normal implementation cost of functional requirements ✦✦Developers
and anything larger should be noted and scheduled for future releases. ✦✦Security Auditors
While this process should be conducted by each project team after being trained with secu- ✦✦Managers
rity awareness, it is helpful to incorporate more security-savvy staff to aide in making design
decisions. Related Levels
SAMM / The Security Practices - v1.1

✦✦Education & Guidance - 1

45
 SA 2 Secure Architecture
Direct the software design process toward known-secure services and secure-by-default designs

Activities
Assessment A. Identify and promote security services and infrastructure
✦✦Do you advertise shared security Organizations should identify shared infrastructure or services with security functionality.
services with guidance for project teams? These will typically include single-sign-on services, corporate directory systems, access con-
✦✦Are project teams provided with trol or entitlements services, and authentication systems. By collecting and evaluating reus-
prescriptive design patterns based able systems, assemble a list of such resources and categorize them by the security mecha-
on their application architecture?
nism they fulfill. It is also helpful to consider each resource in terms of why a development
Results team would want to integrate with it, i.e. the benefits of using the shared resource.
✦✦Detailed mapping of assets to If multiple resources exist in each category, an organization should select and standardize on
user roles to encourage better one or more shared service per category. Because future software development will rely on
compartmentalization in design these selected services, each should be thoroughly audited to ensure the baseline security
✦✦Reusable design building posture is understood. For each selected service, design guidance should be created for
blocks for provision of security development teams to understand how to integrate with the system. After such guidance is
protections and functionality assembled, it should be made available to development teams through training, mentorship,
✦✦Increased confidence for software guidelines, and standards.
projects from use of established
design techniques for security The benefits of doing this include promotion of known-secure systems, simplified security
guidance for project design teams, and clearer paths to building assurance around the ap-
Success Metrics plications utilizing the shared security services.
✦✦>80% of projects with updated
permission matrix in past 6 months
✦✦>80% of project teams B. Identify security design patterns from architecture
briefed on applicable security Across software projects at an organization, each should be categorized in terms of the
patterns in past 6 months generic architecture type. Common categories include client-server applications, embedded
Costs systems, desktop applications, web-facing applications, web services platforms, transactional
middleware systems, mainframe applications, etc. Depending on your organizations specialty,
✦✦Buildout or license of applicable
more detailed categories may need to be developed based upon language, or processor
security patterns
architecture, or even era of deployment.
✦✦Ongoing project overhead from
maintenance of permission matrix For the generic software architecture type, a set of general design patterns representing
sound methods of implementing security functionality can be derived and applied to the
Personnel individual designs of an organization’s software projects. These security design patterns rep-
✦✦Architects resent general definitions of generic design elements they can be researched or purchased,
✦✦Developers and it is often even more effective if these patterns are customized to be made more spe-
✦✦Managers cific to your organization. Example patterns include a single-sign-on subsystem, a cross-tier
✦✦Business Owners delegation model, a hardened interface design, separation-of-duties authorization model, a
✦✦Security Auditors centralized logging pattern, etc.
The process of identification of applicable and appropriate patterns should be carried out
Related Levels
SAMM / The Security Practices - v1.1

by architects, senior developers, and other technical stakeholders during the design phase.
✦✦Education & Guidance - 1

46
 Secure Architecture SA 3
Formally control the software design process and validate utilization of secure components

Activities
Assessment
A. Establish formal reference architectures and platforms
✦✦Do project teams build software
After promoting integration with shared security services and working with security pat- from centrally-controlled
terns specific to each type of architecture, a collection of code implementing these pieces platforms and frameworks?
of functionality should be selected from project teams and used as the basis for a shared ✦✦Are project teams audited for the use
code-base. This shared code-base can initially start as a collection of commonly recom- of secure architecture components?
mended libraries that each project needs to use and it can grow over time into one or more
software frameworks representing reference platforms upon which project teams build their Results
software. Examples of reference platforms include frameworks for model-view-controller ✦✦Customized application development
web applications, libraries supporting transactional back-end systems, frameworks for web platforms that provide built-
services platforms, scaffolding for client-server applications, frameworks for middle-ware in security protections
with pluggable business logic, etc. ✦✦Organization-wide expectations for
proactive security effort in development
Another method of building initial reference platforms is to select a particular project early
✦✦Stakeholders better able to make
in the life-cycle and have security-savvy staff work with them to build the security functional- tradeoff decisions based on
ity in a generic way so that it could be extracted from the project and utilized elsewhere in business need for secure design
the organization.
Regardless of approach to creation, reference platforms have advantages in terms of speed-
Success Metrics
ing audit and security-related reviews, increasing efficiency in development, and lowering ✦✦>50% of active projects using
maintenance overhead. reference platforms
✦✦>80% of projects reporting
Architects, senior developers and other technical stakeholders should participate in design framework, pattern, and platform
and creation of reference platforms. After creation, a team must maintain ongoing support usage feedback in past 6 months
and updates. ✦✦>3.0 Likert on usefulness of guidance/
platforms reported by project teams

B. Validate usage of frameworks, patterns, and platforms Costs

During routine audits of projects conduct additional analysis of project artifacts to measure ✦✦Buildout or license of
usage of recommended frameworks, design patterns, shared security services, and refer- reference platform(s)
ence platforms. Though conducted during routine audits, the goal of this activity is to collect ✦✦Ongoing maintenance and support
feedback from project teams as much as to measure their individual proactive security effort. of reference platforms
✦✦Ongoing project overhead from
Overall, it is important to verify several factors with project teams. Identify use of non- usage validation during audit
recommended frameworks to determine if there may be a gap in recommendations versus
the organization’s functionality needs. Examine unused or incorrectly used design patterns Personnel
and reference platform modules to determine if updates are needed. Additionally, there may ✦✦Managers
be more or different functionality that project teams would like to see implemented in the ✦✦Business Owners
reference platforms as the organization evolves. ✦✦Architects
This analysis can be conducted by any security-savvy technical staff. Metrics collected from
SAMM / The Security Practices - v1.1

✦✦Developers
each project should be collated for analysis by managers and stakeholders. ✦✦Security Auditors

Related Levels
✦✦Policy & Compliance - 2
✦✦Design Review - 3
✦✦Implementation Review - 3
✦✦Security Testing - 3

47
 Design Review

DR 1 DR 2 DR 3
Objective Support ad hoc reviews Offer assessment services Require assessments and
of software design to to review software design validate artifacts to develop
ensure baseline mitigations against comprehensive best detailed understanding of
for known risks practices for security protection mechanisms

Activities A. Identify software attack surface A. Inspect for complete provision A. Develop data-flow diagrams
B. Analyze design against known of security mechanisms for sensitive resources
security requirements B. Deploy design review B. Establish release gates
service for project teams for design review

Assessment ✦✦Do project teams document ✦✦Do project teams specifically ✦✦Does the secure design
the attack perimeter of analyze design elements for review process incorporate
software designs? security mechanisms? detailed data-level analysis?
✦✦Do project teams check ✦✦Are project stakeholders ✦✦Does a minimum security
software designs against aware of how to obtain a baseline exist for secure
known security risks? formal secure design review? design review results?

Results ✦✦High-level understanding of ✦✦Formally offered assessment ✦✦Granular view of weak

security implications from service to consistently review points in a system design
perimeter architecture architecture for security to encourage better
✦✦Enable development teams ✦✦Pinpoint security flaws compartmentalization
to self-check designs for in maintenance-mode ✦✦Organization-level awareness
security best-practices and legacy systems of project standing against
✦✦Lightweight process ✦✦Deeper understanding amongst baseline security expectations
for conducting project- project stakeholders on for architecture
level design reviews how the software provides ✦✦Comparisons between
assurance protections projects for efficiency
and progress toward
mitigating known flaws
SAMM / The Security Practices - v1.1

48
 Design Review DR 1
Support ad hoc reviews of software design to ensure baseline mitigations for known risks

Activities
Assessment
A. Identify software attack surface
✦✦Do project teams document the attack
For each software project, create a simplified view of the overall architecture. Typically, this perimeter of software designs?
should be created based on project artifacts such as high-level requirements and design ✦✦Do project teams check software
documents, interviews with technical staff, or module-level review of the code base. It is im- designs against known security risks?
portant to capture the high-level modules in the system, but a good rule of thumb for granu-
larity is to ensure that the diagram of the whole system under review fits onto one page. Results
From the single page architecture view, analyze each component in terms of accessibility of ✦✦High-level understanding of security
the interfaces from authorized users, anonymous users, operators, application-specific roles, implications from perimeter architecture
etc. The components providing the interfaces should also be considered in the context of ✦✦Enable development teams to self-check
designs for security best-practices
the one-page view to find points of functional delegation or data pass-through to other com-
ponents on the diagram. Group interfaces and components with similar accessibility profiles ✦✦Lightweight process for conducting
project-level design reviews
and capture this as the software attack surface.
For each interface, further elaborate the one-page diagram to note any security-related Success Metrics
functionality. Based on the identified interface groups comprising the attack surface, check ✦✦>50% of projects with updated attack
the model for design-level consistency for how interfaces with similar access are secured. surface analysis in past 12 months
Any breaks in consistency can be noted as assessment findings ✦✦>50% of projects with updated
security requirements design-level
This analysis should be conducted by security-savvy technical staff, either within the project
analysis in past 12 months
team or external. Typically, after initial creation, the diagram and attack surface analysis only
needs to be updated during the design phase when additions or changes are made to the Costs
edge system interfaces.
✦✦Buildout and maintenance of
architecture diagrams for each project
✦✦Ongoing project overhead from
B. Analyze design against known security requirements attack surface and security
Security requirements, either formally identified or informally known, should be identified requirement design inspection
and collected. Additionally, identify and include any security assumptions upon which safe
operation of the system relies. Personnel
✦✦Architects
Review each item on the list of known security requirements against the one-page diagram
✦✦Developers
of the system architecture. Elaborate the diagram to show the design-level features that
address each security requirement. Separate, granular diagrams can be created to simplify ✦✦Managers
capturing this information if the system is large and/or complex. The overall goal is to verify ✦✦Security Auditor
that each known security requirement has been addressed by the system design.Any security Related Levels
requirements that are not clearly provided at the design level should be noted as assessment
findings. ✦✦Security Requirements - 1

This analysis should be conducted by security-savvy technical staff with input from architects,
developers, managers, and business owners as needed. It should be updated during the
SAMM / The Security Practices - v1.1

design phase when there are changes in security requirements or high-level system design.

49
 DR 2 Design Review
Offer assessment services to review software design against comprehensive best practices for security

Activities
Assessment
A. Inspect for complete provision of security mechanisms
✦✦Do project teams specifically analyze
design elements for security mechanisms? For each interface on a module in the high-level architecture diagram, formally iterate
✦✦Are project stakeholders aware of how through the list of security mechanisms and analyze the system for their provision. This type
to obtain a formal secure design review? of analysis should be performed on both internal interfaces, e.g. between tiers, as well as
external ones, e.g. those comprising the attack surface.
Results
The six main security mechanisms to consider are authentication, authorization, input valida-
✦✦Formally offered assessment tion, output encoding, error handling and logging. Where relevant, also consider the mecha-
service to consistently review nisms of cryptography and session management. For each interface, determine where in
architecture for security
the system design each mechanism is provided and note any missing or unclear features as
✦✦Pinpoint security flaws in maintenance-
findings.
mode and legacy systems
✦✦Deeper understanding amongst project This analysis should be conducted by security-savvy staff with assistance from the project
stakeholders on how the software team for application-specific knowledge.This analysis should be performed once per release,
provides assurance protections usually toward the end of the design phase. After initial analysis, subsequent releases are
required to update the findings based on changes being made during the development cycle.
Success Metrics
✦✦>80% of stakeholders briefed on status
of review requests in past 6 months B. Deploy design review service for project teams
✦✦>75% of projects undergoing Institute a process whereby project stakeholders can request a design review. This service
design review in past 12 months
may be provided centrally within the organization or distributed across existing staff, but all
Costs reviewers must be trained on performing the reviews completely and consistently.
✦✦Buildout, training, and maintenance The review service should be centrally managed in that the review request queue should
of design review team be triaged by senior managers, architects, and stakeholders that are familiar with the overall
✦✦Ongoing project overhead business risk profile for the organization.This allows prioritization of project reviews in align-
from review activities ment with overall business risk.
Personnel During a design review, the review team should work with project teams to collect informa-
tion sufficient to formulate an understanding of the attack surface, match project-specific se-
✦✦Architects
curity requirements to design elements, and verify security mechanisms at module interfaces.
✦✦Developers
✦✦Managers
✦✦Security Auditors

Related Levels
✦✦Education & Guidance - 2
✦✦Strategy & Metrics - 2
SAMM / The Security Practices - v1.1

50
 Design Review DR 3
Require assessments and validate artifacts to develop detailed understanding of protection mechanisms

Activities
Assessment
A. Develop data-flow diagrams for sensitive resources
✦✦Does the secure design review process
Based on the business function of the software project, conduct analysis to identify details on incorporate detailed data-level analysis?
system behavior around high-risk functionality. Typically, high-risk functionality will correlate ✦✦Does a minimum security baseline exist
to features implementing creation, access, update, and deletion of sensitive data. Beyond data, for secure design review results?
high-risk functionality also includes project-specific business logic that is critical in nature,
either from a denial-of-service or compromise perspective. Results
For each identified data source or business function, select and use a standardized notation ✦✦Granular view of weak points in
to capture relevant software modules, data sources, actors, and messages that flow amongst a system design to encourage
better compartmentalization
them. It is often helpful to start with a high-level design diagram and iteratively flesh out
✦✦Organization-level awareness of project
relevant detail while removing elements that do not correspond to the sensitive resource.
standing against baseline security
With data-flow diagrams created for a project, conduct analysis over them to determine expectations for architecture
internal choke-points in the design. Generally, these will be individual software modules that ✦✦Comparisons between projects
handle data with differing sensitivity levels or those that gate access to several business func- for efficiency and progress toward
tions of various levels of business criticality. mitigating known flaws

Success Metrics
B. Establish release gates for design review ✦✦>80% of projects with updated data-
flow diagrams in past 6 months
Having established a consistent design review program, the next step of enforcement is
✦✦>75% of projects passing design
to set a particular point in the software development life-cycle where a project cannot
review audit in past 6 months
pass until an design review is conducted and findings are reviewed and accepted. In order
to accomplish this, a baseline level of expectations should be set, e.g. no projects with any Costs
high-severity findings will be allowed to pass and all other findings must be accepted by the ✦✦Ongoing project overhead from
business owner. maintenance of data-flow diagrams
Generally, design reviews should occur toward the end of the design phase to aide early ✦✦Organization overhead from
detection of security issues, but it must occur before releases can be made from the project project delays caused by failed
team. design review audits

For legacy systems or inactive projects, an exception process should be created to allow Personnel
those projects to continue operations, but with an explicitly assigned time-frame for each to ✦✦Developers
be reviewed to illuminate any hidden vulnerabilities in the existing systems. Exceptions for ✦✦Architects
should be limited to no more than 20% of all projects.
✦✦Managers
✦✦Business Owners
✦✦Security Auditors

Related Levels
SAMM / The Security Practices - v1.1

✦✦Secure Architecture - 3
✦✦Code Review - 3

51
 Implementation Review

IR 1 IR 2 IR 3
Objective Opportunistically find basic Make implementation Mandate comprehensive
code-level vulnerabilities and review during development code review process to
other high-risk security issues more accurate and efficient discover language-level and
through automation application-specific risks

Activities A. Create review checklists from A. Utilize automated code A. Customize code analysis for
known security requirements analysis tools application-specific concerns
B. Perform point-review B. Integrate code analysis into B. Establish release gates for
of high-risk code development process implementation review

Assessment ✦✦Do project teams have review ✦✦Can project teams access ✦✦Do project teams utilize
checklists based on common automated code analysis tools automation to check code
security related problems? to find security problems? against application-specific
✦✦Do project teams review ✦✦Do stakeholders consistently coding standards?
selected high-risk code? review results from code reviews? ✦✦Does a minimum security
baseline exist for code
review results?

Results ✦✦Inspection for common ✦✦Development enabled to ✦✦Increased confidence in

configuration or code consistently self-check for code- accuracy and applicability
vulnerabilities that lead to level security vulnerabilities of code analysis results
likely discovery or attack ✦✦Routine analysis results to ✦✦Organization-wide
✦✦Lightweight review for compile historic data on per- baseline for secure
coding errors that lead to team secure coding habits coding expectations
severe security impact ✦✦Stakeholders aware of ✦✦Project teams with an
✦✦Basic code-level due diligence unmitigated vulnerabilities to objective goal for judging
for security assurance support better tradeoff analysis code-level security
SAMM / The Security Practices - v1.1

52
 Implementation Review IR 1
Opportunistically find basic code-level vulnerabilities and other high-risk security issues

Activities
Assessment
A. Create review checklists from known security requirements
✦✦Do project teams have review
From the known security requirements for a project, derive a lightweight implementation checklists based on common
review checklist for security. These can be checks specific to the security concerns sur- security related problems?
rounding the functional requirements or checks for secure coding best practices based on ✦✦Do project teams review
the implementation language, platform, typical technology stack, etc. Due to these variations, selected high-risk code
often a set of checklist are needed to cover the different types of software development
within an organization. Results
Regardless of whether created from publicly available resources or purchased, technical ✦✦Inspection for common configuration
or code vulnerabilities that lead
stakeholders such as development managers, architects, developers, and security auditors
to likely discovery or attack
should review the checklists for efficacy and feasibility. It is important to keep the lists short
✦✦Lightweight review for coding errors
and simple, aiming to catch high-priority issues that are straightforward to find in code either that lead to severe security impact
manually or with simple search tools. Code analysis automation tools may also be used to
✦✦Basic code-level due diligence
achieve this same end, but should also be customized to reduce the overall set of security for security assuranc
checks to a small, valuable set in order to make the scan and review process efficient.
Developers should be briefed on the goals of checklists appropriate to their job function. Success Metrics
✦✦>80% of project teams briefed
on relevant code review
B. Perform point-review of high-risk code checklists in past 6 months
✦✦>50% of project teams performing
Since code-level vulnerabilities can have dramatically increased impacts if they occur in se-
code review on high-risk
curity-critical parts of software, project teams should review high-risk modules for common code in past 6 months
vulnerabilities. Common examples of high-risk functionality include authentication modules, ✦✦>3.0 Likert on usefulness of code review
access control enforcement points, session management schemes, external interfaces, input checklists reported by developers
validators and data parsers, etc.
Utilizing the implementation review checklists, the analysis can be performed as a normal Costs
part of the development process where members of the project team are assigned modules ✦✦Buildout or license of code
to review when changes are made. Security auditors and automated review tools can also review checklists
be utilized for the review. ✦✦Ongoing project overhead from code
review activities of high-risk code
During development cycles where high-risk code is being changed and reviewed, develop-
ment managers should triage the findings and prioritize remediation appropriately with input Personnel
from other project stakeholders. ✦✦Developers
✦✦Architects
✦✦Managers
✦✦Business Owners

Related Levels
SAMM / The Security Practices - v1.1

✦✦Security Requirements - 1

53
 IR 2 Implementation Review
Make implementation review during development more accurate and efficient through automation

Activities
Assessment
A. Utilize automated code analysis tools
✦✦Can project teams access
automated code analysis tools Although any such tool can produce false positives, it can save a lot of time and energy, by
to find security problems? helping focus attention on the most suspicious sections of code.
✦✦Do stakeholders consistently review Many security vulnerabilities at the code level are complex to understand and require care-
results from code reviews? ful inspection for discovery. However, there are many useful automation solutions available
Results to automatically analyze code for bugs and vulnerabilities.
✦✦Development enabled to There are both commercial and open-source products available to cover popular program-
consistently self-check for code- ming languages and frameworks. Selection of an appropriate code analysis solution is based
level security vulnerabilities on several factors including depth and accuracy of inspection, product usability and usage
✦✦Routine analysis results to model, expandability and customization features, applicability to the organization’s architec-
compile historic data on per- ture and technology stack(s), etc.
team secure coding habits
Utilize input from security-savvy technical staff as well as developers and development man-
✦✦Stakeholders aware of unmitigated
agers in the selection process, and review overall results with stakeholders.
vulnerabilities to support
better tradeoff analysis

Success Metrics B. Integrate code analysis into development process

✦✦>50% of projects with code review and Once a code analysis solution is selected, it must be integrated into the development process
stakeholder sign-off in past 6 months to encourage project teams to utilize its capabilities. An effective way to accomplish this is to
✦✦>80% of projects with access setup the infrastructure for the scans to run automatically at build time or from code in the
to automated code review project’s code repository. In this fashion, results are available earlier thus enabling develop-
results in past 1 month ment teams to self-check along the way before release.
Costs A potential problem with legacy systems or large ongoing projects is that code scanners will
✦✦Research and selection of
typically report findings in modules that were not being updated in the release. If automatic
code analysis solution scanning is setup to run periodically, an effective strategy to avoid review overhead is to
✦✦Initial cost and maintenance of limit consideration of findings to those that have been added, removed, or changed since
automation integration the previous scan. It is critical to not ignore the rest of the results however, so development
✦✦Ongoing project overhead from managers should take input from security auditors, stakeholders, and the project team to
automated code review and mitigation formulate a concrete plan for addressing the rest of the findings.
If unaddressed findings from implementation review remain at release, these must be re-
Personnel
viewed, assigned a risk rating and accepted by project stakeholders.
✦✦Developers
✦✦Architects
✦✦Managers
✦✦Security Auditors
SAMM / The Security Practices - v1.1

Related Levels
✦✦

54
 Implementation Review IR 3
Mandate comprehensive implementation review process to discover language-level and application-specific risks

Activities
Assessment
A. Customize code analysis for application-specific concerns
✦✦Do project teams utilize automation
Code scanning tools are powered by built-in a knowledge-base of rules to check code based to check code against application-
on language APIs and commonly used libraries, but have limited ability to understand custom specific coding standards?
APIs and designs to apply analogous checks. However, through customization, a code scan- ✦✦Does a minimum security baseline
ner can be a powerful, generic analysis engine for finding organization and project-specific exist for code review results?
security concerns.
Results
While details vary between tools in terms of ease and power of custom analysis, code scan-
ner customization generally involves specifying checks to be performed at specific APIs and ✦✦Increased confidence in accuracy and
applicability of code analysis results
function call sites. Checks can include analysis for adherence to internal coding standards,
✦✦Organization-wide baseline for
unchecked tainted data being passed to custom interfaces, tracking and verification of sensi-
secure coding expectations
tive data handling, correct usage of an internal API, etc.
✦✦Project teams with an objective goal
Checkers for usage of shared code-bases are an effective place to begin scanner customiza- for judging code-level security
tions since the created checkers can be utilized across multiple projects.To customize a tool
for a code-base, a security auditor should inspect both code and high-level design to identify Success Metrics
candidate checkers to discuss with development staff and stakeholders for implementation. ✦✦>50% of projects using code
analysis customizations
✦✦>75% of projects passing code
B. Establish release gates for implementation review review audit in past 6 months
To set a code-level security baseline for all software projects, a particular point in the soft- Costs
ware development life-cycle should be established as a checkpoint where a minimum stan-
✦✦Buildout and maintenance of
dard for implementation review results must be met in order to make a release.
custom code review checks
To begin, this standard should be straightforward to meet, for example by choosing one or ✦✦Ongoing project overhead
two vulnerability types and a setting the standard that no project may pass with any corre- from code review audit
sponding findings. Over time, this baseline standard should be improved by adding additional ✦✦Organization overhead from project
criteria for passing the checkpoint. delays caused by failed code review audits
Generally, the implementation review checkpoint should occur toward the end of the imple- Personnel
mentation phase, but must occur before release.
✦✦Architects
For legacy systems or inactive projects, an exception process should be created to allow ✦✦Developers
those projects to continue operations, but with an explicitly assigned timeframe for mitiga- ✦✦Security Auditors
tion of findings. Exceptions should be limited to no more that 20% of all projects.
✦✦Business Owners
✦✦Managers

Related Levels
✦✦Policy & Compliance - 2
SAMM / The Security Practices - v1.1

✦✦Secure Architecture - 3

55
 Security Testing

ST 1 ST 2 ST 3
Objective Establish process to perform Make security testing Require application-
basic security tests based during development more specific security testing to
on implementation and complete and efficient ensure baseline security
software requirements through automation before deployment

Activities A. Derive test cases from known A. Utilize automated A. Employ application-specific
security requirements security testing tools security testing automation
B. Conduct penetration testing B. Integrate security testing B. Establish release gates
on software releases into development process for security testing

Assessment ✦✦Do projects specify security ✦✦Do projects use automation to ✦✦Are security test cases
testing based on defined evaluate security test cases? comprehensively generated
security requirements? ✦✦Do projects follow a consistent for application-specific logic?
✦✦Is penetration testing process to evaluate and report ✦✦Does a minimum
performed on high risk on security tests to stakeholders? security baseline exist
projects prior to release? for security testing?
✦✦Are stakeholders aware
of the security test status
prior to release?

Results ✦✦Independent verification ✦✦Deeper and more consistent ✦✦Organization-wide baseline

of expected security verification of software for expected application
mechanisms surrounding functionality for security performance against attacks
critical business functions ✦✦Development teams enabled ✦✦Customized security test
✦✦High-level due diligence to self-check and correct suites to improve accuracy
toward security testing problems before release of automated analysis
✦✦Ad hoc growth of a security test ✦✦Stakeholders better aware of ✦✦Project teams aware
suite for each software project open vulnerabilities when making of objective goals for
risk acceptance decisions attack resistance
SAMM / The Security Practices - v1.1

56
 Security Testing ST 1
Establish process to perform basic security tests based on implementation and software requirements

Activities
Assessment
A. Derive test cases from known security requirements
✦✦Do projects specify security testing
From the known security requirements for a project, identify a set of test cases to check the based on defined security requirements?
software for correct functionality. Typically, these test cases are derived from security con- ✦✦Is penetration testing performed on
cerns surrounding the functional requirements and business logic of the system, but should high risk projects prior to release?
also include generic tests for common vulnerabilities based on the implementation language ✦✦Are stakeholders aware of the
or technology stack. security test status prior to release?
Often, it is most effective to use the project team’s time to build application-specific test
Results
cases and utilize publicly available resources or purchased knowledge bases to select appli-
cable general test cases for security. Although not required, automated security testing tools ✦✦Independent verification of expected
security mechanisms surrounding
can also be utilized to cover the general security test cases.
critical business functions
This test case planning should occur during the requirements and/or design phases, but must ✦✦High-level due diligence
occur before final testing prior to release. Candidate test cases should be reviewed for ap- toward security testing
plicability, efficacy, and feasibility by relevant development, security, and quality assurance staff. ✦✦Ad hoc growth of a security test
suite for each software project

B. Conduct penetration testing on software releases Success Metrics

Using the set of security test cases identified for each project, penetration testing should be ✦✦>50% of projects specifying security
conducted to evaluate the system’s performance against each case. It is common for this to test cases in past 12 months
occur during the testing phase prior to release. ✦✦>50% of stakeholders briefed on
project status against security
Penetration testing cases should include both application-specific tests to check soundness tests in past 6 months
of business logic as well as common vulnerability tests to check the design and implementa-
tion. Once specified, security test cases can be executed by security-savvy quality assurance Costs
or development staff, but first-time execution of security test cases for a project team should ✦✦Buildout or license of security test cases
be monitored by a security auditor to assist and coach team members. ✦✦Ongoing project overhead from
Prior to release or deployment, stakeholders must review results of security tests and ac- maintenance and evaluation
of security test cases
cept the risks indicated by failing security tests at release time. In the latter case, a concrete
timeline should be established to address the gaps over time. Personnel
✦✦QA Testers
✦✦Security Auditor
✦✦Developers
✦✦Architects
✦✦Business Owners

Related Levels
SAMM / The Security Practices - v1.1

✦✦Security Requirements - 1

57
 ST 2 Security Testing
Make security testing during development more complete and efficient through automation

Activities
Assessment
A. Utilize automated security testing tools
✦✦Do projects use automation to
evaluate security test cases? In order to test for security issues, a potentially large number of input cases must be checked
✦✦Do projects follow a consistent against each software interface, which can make effective security testing using manual test
process to evaluate and report on case implementation and execution unwieldy. Thus, automated security test tools should be
security tests to stakeholders? used to automatically test software, resulting in more efficient security testing and higher
quality results.
Results
Both commercial and open-source products are available and should be reviewed for appro-
✦✦Deeper and more consistent verification priateness for the organization. Selecting a suitable tool is based on several factors including
of software functionality for security
robustness and accuracy of built-in security test cases, efficacy at testing architecture types
✦✦Development teams enabled
important to organization, customization to change or add test cases, quality and usability of
to self-check and correct
problems before release
findings to the development organization, etc..
✦✦Stakeholders better aware of Utilize input from security-savvy technical staff as well as development and quality assurance
open vulnerabilities when making staff in the selection process, and review overall results with stakeholders.
risk acceptance decisions

Success Metrics B. Integrate security testing into development process

✦✦>50% of projects with security testing
With tools to run automated security tests, projects within the organization should routinely
and stakeholder sign-off in past 6 months
run security tests and review results during development. In order to make this scalable with
✦✦>80% of projects with access
low overhead, security testing tools should be configured to automatically run on a routine
to automated security testing
results in past 1 month basis, e.g. nightly or weekly, and findings should be inspected as they occur.
Conducting security tests as early as the requirements or design phases can be beneficial.
Costs While traditionally, used for functional test cases, this type of test-driven development ap-
✦✦Research and selection of automated proach involves identifying and running relevant security test cases early in the development
security testing solution cycle, usually during design. With the automatic execution of security test cases, projects
✦✦Initial cost and maintenance of enter the implementation phase with a number of failing tests for the non-existent function-
automation integration ality. Implementation is complete when all the tests pass. This provides a clear, upfront goal
✦✦Ongoing project overhead from for developers early in the development cycle, thus lowering risk of release delays due to
automated security testing and mitigation security concerns or forced acceptance of risk in order to meet project deadlines.
Personnel For each project release, results from automated and manual security tests should be pre-
✦✦Developers sented to management and business stakeholders for review. If there are unaddressed find-
✦✦Architects ings that remain as accepted risks for the release, stakeholders and development managers
✦✦Managers
should work together to establish a concrete timeframe for addressing them.
✦✦Security Auditors
✦✦QA Testers
SAMM / The Security Practices - v1.1

Related Levels
✦✦

58
 Security Testing ST 3
Require application-specific security testing to ensure baseline security before deployment

Activities
Assessment
A. Employ application-specific security testing automation
✦✦Are security test cases comprehensively
Through either customization of security testing tools, enhancements to generic test case generated for application-specific logic?
execution tools, or buildout of custom test harnesses, project teams should formally iterate ✦✦Does a minimum security baseline
through security requirements and build a set of automated checkers to test the security of exist for security testing?
the implemented business logic.
Results
Additionally, many automated security testing tools can be greatly improved in accuracy
and depth of coverage if they are customized to understand more detail about the specific ✦✦Organization-wide baseline for expected
software interfaces in the project under test. Further, organization-specific concerns from application performance against attacks
compliance or technical standards can be codified as a reusable, central test battery to make ✦✦Customized security test suites to
improve accuracy of automated analysis
audit data collection and per-project management visibility simpler.
✦✦Project teams aware of objective
Project teams should focus on buildout of granular security test cases based on the busi- goals for attack resistance
ness functionality of their software, and an organization-level team led by a security auditor
should focus on specification of automated tests for compliance and internal standards. Success Metrics
✦✦>50% of projects using security
testing customizations
B. Establish release gates for security testing ✦✦>75% of projects passing all
To prevent software from being released with easily found security bugs, a particular point security tests in past 6 months
in the software development life-cycle should be identified as a checkpoint where an estab-
Costs
lished set of security test cases must pass in order to make a release from the project. This
establishes a baseline for the kinds of security tests all projects are expected to pass. ✦✦Buildout and maintenance of
customizations to security
Since adding too many test cases initially can result in an overhead cost bubble, begin by testing automation
choosing one or two security issues and include a wide variety of test cases for each with ✦✦Ongoing project overhead from
the expectation that no project may pass if any test fails. Over time, this baseline should be security testing audit process
improved by selecting additional security issues and adding a variety of corresponding test ✦✦Organization overhead from
cases. project delays caused by failed
security testing audits
Generally, this security testing checkpoint should occur toward the end of the implementa-
tion or testing, but must occur before release. Personnel
For legacy systems or inactive projects, an exception process should be created to allow ✦✦Architects
those projects to continue operations, but with an explicitly assigned timeframe for mitiga- ✦✦Developers
tion of findings. Exceptions should be limited to no more that 20% of all projects. ✦✦Security Auditors
✦✦QA Testers
✦✦Business Owners
✦✦Managers
SAMM / The Security Practices - v1.1

Related Levels
✦✦Policy & Compliance - 2
✦✦Secure Architecture - 3

59
 Issue Management

IM 1 IM 2 IM 3
Objective Understand high-level plan Elaborate expectations Improve analysis and data
for responding to issue for response process gathering within response
reports or incidents to improve consistency process for feedback into
and communications proactive planning

Activities A. Identify point of contact A. Establish consistent incident A. Conduct root cause
for security issues response process analysis for incidents
B. Create informal security B. Adopt a security issue B. Collect per-incident metrics
response team(s) disclosure process

Assessment ✦✦Do projects have a point ✦✦Does the organization utilize a ✦✦Are incidents inspected for
of contact for security consistent process for incident root causes to generate
issues or incidents? reporting and handling? further recommendations?
✦✦Does your organization have an ✦✦Are project stakeholders ✦✦Do projects consistently
assigned security response team? aware of relevant security collect and report data and
✦✦Are project teams aware disclosures related to their metrics related to incidents?
of their security point(s) of software projects?
contact and response team(s)?

Results ✦✦Lightweight process in place ✦✦Communications plan for ✦✦Detailed feedback for
to handle high-priority dealing with issue reports organizational improvement
issues or incidents from third-parties after each incident
✦✦Framework for stakeholder ✦✦Clear process for releasing ✦✦Rough cost estimation from
notification and reporting of security patches to issue and compromises
events with security impact software operators ✦✦Stakeholders better able to
✦✦High-level due diligence for ✦✦Formal process for tracking, make tradeoff decisions based
handling security issues handling, and internally on historic incident trends
communicating about incidents
SAMM / The Security Practices - v1.1

60
 Issue Management IM 1
Understand high-level plan for responding to issue reports or incidents

Activities
Assessment
A. Identify point of contact for security issues
✦✦Do projects have a point of contact
For each division within the organization or for each project team, establish a point of con- for security issues or incidents?
tact to serve as a communications hub for security information. While generally this respon- ✦✦Does your organization have an
sibility will not claim much time from the individuals, the purpose of having a predetermined assigned security response team?
point of contact is to add structure and governance for vulnerability management. ✦✦Are project teams aware of their security
Examples of incidents that might cause the utilization include receipt of a vulnerability report point(s) of contact and response team(s)?
from an external entity, compromise or other security failure of software in the field, inter-
Results
nal discovery of high-risk vulnerabilities, etc. In case of an event, the closest contact would
step in as an extra resource and advisor to the affected project team(s) to provide technical ✦✦Lightweight process in place to handle
high-priority issues or incidents
guidance and brief other stakeholders on progress of mitigation efforts.
✦✦Framework for stakeholder
The point of contact should be chosen from security-savvy technical or management staff notification and reporting of
with a breadth of knowledge over the software projects in the organization. A list of these events with security impact
assigned security points of contact should be centrally maintained and updated at least every ✦✦High-level due diligence for
six months.Additionally, publishing and advertising this list allows staff within the organization handling security issues
to request help and work directly with one another on security problems.
Success Metrics
✦✦>50% of the organization briefed
B. Create informal security response team(s) on closest security point of
contact in past 6 months
From the list of individuals assigned responsibility as a security point of contact or from
✦✦>1 meeting of security response team
dedicated security personnel, select a small group to serve as a centralized technical security
and points of contact in past 12 months
response team. The responsibilities of the team will include directly taking ownership of se-
curity incidents or issue reports and being responsible for triage, mitigation, and reporting Costs
to stakeholders.
✦✦Ongoing variable project overhead
Given their responsibility when tapped, members of the security response team are also from staff filling the security
responsible for executive briefings and upward communication during an incident. It is likely point of contact roles
that most of the time, the security response team would not be operating in this capacity, ✦✦Identification of appropriate
though they must be flexible enough to be able to respond quickly or a smooth process must security response team
exist for deferring and incident to another team member.
Personnel
The response team should hold a meeting at least annually to brief security points of contact ✦✦Security Auditors
on the response process and high-level expectations for security-related reporting from
✦✦Architects
project teams.
✦✦Managers
✦✦Business Owners

Related Levels
SAMM / The Security Practices - v1.1

✦✦Education & Guidance - 2

✦✦Strategy & Metrics - 3

61
 IM 2 Issue Management
Elaborate expectations for response process to improve consistency and communications

Activities
Assessment
A. Establish consistent incident response process
✦✦Does the organization utilize a
consistent process for incident Extending from the informal security response team, explicitly document the organization’s
reporting and handling? incident response process as well as the procedures that team members are expected to
✦✦Are project stakeholders aware of follow. Additionally, each member of the security response team must be trained on this
relevant security disclosures related material at least annually.
to their software projects?
There are several tenets to sound incident response process and they include initial triage
Results to prevent additional damage, change management and patch application, managing project
personnel and others involved in the incident, forensic evidence collection and preservation,
✦✦Communications plan for dealing with
limiting communication about the incident to stakeholders, well-defined reporting to stake-
issue reports from third-parties
holders and/or communications trees, etc.
✦✦Clear process for releasing security
patches to software operators With development teams, the security responders should work together to conduct the
✦✦Formal process for tracking, handling, and technical analysis to verify facts and assumptions about each incident or issue report. Like-
internally communicating about incidents wise, when project teams detect an incident or high-risk vulnerability, they should follow an
internal process that puts them in contact with a member of the security response team.
Success Metrics
✦✦>80% of project teams
briefed on incident response B. Adopt a security issue disclosure process
process in past 6 months
For most organizations, it is undesirable to let news of a security problem become public, but
✦✦>80% of stakeholders briefed on security
there are several important ways in which internal-to-external communications on security
issue disclosures in past 6 months
issues should be fulfilled.
Costs The first and most common is through creation and deployment of security patches for
✦✦Ongoing organization overhead the software produced by the organization. Generally, if all software projects are only used
from incident response process internally, then this becomes less critical, but for all contexts where the software is being
operated by parties external to the organization, a patch release process must exist. It should
Personnel provide for several factors including change management and regression testing prior to
✦✦Security Auditors patch release, announcement to operators/users with assigned criticality category for the
✦✦Managers patch, sparse technical details so that an exploit cannot be directly derived, etc.
✦✦Business Owners
Another avenue for external communications is with third parties that report security vul-
✦✦Support/Operators nerabilities in an organization’s software. By adopting and externally posting the expected
Related Levels process with timeframes for response, vulnerability reporters are encouraged to follow
responsible disclosure practices.
✦✦
Lastly, many states and countries legally require external communications for incidents in-
volving data theft of personally identifiable information and other sensitive data type. Should
this type of incident occur, the security response team should work with managers and busi-
ness stakeholders to determine appropriate next-steps.
SAMM / The Security Practices - v1.1

62
 Issue Management IM 3
Improve analysis and data gathering within response process for feedback into proactive planning

Activities
Assessment
A. Conduct root cause analysis for incidents
✦✦Are incidents inspected for root causes
Though potentially time consuming, the incident response process should be augmented to to generate further recommendations?
include additional analysis to identify the key, underlying security failures. These root causes ✦✦Do projects consistently collect
can be technical problems such as code-level vulnerabilities, configuration errors, etc. or they and report data and metrics
can be people/process problems such as social engineering, failure to follow procedures, etc. related to incidents?
Once a root cause is identified for an incident, it should be used as a tool to find other Results
potential weaknesses in the organization where an analogous incident could have occurred.
For each identified weakness additional recommendations for proactive mitigations should ✦✦Detailed feedback for organizational
improvement after each incident
be communicated as part of closing out the original incident response effort.
✦✦Rough cost estimation from
Any recommendations based on root cause analysis should be reviewed by management and issue and compromises
relevant business stakeholders in order to either schedule mitigation activities or note the ✦✦Stakeholders better able to
accepted risks. make tradeoff decisions based
on historic incident trends

B. Collect per-incident metrics Success Metrics

By having a centralized process to handle all compromise and high-priority issue reports, an ✦✦>80% of incidents documented
with root causes and further
organization is enabled to take measurements of trends over time to determine impact and
recommendations in past 6 months
efficiency of initiatives for security assurance.
✦✦>80% of incidents collated for
Records of past incidents should be stored and reviewed at least every 6 months. Group metrics in the past 6 months
similar incidents and simply tally the overall count for each type of problem. Additional
measurements to take from the incidents include frequency of software projects affected by Costs
incidents, system downtime and cost from loss of use, human resources taken in handling ✦✦Ongoing organization overhead
and cleanup of the incident, estimates of long-term costs such as regulatory fines or brand from conducting deeper research
damage, etc. For root causes that were technical problems in nature, it is also helpful to and analysis of incidents
identify what kind of proactive, review, or operational practice might have detected it earlier ✦✦Ongoing organization overhead from
or lessened the damage. collection and review of incident metrics

This information is concrete feedback into the program planning process since it represents Personnel
the real security impact that the organization has felt over time. ✦✦Security Auditors
✦✦Managers
✦✦Business Owners
✦✦Support/Operators

Related Levels
✦✦Strategy & Metrics - 3
SAMM / The Security Practices - v1.1

63
 Environment Hardening

EH 1 EH 2 EH 3
Objective Understand baseline Improve confidence in Validate application health
operational environment application operations by and status of operational
for applications and hardening the operating environment against
software components environment known best practices

Activities A. Maintain operational A. Establish routine patch A. Identify and deploy relevant
environment specification management process operations protection tools
B. Identify and install critical B. Monitor baseline environment B. Expand audit program for
security upgrades and patches configuration status environment configuration

Assessment ✦✦Do projects document ✦✦Is a consistent process used ✦✦Are stakeholders aware of
operational environment to apply upgrades and patches options for additional tools
security requirements? to critical dependencies? to protect software while
✦✦Do projects check for security ✦✦Do projects leverage automation running in operations?
updates to third-party to check application and ✦✦Does a minimum
software components? environment health? security baseline exist
for environment health
(versioning, patching, etc)?

Results ✦✦Clear understanding of ✦✦Granular verification of ✦✦Reinforced operational

operational expectations security characteristics of environment with layered
within the development team systems in operations checks for security
✦✦High-priority risks from ✦✦Formal expectations on timelines ✦✦Established and measured
underlying infrastructure for infrastructure risk mitigation goals for operational
mitigated on a well- ✦✦Stakeholders consistently maintenance and performance
understood timeline aware of current operations ✦✦Reduced likelihood of
✦✦Software operators with a high- status of software projects successful attack via flaws
level plan for security-critical in external dependencies
maintenance of infrastructure
SAMM / The Security Practices - v1.1

64
 Environment Hardening EH 1
Understand baseline operational environment for applications and software components

Activities
Assessment
A. Maintain operational environment specification
✦✦Do projects document operational
For each project, a concrete definition of the expected operating platforms should be cre- environment security requirements?
ated and maintained. Depending on the organization, this specification should be jointly cre- ✦✦Do projects check for security updates
ated with development staff, stakeholders, support and operations groups, etc. to third-party software components?
Begin this specification should by capturing all details that must be true about the operating
Results
environment based upon the business function of the software. These can include factors
such as processor architecture, operating system versions, prerequisite software, conflict- ✦✦Clear understanding of
ing software, etc. Further, note any known user or operator configurable options about the operational expectations within
the development team
operating environment that affect the way in which the software will behave.
✦✦High-priority risks from underlying
Additionally, identify any relevant assumptions about the operating environment that were infrastructure mitigated on a
made in design and implementation of the project and capture those assumptions in the well-understood timeline
specification. ✦✦Software operators with a high-
level plan for security-critical
This specification should be reviewed and updated at least every 6 months for active projects
maintenance of infrastructure
or more often if changes are being made to the software design or the expected operating
environment. Success Metrics
✦✦>50% project with updated
operational environment
B. Identify and install critical security upgrades and patches specification in past 6 months
Most applications are software that runs on top of another large stack of software com- ✦✦>50% of projects with updated
posed of built-in programming language libraries, third-party components and development list of relevant critical security
frameworks, base operating systems, etc. Because security flaws contained in any module in patches in past 6 months
that large software stack affect the overall security of the organization’s software, critical
Costs
security updates for elements of the technology stack must be installed.
✦✦Ongoing project overhead from
As such, regular research or ongoing monitoring of high-risk dependencies should be per- buildout and maintenance of operational
formed to stay abreast of the latest fixes to security flaws. Upon identification of a critical environment specification
upgrade or patch that would impact the security posture of the software project, plans ✦✦Ongoing project overhead
should be made to get affected users and operators to update their installations. Depending from monitoring and installing
on the type of software project, details on doing this can vary. critical security updates

Personnel
✦✦Developers
✦✦Architects
✦✦Managers
✦✦Support/Operators
SAMM / The Security Practices - v1.1

Related Levels
✦✦Operational Enablement - 2

65
 EH 2 Environment Hardening
Improve confidence in application operations by hardening the operating environment

Activities
Assessment
A. Establish routine patch management process
✦✦Is a consistent process used
to apply upgrades and patches Moving to a more formal process than ad hoc application of critical upgrades and patches,
to critical dependencies? an ongoing process should be created in the organization to consistently apply updates to
✦✦Do projects leverage automation software dependencies in the operating environment.
to check application and In the most basic form, the process should aim to make guarantees for time lapse between
environment health?
release and application of security upgrades and patches.To make this process efficient, orga-
Results nizations typically accept high latency on lower priority updates, e.g. maximum of 2 days for
critical patches spanning to a maximum of 30 days for low priority patches.
✦✦Granular verification of security
characteristics of systems in operations This activity should be primarily conducted by support and operations staff, but routine
✦✦Formal expectations on timelines meetings with development should also be conducted to keep the whole project abreast of
for infrastructure risk mitigation past changes and scheduled upgrades.
✦✦Stakeholders consistently Additionally, development staff should share a list of third-party components upon which the
aware of current operations
software project internally depends so that support and operations staff can monitor those
status of software projects
as well to cue development teams on when an upgrade is required.
Success Metrics
✦✦>80% of project teams briefed on patch
B. Monitor baseline environment configuration status
management process in past 12 months
✦✦>80% of stakeholders aware of current Given the complexity of monitoring and managing patches alone across the variety of com-
patch status in past 6 months ponents composing the infrastructure for a software project, automation tools should be
utilized to automatically monitor systems for soundness of configuration.
Costs
There are both commercial and open-source tools available to provide this type of function-
✦✦Ongoing organization overhead from
ality, so project teams should select a solution based on appropriateness to the organization’s
patch management and monitoring
needs. Typical selection criteria includes ease of deployment and customization, applicability
✦✦Buildout or license of infrastructure
to the organization’s platforms and technology stacks, built-in features for change manage-
monitoring tools
ment and alerting, metrics collection and trend tracking etc.
Personnel In addition to host and platform checks, monitoring automation should be customized to
✦✦Architects perform application-specific health checks and configuration verifications. Support and op-
✦✦Developers erations personnel should work with architects and developers to determine the optimal
✦✦Business Owners amount of monitoring for a given software project.
✦✦Managers Ultimately, after a solution is deployed for monitoring the environment’s configuration status,
✦✦Support/Operators unexpected alerts or configuration changes should be collected and regularly reviewed by
project stakeholders as often as weekly but at least once per quarter.
Related Levels
✦✦
SAMM / The Security Practices - v1.1

66
 Environment Hardening EH 3
Validate application health and status of operational environment against known best practices

Activities
Assessment
A. Identify and deploy relevant operations protection tools
✦✦Are stakeholders aware of options for
In order to build a better assurance case for software in its operating environment, addi- additional tools to protect software
tional tools can be used to enhance the security posture of the overall system. Operational while running in operations?
environments can vary dramatically, thus the appropriateness of given protection technology ✦✦Does a minimum security baseline
should be considered in the project context. exist for environment health
(versioning, patching, etc)?
Commonly used protections tools include web application firewalls, XML security gateways
for web services, anti-tamper and obfuscation packages for client/embedded systems, net- Results
work intrusion detection/prevention systems for legacy infrastructure, forensic log aggrega-
✦✦Reinforced operational environment
tion tools, host-based integrity verification tools, etc.
with layered checks for security
Based on the organization and project-specific knowledge, technical stakeholders should ✦✦Established and measured goals
work with support and operations staff to identify and recommend selected operations for operational maintenance
protection tools to business stakeholders. If deemed a valuable investment in terms of risk- and performance
reduction versus cost of implementation, stakeholders should agree on plans for a pilot, ✦✦Reduced likelihood of successful attack
widespread rollout, and ongoing maintenance. via flaws in external dependencies

Success Metrics
B. Expand audit program for environment configuration ✦✦>80% of stakeholders briefed on
relevant operations protection
When conducting routine project-level audits, expand the review to include inspection of tools in past 6 months
artifacts related to hardening the operating environment. Beyond an up-to-date specification
✦✦>75% of projects passing infrastructure
for the operational environment, audits should inspect current patch status and historic audits in past 6 months
data since the previous audit. By tapping into monitoring tools, audits can also verify key
factors about application configuration management and historic changes. Audits should also Costs
inspect the usage of operations protections tools against those available for the software’s ✦✦Research and selection of
architecture type. operations protection solutions
Audits for infrastructure can occur at any point after a project’s initial release and deploy- ✦✦Buildout or license of operations
ment, but should occur at least every 6 months. For legacy systems or projects without protections tools
active development, infrastructure audits should still be conducted and reviewed by busi- ✦✦Ongoing operations overhead from
ness stakeholders. An exception process should be created to allow special-case projects maintenance of protection tools
to continue operations, but with an explicitly assigned timeframe for mitigation of findings. ✦✦Ongoing project overhead from
Exceptions should be limited to no more that 20% of all projects. infrastructure-related audits

Personnel
✦✦Business Owners
✦✦Managers
✦✦Support/Operators
SAMM / The Security Practices - v1.1

Related Levels
✦✦Policy & Compliance - 2

67
 Operational Enablement

OE 1 OE 2 OE 3
Objective Enable communications Improve expectations Mandate communication
between development teams for continuous secure of security information
and operators for critical operations through provision and validate artifacts
security-relevant data of detailed procedures for completeness

Activities A. Capture critical security C. Create per-release change A. Expand audit program for
information for deployment? management procedures operational information
B. Document procedures for D. Maintain formal operational B. Perform code signing for
typical application alerts security guides application components

Assessment ✦✦Are security notes delivered ✦✦Do projects utilize a change ✦✦Are project releases audited
with each software release? management process for appropriate operational
✦✦Are security-related alerts and that’s well understood? security information?
error conditions documented ✦✦Do project teams deliver an ✦✦Is code signing routinely
on a per-project basis? operational security guide performed on software
with each product release? components using a
consistent process?

Results ✦✦Ad hoc improvements to ✦✦Detailed guidance for security- ✦✦Organization-wide

software security posture relevant changes delivered understanding of
through better understanding with software releases expectations for security-
of correct operations ✦✦Updated information relevant documentation
✦✦Operators and users aware repository on secure operating ✦✦Stakeholders better able
of their role in ensuring procedures per application to make tradeoff decisions
secure deployment ✦✦Alignment of operations based on feedback from
✦✦Improved communications expectations among developers, deployment and operations
between software developers operators, and users. ✦✦Operators and/or users
and users for security- able to independently verify
critical information integrity of software releases
SAMM / The Security Practices - v1.1

68
 Operational Enablement OE 1
Enable communications between development teams and operators for critical security-relevant data

Activities
Assessment
A. Capture critical security information for deployment
✦✦Are security notes delivered
With software-specific knowledge, project teams should identify any security-relevant con- with each software release?
figuration and operations information and communicate it to users and operators. This en- ✦✦Are security-related alerts and
ables the actual security posture of software at deployment sites to function in the same way error conditions documented
that designers in the project team intended. on a per-project basis?
This analysis should begin with architects and developers building a list of security features Results
built-in to the software. From that list, information about configuration options and their
security impact should be captured as well. For projects that offer several different deploy- ✦✦Ad hoc improvements to software
security posture through better
ment models, information about the security ramifications of each should be noted to better
understanding of correct operations
inform users and operators about the impact of their choices.
✦✦Operators and users aware of their
Overall, the list should be lightweight and aim to capture the most critical information. Once role in ensuring secure deployment
initially created, it should be reviewed by the project team and business stakeholders for ✦✦Improved communications between
agreement. Additionally, it is effective to review this list with select operators or users in software developers and users for
order to ensure the information is understandable and actionable. Project teams should re- security-critical information
view and update this information with every release, but must do so at least every 6 months.
Success Metrics
✦✦>50% of projects with updated
B. Document procedures for typical application alerts deployment security information
in past 6 months
With specific knowledge of ways in which software behaves, project teams should identify
✦✦>50% of projects with operational
the most important error and alert messages which require user/operator attention. From procedures for events updated
each identified event, information related to appropriate user/operator actions in response in past 6 months
to the event should be captured.
Costs
From the potentially large set of events that the software might generate, select the highest
priority set based on relevance in terms of the business purpose of the software.This should ✦✦Ongoing project overhead from
include any security-related events, but also may include critical errors and alerts related to maintenance of deployment
security information
software health and configuration status.
✦✦Ongoing project overhead
For each event, actionable advice should be captured to inform users and operators of from maintenance of critical
required next steps and potential root causes of the event. These procedures must be re- operating procedures
viewed by the project team and updated at every major product release, every 6 months, but
can be done more frequently, e.g. with each release. Personnel
✦✦Developers
✦✦Architects
✦✦Managers
✦✦Support/Operators
SAMM / The Security Practices - v1.1

Related Levels
✦✦

69
 OE 2 Operational Enablement
Improve expectations for continuous secure operations through provision of detailed procedures

Activities
Assessment
A. Create per-release change management procedures
✦✦Do projects utilize a change management
process that’s well understood? To more formally update users and operators on relevant changes in the software, each
✦✦Do project teams deliver an operational release must include change management procedures relevant to upgrade and first-time
security guide with each product release? installation. Overall, the goal is to capture the expected accompanying steps that ensure the
deployment will be successful and not incur excessive downtime or degradation of security
Results posture.
✦✦Detailed guidance for security-relevant To build these procedures during development, the project teams should setup a lightweight
changes delivered with software releases internal process for capturing relevant items that would impact deployments. It is effective to
✦✦Updated information have this process in place early in the development cycle so that this information can be re-
repository on secure operating
tained as soon as it is identified while in the requirements, design, and implementation phases.
procedures per application
✦✦Alignment of operations expectations Before each release, the project team should review the list as a whole for completeness
among developers, operators, and users. and feasibility. For some projects, extensive change procedures accompanying a given release
may warrant special handling, such as building automated upgrade scripts to prevent errors
Success Metrics during deployment.
✦✦>50% of projects with updated
change management procedures
in past 6 months B. Maintain formal operational security guides
✦✦>80% of stakeholders briefed Starting from the information captured on critical software events and the procedures for
on status of operational security
handling each, project teams should build and maintain formal guides that capture all the
guides in past 6 months
security-relevant information that users and operators need to know.
Costs Initially, this guide should be built from the known information about the system, such as
✦✦Ongoing project overhead security-related configuration options, event handling procedures, installation and upgrade
from maintenance of change guides, operational environment specifications, security-related assumptions about the de-
management procedures ployment environment, etc. Extending this, the formal operational security guide should
✦✦Ongoing project overhead from elaborate on each of these to cover more details such that the majority of the users and
maintenance of operational operators will be informed for all the questions they might have had. For large or complex
security guides
systems, this can be challenging, so project teams should work with business stakeholders to
Personnel determine the appropriate level of documentation. Additionally, project teams should docu-
ment any recommendations for deployments that would enhance security.
✦✦Developers
✦✦Architects The operational security guide, after initial creation, should be reviewed by project teams and
✦✦Managers updated with each release.
✦✦Support/Operators

Related Levels
SAMM / The Security Practices - v1.1

✦✦Environment Hardening - 1

70
 Operational Enablement OE 3
Mandate communication of security information and validate artifacts for completeness

Activities
Assessment
A. Expand audit program for operational information
✦✦Are project releases audited
When conducting routine project-level audits, expand the review to include inspection of ar- for appropriate operational
tifacts related to operational enablement for security. Projects should be checked to ensure security information?
they have an updated and complete operational security guides as relevant to the specifics ✦✦Is code signing routinely performed
of the software. on software components using
a consistent process?
These audits should begin toward the end of the development cycle close to release, but
must be completed and passed before a release can be made. For legacy systems or inactive Results
projects, this type of audit should be conducted and a one-time effort should be made to
✦✦Organization-wide understanding
address findings and verify audit compliance, after which additional audits for operational
of expectations for security-
enablement are no longer required. relevant documentation
Audit results must be reviewed with business stakeholders prior to release. An exception ✦✦Stakeholders better able to make
process should be created to allow projects failing an audit to continue with a release, but tradeoff decisions based on feedback
these projects should have a concrete timeline for mitigation of findings. Exceptions should from deployment and operations
be limited to no more that 20% of all active projects. ✦✦Operators and/or users able to
independently verify integrity
of software releases
B. Perform code signing for application components
Success Metrics
Though often used with special-purpose software, code signing allows users and operators ✦✦>80% of projects with
to perform integrity checks on software such that they can cryptographically verify the updated operational security
authenticity of a module or release. By signing software modules, the project team enables guide in last 6 months
deployments to operate with a greater degree of assurance against any corruption or modi- ✦✦>80% of stakeholders briefed
fication of the deployed software in its operating environment. on code signing options and
status in past 6 months
Signing code incurs overhead for management of signing credentials for the organization. An
organization must follow safe key management processes to ensure the ongoing confidential- Costs
ity of the signing keys. When dealing with any cryptographic keys, project stakeholders must
✦✦Ongoing project overhead from
also consider plans for dealing with common operational problems related to cryptography
audit of operational guides
such as key rotation, key compromise, or key loss.
✦✦Ongoing organization overhead from
Since code signing is not appropriate for everything, architects and developers should work management of code signing credentials
with security auditors and business stakeholders to determine which parts of the software ✦✦Ongoing project overhead
should be signed. As projects evolve, this list should be reviewed with each release, especially from identification and signing
when adding new modules or making changes to previously signed components. of code modules.

Personnel
✦✦Developers
✦✦Architects
SAMM / The Security Practices - v1.1

✦✦Managers
✦✦Security Auditors

Related Levels
✦✦

71
Sponsors
We would like to thank the following sponsors who donated funds to the OpenSAMM project

Belgium

London