Sei sulla pagina 1di 39

Software Assurance Maturity Model (SAMM) Interview Template

Version: 1.1

Authors: Nick Coblentz


Eoin Keary Assurance Maturity Model (SAMM) includes a set of questions used to evaluate an organi
The Software
Seba Deleersnyder
The SAMM Interview Template expands on those questions to include assertions that give further assura
answers. This document is intended to be used to help document and evaluate responses during interv
Description: managers, or other appropriate individuals.

Contributors:

License: Creative Commons Attribution-ShareAlike 3.0 License

This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/legalcode; or, (b) send a letter to Creative Commons, 171 2nd Street, Suite
94105, USA. Assurance Maturity Model (SAMM) was created by Pravir Chandra.
The Software
It is licensed under the Creative Commons Attribution-Share Alike 3.0 License
SAMM Website: http://www.opensamm.org
ew Template

ns used to evaluate an organization against the maturity model.


ertions that give further assurance as to the quality of individual's
uate responses during interviews with development staff,

w a copy of this license, visit


mons, 171 2nd Street, Suite 300, San Francisco, California,
Software Assurance Maturity Model (SAMM) Roadmap Chart Template
Version: 0.6

Author: Colin Watson, Watson Hall Ltd


colin(at)watsonhall.com
http://www.watsonhall.com/

Description: One aim of the Software Assurance Maturity Model (SAMM) is to help organizations build software security assurance
programs. The current position and future targets can be charted and the SAMM document includes roadmap templates
for different industries. This spreadsheet helps produce roadmaps once the plan is known. It is structured with four
phases of improvement, like in SAMM, although could be altered to suit any number of stages.

Contributors: Aidan Lynch

License: Creative Commons Attribution-ShareAlike 3.0 License


This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license,
visit http://creativecommons.org/licenses/by-sa/3.0/legalcode; or, (b) send a letter to Creative Commons, 171 2nd
Street, Suite 300, San Francisco, California, 94105, USA.

SAMM The Software Assurance Maturity Model (SAMM) was created by Pravir Chandra and is now an Open Web Application
Security Project (OWASP) project.
SAMM is licensed under the Creative Commons Attribution-Share Alike 3.0 License
http://www.opensamm.org
Instruc
Interview an individual based on the questions below organized according to SAMM Business Functions and Se
Place a "Yes" or "No" next to each question or assertion based on the individual's response.
Document additional information such as how and why in the "Interview Notes" column.
In order to mark "Yes" on a question, each assertion below that question must also be satisfied.
Once the interview is complete, go to the "Scorecard" sheet and follow instructions.

Organization:
Project:
Interview Date:
Interviewer:
Persons Interviewed:

Gover
Strategy & Metrics
Is there a software security assurance program in place?
Guidance:
Guidance:
Guidance:

Are development staff aware of future plans for the assurance program?
Guidance:
Guidance:
SM1
Guidance:

Do the business stakeholders understand your organization’s risk profile?


Guidance:
Guidance:
Guidance:
Guidance:

Are many of your applications and resources categorized by risk?


Guidance:
Guidance:
Guidance:
Guidance:
SM2
Are risk ratings used to tailor the required assurance activities?
Guidance:

Does the organization know about what’s required based on risk ratings?
Guidance:

Is per-project data for the cost of assurance activities collected?


Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
SM3 Guidance:
SM3

Does your organization regularly compare your security spend with that of other organization
Guidance:
Guidance:
Guidance:

Policy & Compliance


Do project stakeholders know their project’s compliance status?
Guidance:

Are compliance requirements specifically considered by project teams?


Guidance:
PC1
Guidance:
Guidance:
Guidance:
Guidance:

Does the organization utilize a set of policies and standards to control software development?
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
PC2
Are project teams able to request an audit for compliance with policies and standards?
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:

Are projects periodically audited to ensure a baseline of compliance with policies and standar
Guidance:
Guidance:
Guidance:
PC3
Does the organization systematically use audits to collect and control compliance evidence?
Guidance:
Guidance:
Guidance:

Education & Guidance


Have developers been given high-level security awareness training?
Guidance:
Guidance:
Guidance:
EG1
Does each project team understand where to find secure development best-practices and gui
Guidance:
Guidance:
Guidance:
Are those involved in the development process given role-specific security training and guida
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
EG2
Are stakeholders able to pull in security coaches for use on projects?
Guidance:
Guidance:
Guidance:

Is security-related guidance centrally controlled and consistently distributed throughout the o


Guidance:
Guidance:
Guidance:
Guidance:
EG3
Are developers tested to ensure a baseline skill-set for secure development practices?
Guidance:
Guidance:
Guidance:
Guidance:

Constr
Threat Assessment
Do projects in your organization consider and document likely threats?
Guidance:
Guidance:
Guidance:
Guidance:
TA1
Does your organization understand and document the types of attackers it faces?
Guidance:
Guidance:
Guidance:

Do project teams regularly analyze functional requirements for likely abuses?


Guidance:
Guidance:

Do project teams use a method of rating threats for relative comparison?


TA2 Guidance:
Guidance:

Are stakeholders aware of relevant threats and ratings?


Guidance:

Do project teams specifically consider risk from external software?


Guidance:

TA3
Guidance:

Are the majority of the protection mechanisms and controls captured and mapped back to thr
TA3
Guidance:
Guidance:
Guidance:
Guidance:

Security Requirements
Do project teams specify security requirements during development?
Guidance:
Guidance:
Guidance:
Guidance:
SR1
Do project teams pull requirements from best practices and compliance guidance?
Guidance:
Guidance:
Guidance:

Do stakeholders review access control matrices for relevant projects?


Guidance:
Guidance:
Guidance:
Guidance:
SR2
Guidance:

Do project teams specify requirements based on feedback from other security activities?
Guidance:

Do stakeholders review vendor agreements for security requirements?


Guidance:

Are audits performed against the security requirements specified by project teams?
SR3 Guidance:
Guidance:
Guidance:
Guidance:

Secure Architecture
Are project teams provided with a list of recommended third-party components?
Guidance:
Guidance:
Guidance:
SA1
Are project teams aware of secure design principles and do they apply them consistently?
Guidance:
Guidance:

Do you advertise shared security services with guidance for project teams?
Guidance:

SA2
Guidance:
Guidance:
Guidance:
Guidance:
SA2
Are project teams provided with prescriptive design patterns based on their application archit
Guidance:
Guidance:
Guidance:

Do project teams build software from centrally-controlled platforms and frameworks?


Guidance:
Guidance:
SA3
Are project teams audited for the use of secure architecture components?
Guidance:
Guidance:

Verific
Design Review
Do project teams document the attack perimeter of software designs?
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
DR1
Do project teams check software designs against known security risks?
Guidance:
Guidance:
Guidance:
Guidance:

Do project teams specifically analyze design elements for security mechanisms?


Guidance:
Guidance:
Guidance:
DR2
Are project stakeholders aware of how to obtain a formal secure design review?
Guidance:
Guidance:
Guidance:

Does the secure design review process incorporate detailed data-level analysis?
Guidance:
Guidance:
Guidance:

DR3 Does a minimum security baseline exist for secure design review results?
Guidance:
DR3

Guidance:
Guidance:
Guidance:

Implementation Review
Do project teams have review checklists based on common security related problems?
Guidance:
Guidance:

IR1 Do project teams review selected high-risk code?


Guidance:
Guidance:
Guidance:

Can project teams access automated code analysis tools to find security problems?
Guidance:
Guidance:
IR2
Do stakeholders consistently review results from code reviews?
Guidance:
Guidance:

Do project teams utilize automation to check code against application-specific coding standa
Guidance:

IR3 Does a minimum security baseline exist for code review results?
Guidance:
Guidance:

Security Testing
Do projects specify security testing based on defined security requirements?
Guidance:
Guidance:
Guidance:

Is penetration testing performed on high risk projects prior to release?


Guidance:
ST1 Guidance:
Guidance:

Are stakeholders aware of the security test status prior to release?


Guidance:
Guidance:
Guidance:

Do projects use automation to evaluate security test cases?


Guidance:
Guidance:
ST2
Do projects follow a consistent process to evaluate and report on security tests to stakeholde
Guidance:
ST2

Guidance:

Are security test cases comprehensively generated for application-specific logic?


Guidance:

ST3 Does a minimum security baseline exist for security testing?


Guidance:
Guidance:

Opera
Issue Management
Do projects have a point of contact for security issues or incidents?
Guidance:
Guidance:

Does your organization have an assigned security response team?


IM1 Guidance:
Guidance:

Are project teams aware of their security point(s) of contact and response team(s)?
Guidance:

Does the organization utilize a consistent process for incident reporting and handling?
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
IM2 Guidance:
Guidance:
Guidance:

Are project stakeholders aware of relevant security disclosures related to their software proje
Guidance:

Are incidents inspected for root causes to generate further recommendations?


Guidance:
Guidance:
Guidance:
Guidance:
IM3
Do projects consistently collect and report data and metrics related to incidents?
Guidance:
Guidance:
Guidance:

Environment Hardening
Do projects document operational environment security requirements?
Guidance:
Guidance:
Guidance:
EH1
Guidance:
EH1
Do projects check for security updates to third-party software components?
Guidance:
Guidance:

Is a consistent process used to apply upgrades and patches to critical dependencies?


Guidance:
Guidance:
Guidance:

Do projects leverage automation to check application and environment health?


EH2
Guidance:
Guidance:
Guidance:
Guidance:
Guidance:

Are stakeholders aware of options for additional tools to protect software while running in op
Guidance:
Guidance:

Does a minimum security baseline exist for environment health (versioning, patching, etc)?
EH3
Guidance:
Guidance:
Guidance:
Guidance:

Operational Enablement
Are security notes delivered with each software release?
Guidance:
Guidance:
Guidance:
Guidance:
OE1
Are security-related alerts and error conditions documented on a per-project basis?
Guidance:
Guidance:
Guidance:
Guidance:

Do projects utilize a change management process that’s well understood?


Guidance:
Guidance:
Guidance:
Guidance:
Guidance:
OE2
Do project teams deliver an operational security guide with each product release?
Guidance:
Guidance:
OE2

Guidance:
Guidance:
Guidance:

Are project releases audited for appropriate operational security information?


Guidance:
Guidance:

OE3 Is code signing routinely performed on software components using a consistent process?
Guidance:
Guidance:
Guidance:
Guidance:
Instructions
individual based on the questions below organized according to SAMM Business Functions and Security Practices.
" or "No" next to each question or assertion based on the individual's response.
dditional information such as how and why in the "Interview Notes" column.
ark "Yes" on a question, each assertion below that question must also be satisfied.
erview is complete, go to the "Scorecard" sheet and follow instructions.

Governance
Strategy & Metrics
there a software security assurance program in place?
Assurance program is documented and accessible to staff.
Assurance program has been used in recent development efforts.
Staff receives training against assurance program and responsibilities.

re development staff aware of future plans for the assurance program?


Assurance program goals are documented and accessible to staff.
Assurance program goals have been presented to staff.
A plan has been put in place to reach those goals in a specific period of time.

o the business stakeholders understand your organization’s risk profile?


Organization has documented motivation behind creating a software security assurance program.
Assurance program has been customized to align with the organization's motivation and goals.
Worst-case scenarios for organization's application and data assets have been collected and documented.
Scenarios, contributing factors, and mitigating factors have been reviewed with business owners and other stakeholders.

re many of your applications and resources categorized by risk?


A data and application risk classification system has been documented.
An evaluation criteria has been created to apply the classification system to data and applications.
Staff receives training in how to apply evaluation criteria to application and data assets.
Most applications and data have been categorized using this evaluation criteria.

re risk ratings used to tailor the required assurance activities?


The assurance program is customized based on data and application risk classification.

oes the organization know about what’s required based on risk ratings?
Staff receives training according to documented assurance program and risk classifications.

per-project data for the cost of assurance activities collected?


Statistics are collect for spending related to security incidents or breaches.
Baseline security costs are estimated based on each project based on it's assigned security assurance road map and risk
Actual security spending is tracked for each project.
Actual spending vs. estimated spending is evaluated on a quarterly basis.
Spending statistics and historical data are used to make case-by-case decisions on security expenditures.
Security spending decisions are made on a per project basis with consideration for expense versus loss potential.
oes your organization regularly compare your security spend with that of other organizations?
Statistics regarding similar organization's security spending is collected regularly.
Compare potential cost savings by purchasing products or switching vendors for security tools.
Security cost-comparison exercises are conducted at least annually.

Policy & Compliance


o project stakeholders know their project’s compliance status?
Project stakeholders review project's compliance status biannually.

re compliance requirements specifically considered by project teams?


External, third-party regulatory or compliance requirements have been identified.
A consolidated
Control list oforregulatory
statements responsesand compliance
have requirements
been created has been
for each security mapped toindicating
requirement security requirements.
how the organization will mee
requirement.
Security requirements are added to each project based on applicable regulatory and compliance standards.
The organization researches and updates regulatory or compliance requirements biannually.

oes the organization utilize a set of policies and standards to control software development?
A set of security policies has been created based on compliance drivers.
Optional or recommended compliance items have been added to security policies.
Requirements based on known business drivers for security have been added to security policies.
Common or similar policies have been grouped, generalized, and rewritten to satisfy compliance and security requirements
Security policies do not include requirements that are too costly or difficult for project teams to comply.
Awareness programs have been created to advertise and spread awareness of security policies.

re project teams able to request an audit for compliance with policies and standards?
A process has been created for project teams to request an audit against security policies and compliance requirements.
Internal audits are prioritized based on business risk indicators.
Each project undergoes an audit at least biannually.
Awareness programs have been created to advertise and spread awareness of the organization's audit process.
Audit results are reviewed by project stakeholders including per requirement pass/fail status, impact, and remediation.

re projects periodically audited to ensure a baseline of compliance with policies and standards?
Compliance and security gates are established throughout the development process.
An exception approval process has been created for legacy or other specialized projects.
Automated tools (code review, penetration testing, etc) are used to assist in identifying non-compliance prior to the audit pr

oes the organization systematically use audits to collect and control compliance evidence?
An automated system is used to capture, organize, and display audit data and documentation.
Access to audit data is controlled based on a need to know
Instructions and procedures for accessing audit data are published and advertised to project groups.

Education & Guidance


ave developers been given high-level security awareness training?
Application security awareness training is provided to all developers.
Training covers topics such as common vulnerabilities and best practice recommendations for eliminating vulnerabilities.
Training is conducted at least annually as well as on demand based on need.

oes each project team understand where to find secure development best-practices and guidance?
Resources regarding secure development practices have been assembled and made available to developers.
Management informs development groups that they are expected to utilize secure development resources.
A checklist based on the secure development resources has been created to ensure guidelines are met during developme
re those involved in the development process given role-specific security training and guidance?
Role specific
Managers andapplication security
requirements training
specifiers is given
receive to developers,
training in securityarchitects, QA, planning,
requirements etc. vulnerability and incident manage
threat modeling, and misuse/abuse case design.
Testers and auditors receive training in code review, architecture and design analysis, runtime analysis, and effective secu
planning.
Developer training includes security design patterns, tool-specific training, threat modeling and software assessment techn
Role specific training is provided at least annually as well as on demand based on need.

re stakeholders able to pull in security coaches for use on projects?


Internal or external security experts are available to project teams for consultation.
The process for requesting these experts is advertised to project teams.
A set security analysts or security-savvy developers have been selected as security coaches.

security-related guidance centrally controlled and consistently distributed throughout the organization?
A centralized repository has been created to organize secure development information, resources, and processes.
An approval board and change control management process is in place to control modification of information in this reposit
A method for collaboration and communication of secure development topics has been provided.
Content is searchable based on common factors like platform, language, library, life-cycle stage, etc.

re developers tested to ensure a baseline skill-set for secure development practices?


Exams are used to verify retention of security knowledge in a per training module or per role context.
Exams are given to staff at least biannually.
Staff are organized or ranked based on exam scores.
Some security activities or gates require staff of a certain rank to sign off before the item is marked as complete.

Construction
Threat Assessment
o projects in your organization consider and document likely threats?
Likely
Attack worst-case scenarios
trees or a threat are
model is documented for each
created for each project
project based
tracing on its businessnecessary
the preconditions risk profile.
for a worst-case scenario to b
realized.
Attack trees or threat models are expanded to include potential security failures in current and historical functional requirem
When new features are added to a project, attack trees or threat models are updated.

oes your organization understand and document the types of attackers it faces?
Potential external threat agents and their motivations are documented for each project.
Potential internal threat agents, their associated roles, and damage potential are documented for each project or architectu
A common set of threat agents, motivations, and other information is collected at the organization level and re-used within

o project teams regularly analyze functional requirements for likely abuses?


Each project derives abuse-cases from its use-cases.
As project requirements or features are added, abuse-cases are updated.

o project teams use a method


A documented of rating
weighting threats
system basedforon
relative comparison?
documented threat agents, exploit value, technical difficulty, and other factors is
rank threats.
Remediation of vulnerabilities is prioritized based on the weighting system.

re stakeholders aware of relevant threats and ratings?


Potential threats and ratings are reviewed with project stakeholders.

o project teams specifically consider risk from external software?


Third-party, external libraries and code used in each project are clearly identified and documented for each project.
Project threat models are updated based on identified threat agents and motivations for third party libraries and code.

re the majority
An of the protection
assessment mechanisms
for each project hasand controls
been captured
conducted andmitigating
to identify mapped controls
back to that
threats?
prevent preconditions identified in a
trees or threat models.
This assessment is updated each time new features or requirements are introduced or the attack tree is modified.
have
Mitigating controls or been requirements
security documented within the attack
have been addedtree or threat
to each model.
project to address any preconditions that still lead to
successful attack within attack trees.

Security Requirements
o project teams specify security requirements during development?
Security requirements are derived from functional requirements and customer/organization concerns.
A security auditor leads specification of security requirements within each project.
Security requirements are specific, measurable, and reasonable.
Security requirements are documented for each project.

o project teams pull requirements from best practices and compliance guidance?
Industry best practices are used to derive additional security requirements.
Existing
Plans to code bases
refactor are analyzed
existing by a security
code to implement auditor
security for opportunities
requirements to add security
are prioritized requirements.
by project stakeholders including risk
management, senior developers, and architects.

o stakeholders review access control matrices for relevant projects?


Users, roles, and privileges are identified in each project.
Resources and capabilities are identified in each project.
A matrix of roles and capabilities is documented for each project.
As new features are introduced, the matrix documentation is updated.
The matrix is reviewed with project stakeholders prior to release.

o project teams specify


Additional requirements
security based
requirements oncreated
are feedback from
based onother security
feedback activities?
from code reviews, penetration tests, risk assessments, o
security activities.

o stakeholders review vendor agreements for security requirements?


During the creation of third-party agreements, specific security requirements, activities, and processes are considered for i

re audits performed against the security requirements specified by project teams?


Audits are routinely performed to ensure security requirements have been specified for all functional requirements.
Audits also verify attack trees are constructed and mitigating controls are annotated.
A list of unfulfilled security requirements and their projected implementation date is documented.
Security requirement audits is performed on every development iteration prior to the implementation of code.

Secure Architecture
re project teams provided with a list of recommended third-party components?
A weighted
The librarieslist
areofinformally
commonlyevaluated
used third-party libraries
for security basedandoncode
pastisincidents,
collectedresponses
and documented across
to identified the organization.
issues, complexity, and
appropriateness to the organization. Risk associated with these components are documented.
A list of approved third-party libraries for use within development projects is published.

re project teams aware of secure design principles and do they apply them consistently?
A list of secure design principles (such as defense in depth) have been collected and documented.
These principles are used as a checklist during the design phase of each project.

A list of reusable resources is collected and categorized based on the security mechanisms they fulfill (LDAP server, single
o you advertise shared
server, etc.).security services with guidance for project teams?
The organization has selected a set of reusable resources to standardize on.
These resources have been thoroughly audited for security issues.
Design guidance has been created for secure integration of each component within a project.
Project groups receive training regarding the proper use and integration of these components.

re project teams provided with prescriptive design patterns based on their application architecture?
Each
A project
set of is categorized
design based on architecture
patterns is documented (client-server,
for each architecture web application,
(Risk-based thick client,
authentication etc.).
system, single sign-on, centralized
logging, etc.).
Architects, senior developers, or other project stakeholders identify applicable and appropriate patterns for each project du
design phase.

o project teams build code


Reusable software from centrally-controlled
components platforms
based on established and frameworks?
design patterns and shared security services have been created for use
projects across the organization.
Reusable code components are regularly maintained, updated, and assessed for risk.

re project teams
Auditsaudited
includefor the use of
evaluation of usage
secureofarchitecture
recommended components?
frameworks, design patterns, shared security services, and reference
platforms.
Results are used to determine if additional frameworks, resources, or guidance need to be specified as well as the quality o
guidance provided to project teams.

Verification
Design Review
o project teams document the attack perimeter of software designs?
project group
Each component in creates a simplified
the diagram one-page
is analyzed architecture
in terms diagram
of accessibility representing
of the high-level
interface from modules.
authorized users, anonymous use
operators, application-specific roles, etc.
Interfaces and components with similar accessibility profiles are grouped and documented as the software attack surface.
One-page architecture diagram is annotated with security-related functionality.
Grouped interface designs are evaluated to determine whether security-related functionality is applied consistently.
Architecture diagrams and attack surface analysis is updated when an application's design is altered.

o project teams check software designs against known security risks?


Each project group documents a list of assumptions the software relies on for safe execution.
project group
Each project's documents
one-page a list ofdiagram
architecture securityisrequirements
evaluated forfor the application.
security requirements and assumptions. Missing items are
documented as findings.
Evaluations are repeated when security requirements are added or the high-level system design changes occur within a pr

o project teams
Eachspecifically analyze
interface within design elements
the high-level for security
architecture mechanisms?
diagram is formally inspected for security mechanisms (includes internal an
external application
Analysis includes thetiers).
following minimum categories: authentication, authorization, input validation, output encoding, error h
logging, cryptography, and session management.
Each software release is required to undergo a design review.

re project stakeholders aware of how to obtain a formal secure design review?


A process for requesting a formal design review is created and advertised to project stakeholders.
The design
Design review
reviews process
include is centralized
verification and requests
of software's attack are prioritized
surface, based
security on the organization's
requirements, and securitybusiness risk profile.
mechanisms within mo
interfaces.

oes the secure design review process incorporate detailed data-level analysis?
identify details
Project teams document on system
relevant behavior
software around
modules, data high-risk
sources, functionality (such as CRUD
actors, and messages of sensitive
that flow betweendata).
data sources o
businessthe
Utilizing functions.
data flow diagram, project teams identify software modules that handle data or functionality with differing sens
levels.

oes a minimum security baseline exist for secure design review results?
A consistent design review program has been established.
A criteria gates
Release is created to determine
are used within thewhether a project
development passes
process to the design
ensure reviewcannot
projects process (for example
advance no high-risk
to the next findings).
step until the projec
succesfully
A process iscompletes a design
established review.
for handling design review results in legacy projects, including a requirement to establish a time fr
successfully completing the design review process.

Implementation Review
o project teams have review checklists based on common security related problems?
The organization has derived a light-weight code review checklist based on previously identified security requirements.
Developers receive training regarding their role and the goals of the checklist.

o project teams review selected high-risk code?


High-risk software components are prioritized above other code during the review process.
Security auditors or code review tools are utilized to perform the checklist based code review.
Remediation of findings in high-risk components are prioritized appropriately.

an project teams access automated


The organization code open
has reviewed analysis tools
source, to find security
commercial, problems?
and other solution for performing automated code reviews and s
solution that will best fit the organization.
Automated code analysis has been integrated within the development process (at code check-in for example).

o stakeholders consistently review results from code reviews?


Project stakeholders review and accept any risks that they choose not to address.
Project stakeholders have created a plan for addressing findings in legacy code.

o project teams utilize automation


Automated code review to check
tools code against
are customized application-specific
to perform additional APIcoding
checks,standards?
verify organization coding standards, etc. (i
the addition of custom rules).

oes a minimum
Eachsecurity baselineaexist
project contains for code
checkpoint review
in the results? process that requires a specific level of code review results to be m
development
before
The release. has established an exception process for legacy code, which requires a certain level of assurance to be m
organization
within a specific time period

Security Testing
o projects specify security testing based on defined security requirements?
The organization has documented general test cases based on security requirements and common vulnerabilities.
Each ensures
Staff project has
testdocumented test casesfeasible,
cases are applicable, for security
and requirements specific
can be executed to that project.
by relevant development, security, and quality assu
staff.

penetration testing performed on high risk projects prior to release?


Project teams engage security auditors to perform penetration testing.
Penetration testing covers security requirements and test cases at a minimum.
Penetration testing issues are resolved to an acceptable level of risk prior to release.

re stakeholders aware of the security test status prior to release?


Penetration testing issues are reviewed with project stakeholders.
Project stakeholders select issues to remediate prior to release.
Project stakeholders set a time line for addressing identified issues or accept outstanding risks.

o projects use
Theautomation
organization tohas
evaluate
reviewedsecurity test cases?
open source, commercial, and other solution for performing automated security testing and
a solution that will best fit the organization.
Automated security testing has been integrated within the development process.

o projects follow a consistent process to evaluate and report on security tests to stakeholders?
Automated security testing occurs across projects on a regular, scheduled basis.
A process has been created for reviewing security testing results with project stakeholders and remediating risk.

re security test cases


Using comprehensively
automated generated
tools, unit tests, or otherfor application-specific
similar logic?
methods, a comprehensive set of security test cases is constructed and
evaluated for each project.

oes a minimum
Eachsecurity baselineaexist
project contains for security
checkpoint in the testing?
development process that requires a specific level of security testing results to be
before release.
The organization has established an exception process for handling security testing results in legacy projects, which requir
certain level of assurance to be met within a specific time period

Operations
Issue Management
o projects have a point of contact for security issues or incidents?
Each project or development group has assigned a security-savvy developer to be the point of contact for security issues.
The organization maintains a centralized list of applications, projects, and points of contact regarding security issues.

oes your organization have an


The organization hasassigned
defined asecurity response
centralized securityteam?
response team responsible for managing incidents, vulnerability report
remediation, and reporting.
During an incident, the security response team provides briefings and upward communication.

re project teams aware of their security point(s) of contact and response team(s)?
The security response team meets with project groups at least annually to brief individuals on the incident response proces

oes the organization utilize ahas


The organization consistent process
a documented for incident
process reporting
for incident handlingandand
handling?
reporting, including team members' roles and
responsibilities.
The incident response process includes items such as triage to prevent additional damage, change management and patc
The incidentmanaging
application, response project
team receives training
personnel at leastinvolved
and others annually.
in the incident, forensic evidence collection and preservation,
communication about the incident to stakeholders, well-defined reporting to stakeholders and/or communications trees, etc
The organization has adopted and documented a security issue disclosure process.
The organization has adopted and documented a patch release process.
The organization has adopted and documented a process for collaborating with individuals exercising responsible disclosu
advertises
The organization has adopteda process for handling
and documented issues disclosed
a practice responsibly
for disclosing incidentsbytothird-parties.
the public (if necessary and in complia
state and federal laws).

re project stakeholders aware of relevant security disclosures related to their software projects?
A formal, documented process has been established for tracking, handling, and communicating incidents internally.

re incidents inspected for root causes to generate further recommendations?


Incident response teams investigate root causes of security failures leading to an incident or security issue.
The root cause is used to analyze
compared the project
to security or software
requirements and for additional
existing potential
processes failures. how to improve security assuran
to determine
efforts.
The root cause is reviewed with project stakeholders and management to determine a mitigation process and time frame.

o projects consistently
Metrics suchcollect and report
as frequency data and
of software metrics
projects related
affected by to incidents?
incidents, system downtime and cost from loss of use, human re
The organization's
taken centralized
in handling and cleanup incident response
of the incident, processofislong-term
estimates expandedcosts
to collect
such and record metrics.
as regulatory fines or brand damage, etc.
collected.
Past security incidents are recorded and reviewed every six months and recommendations to improve the organization or s
assurance process are made.

Environment Hardening
o projects document operational environment security requirements?
The organization documents and maintains a set of baseline operating platforms.
project teams expand on existing, approved baseline operating platforms to meet project requirements.
Project teams document assumptions made about operating environments during development.
Organization and project operating platforms are reviewed at least every six months.

o projects check for security updates to third-party software components?


Project teams or the operations team regularly monitors software components for security updates.
Project teams or the operations team apply critical software component updates once identified.

a consistent process used to apply upgrades and patches to critical dependencies?


A documented ongoing process has been created at the organization level to consistently identify and apply security patch
The patch management process requires security patches to be applied within a specific time window based on risk.
Project teams share a list of third-party components and a source for updates with the operations team.

o projects leverage automation


The organization hasto check application
reviewed open source, and environment
commercial, and health?
other solution for performing automated monitoring and patc
management and has selected a solution that will best fit the organization.
Automated monitoring and patch management tools and processes has been integrated within the organization's operation
environments.
Project
The teams and
automated the operations
monitoring team
and patch document and
management implement
tools generateapplication-level heath checks.
alerts and a documented process for handling and respo
these alerts
Project teamshas been
and the established.
operations team reviews configuration changes and alerts at least quarterly in order to improve curre
processes.

re stakeholders aware of options for additional tools to protect software while running in operations?
The security team or operations team reviews optional tools for protecting software with project stakeholders.
Appropriate solutions such as a WAF, IPS, HIDS, etc. are adopted for each project's operational environment.

oes a minimum security baseline exist for environment health (versioning, patching, etc)?
Project-level audits include analysis and testing of the operational environment in which the software resides.
Audits include verification of compliance with the organization's patch management process.
Operational
The environment
organization audits occur
has established at least every
an exception six months.
process for legacy operational environments, which requires a certain level
assurance to be met within a specific time period.

Operational Enablement
re security notes delivered
Project with each
teams document software release?
security-relevant configuration and operations information and provide documentation to users an
operators.
Project teams document a list of security features built into the software, options for configuration, security impacts, and inc
secure default.
Project stakeholders review security documentation prior to release.
Project teams update security documentation at least every six months.

re security-related
Project alerts
teamsand error conditions
document documented on
important security-related a per-project
alerts basis? and provide the documentation to the operat
and error conditions
team.
Project teams update alerts and error conditions documentation at least every six months.
Project teams document an automated or manual process for monitoring and responding to application alerts and errors.
Operations team regularly monitors and responds to application alerts and errors based on provided documentation.

o projects utilize a change management process that’s well understood?


The organization has documented and implemented a change management process.
The development process includes steps intended to collect installation or upgrade related information.
Project teams document first-time installation and upgrade instructions.
Project teams review installation and upgrade instructions for completeness and accuracy prior to release.
Project teams communicate Installation and upgrade instructions to the operations team during for release cycle.

o project teams deliver an operational security guide with each product release?
Project teams develop an operational security guide starting with information documented about security-related alerts and
Guides include all security information needed by users and operators.
Guides include items such as: security-related configuration options, event handling procedures, installation and upgrade g
operational environment specifications, security-related assumptions about the deployment environment, etc.
Project teams work with project stakeholders to determine an appropriate level of detail for the operational security guide.
Project teams update the operational security guide with each release.

re project releases audited


The audit forincludes
process appropriate operational
verification security
that projects' information?
operational security guides are complete, contain sufficient details, an
to-date.
The organization has established an exception process for legacy projects, which requires a certain level of assurance with
software's operational environment to be met within a specific time period.

code signing routinely performed on software components using a consistent process?


Code signing is used to ensure and verify the authenticity of developed code.
A code signing and key management process has been documented for the organization.
Project teams work with security auditors to determine which components warrant including within the code signing proces
List of included code components is reviewed and updated regularly.
Yes/No Interview Notes Rating
Yes

1+
Yes

Yes

No

No

No

Yes
No

Yes/No Interview Notes Rating


Yes

0+

Yes/No Interview Notes Rating

0+
Yes

Yes/No Interview Notes Rating

0
Yes/No Interview Notes Rating
Yes

0+

No

Yes/No Interview Notes Rating

0
Yes/No Interview Notes Rating

0
Yes/No Interview Notes Rating

Yes/No Interview Notes Rating

0+
Yes
Yes/No Interview Notes Rating

Yes/No Interview Notes Rating

0+
0+

Yes

Yes/No Interview Notes Rating

0+

Yes

No
SAMM Assessment Scorecard: For

Instructions
Fill out the following scorecard based on the "Yes" or "No" responses marked during the interview
If "Yes" has been marked for a question, a whole number maturity level has been achieved (for example "1" or "2" rather th
If a question has been marked "No", but assertions below that question have been marked "Yes" AND the question for the
maturity level has been marked "Yes", a "1+", "2+", or "3+" can be recorded

Organization:
Project:
Interview Date:
Interviewer:
Persons Interviewed:
Business
Functions Security Practices Current 1 2 3

Governance Strategy & Metrics 1+

Governance Policy & Compliance 0+

Governance Education & Guidance 0+

Construction Threat Assessment 0

Construction Security Requirements 0+

Construction Secure Architecture 0

Verification Design Analysis 0

Verification Implementation Review 0

Verification Security Testing 0+

Operations Issue Management 0

Operations Environment Hardening 0+

Operations Operational Enablement 0+


For

nterview
ed (for example "1" or "2" rather than "1+"
d "Yes" AND the question for the previous
Software Assurance Maturity Model (SAMM) Roadmap

Security Practice Phase


Q1 Q2 Q3 Q4

Strategy & metrics


0
1 2 3 4 5 6 7 8 9

1
Policy & Compliance
0
1 2 3 4 5 6 7 8 9

1
Education & Guidance
0
1 2 3 4 5 6 7 8 9

1
Threat Assessment
0
1 2 3 4 5 6 7 8 9

1
Security Requirements
0
1 2 3 4 5 6 7 8 9

1
Secure Architecture
0
1 2 3 4 5 6 7 8 9

1
Design Analysis
0
1 2 3 4 5 6 7 8 9

1
Implementation Review
0
1 2 3 4 5 6 7 8 9

1
Security Testing
0
1 2 3 4 5 6 7 8 9

1
Issue Management
0
1 2 3 4 5 6 7 8 9

1
Environment Hardening
0
1 2 3 4 5 6 7 8 9

1
Operational Enablement
0
1 2 3 4 5 6 7 8 9
Software Assurance Maturity Model (SAMM) Roadmap Chart Template Notes
1 The chart template assumes four stages.

2 To update the charts, enter your own target levels for each of the security practices over the four phases. Take care, there are partially obscured cells
(white text) to the right of the phases in the data table - these are necessary for the correct formatting of the charts. They contain a formula that simply
duplicates the maturity level in the cell to their left.

3 Valid values for maturity levels are The values should be 0, 1, 2 or 3 only.

4 The charts are constructed using multiple Excel area charts, each with a single line of data - one for each security practice. The charts use background
pictures to provide the striping effect, and there is an empty chart with the grey striping in the background of all of these. Unfortunately it was also
necessary to add two white rectangle objects to mask the right and bottom borders of the latter empty chart.

5 The print area is set on the chart page only to include the charts, not the source data.

6 If you need fewer or more than four phases, you'll need to spend some time adding columns, altering charts and creating new background images (see
separate worksheet).

7 Most cells are locked and have protection turned on (without a password) - use Tools | Protection | Unprotect Sheet to turn off

8 See also the SAMM Interview template v1.0


http://nickcoblentz.blogspot.com/2009/06/samm-inteview-template-version-10.html
Software Assurance Maturity Model (SAMM) Roadmap Chart Tem
Answer Rating Scale
Yes 3 3 3 6
No 2.01 2.99 2+ 5
2 2 2 4
1.01 1.99 1+ 3
1 1 1 2
0.01 0.99 0+ 1
0 0 0 0

Potrebbero piacerti anche