Documente Academic
Documente Profesional
Documente Cultură
This document is provided “as-is.” Information and views expressed in this document, including URL and other
Internet Web site references, may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection
is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You
may copy and use this document for your internal, reference purposes.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Table of Contents
Executive Summary...........................................................................................................................2
Introduction.......................................................................................................................................2
Definitions..................................................................................................................................................................................... 2
Further Reading.................................................................................................................................2
References..........................................................................................................................................2
Two primary scenarios where software security intersects with the PCI DSS and PA-DSS requirements are
addressed in this paper—the development of new payment card software and the integration of payment
card software into existing systems. The goal of the paper is to show business decision makers, systems
integrators, and development organizations where existing PCI DSS compliance activities and SDL
practices intersect in ways that may help them realize time, resource, or process efficiencies. By using this
paper as a reference, a development organization can adopt the SDL and use the security best practices
of the SDL to assist them in achieving compliance with the PCI DSS standard. These combined activities
can verify that proactive security best practices are a foundation for new software in the payment card
industry. Additionally, this paper provides a summary of the PCI DSS standard requirements and maps
them to the supporting SDL practices.
INTRODUCTION
Development organizations or system integrators that must comply with PCI DSS regulations are often
aware of the need for a lifecycle-wide approach to secure development. However, they may find that the
time, resource, and process costs associated with PCI DSS compliance limit their ability to implement a
secure development process. This paper shows where PCI DSS compliance activities and SDL practices
may intersect in practical ways for two common software development scenarios in PCI-regulated
environments:
This paper can help business decision makers, software developers, IT consultants, and system integrators
address PCI DSS security requirements when creating software or systems while speeding adoption of the
SDL in their organizations.
NOTE: it is assumed that the reader understands when PCI DSS applies in their organization, has a basic
understanding of PCI DSS and how it applies to their business requirements, and will interpret the
contents of this paper based on their specific business requirements.
Adventure-works.com developers will develop the code for this project internally. The online sales
application being developed for payment processing setting will perform the following functions that
handle sensitive data:
Transaction processing
o Authorization
o Clearing
o Settlement
Cardholder data handling
o Cardholder name
o Cardholder address
o Primary account number (PAN)
o Expiration date
o Card verification value or code (CVV2, CVC2, CID)
Chargebacks
Billing
o Single transaction
o Reoccurring transactions
Troubleshooting transactions
o Help desk access to customer accounts
o Developer access to transactional data
Each of these functions may require storage, processing, or transmission of data that falls under the
requirements of the PCI DSS. In order to meet their business requirement for protecting the security and
privacy of customer data, Adventure Works has adopted the SDL process but needs to better understand
how the SDL practices align with PCI DSS compliance activities. In this paper, this scenario is referred to as
the New Software Build Scenario.
The changes necessary for the Northwind Traders POS software include the following:
Customized transaction processing
o In-store returns and reversals
o Chargebacks
Cardholder data handling related to
o Cardholder name
o PAN
o Expiration date
o Magnetic stripe or track data (track 1 and/or track 2 data)
Data analysis
o Purchase data analytics
o Loyalty cards
Troubleshooting transactions
o Developer access to transactional data
During the customization and integration of these changes, use of the SDL process can improve the
security of the customized code. It can also provide a framework to evaluate the software security of the
customizations themselves prior to deployment. Even when performing integration, the disciplined
security and privacy behaviors in the SDL complement the PCI DSS requirements designed to provide
safeguards to the payment card data.
The Microsoft SDL is based on three core concepts—education, continuous process improvement, and
accountability. Ongoing education and training within a software development group is critical. The
appropriate investment in knowledge transfer helps organizations react appropriately to changes in
technology and the threat landscape. Because security risk is not static, the SDL places heavy emphasis on
understanding the cause and effect of security vulnerabilities and requires regular evaluation of SDL
processes and introduction of changes in response to new technology advancements or new threats. Data
is collected to verify completion of security training, in-process metrics are used to confirm process
compliance, and post-release metrics help guide future changes. Finally, the SDL requires the archival of
all data necessary to service an application in a crisis. When this archived data is paired with detailed
security response and communication plans, an organization can provide concise and cogent guidance to
all parties affected by a security incident.
p
rocess to integrate end-to-end security best practices.
It is important to notice that the five core phases roughly correspond to the phases within the software
development lifecycle:
Requirements
Design
Implementation
Verification
Release and response
The SDL integrates effective security practices into each phase of the software development lifecycle to
improve awareness of security risk and realize time and cost-saving benefits from discovering and
eliminating security issues early in the development process.
Basic software security training should cover foundational concepts such as:
Secure design
Attack surface reduction
Defense in depth
Principle of least privilege
Secure defaults
Create a basic risk questionnaire to verify whether the product should be subject to the SDL. At a
minimum, products that meet the following criteria should follow a SDL process:
Any product that is commonly used or deployed within a business (e.g. Email or database servers)
Any product that regularly stores, processes, or communicates personally identifiable information
(PII) such as financial, medical, or sensitive customer information.
If the results of this questionnaire show that the product should apply the SDL, begin building baseline
security requirements from the content of the questionnaire.
Identify a security advisor to serve as the organization‘s first point of contact for security support and
additional resources. This advisor should be responsible for defining the overall security policy and
maintaining awareness of new threats or industry developments that may affect the security of the
products or organization. In addition, identify the team or individual that is responsible for tracking and
It is important to establish the minimum design security requirements for the application that reflect how
it will run in its planned operational environment. The security advisor, partnered with the product team
security owner, should work with all disciplines to ensure security requirements are defined and agreed on
early across the development organization. Once these requirements are established, identify and deploy
a centralized security vulnerability work item tracking system that allows assigning, sorting, filtering, and
tracking completion of security related bugs, work items, or tasks. The ability to track security work items
is a critical piece in validating completion and generating data that demonstrates the effectiveness of
establishing an SDL.
A defined process should regulate the approval of exceptions to the quality gates and bug bars
throughout the lifecycle of a project. This exception process should require approval from both product
team management and security experts who understand any potential risks associated with a security
exception and can make plans for mitigation in both incident response planning and future product
cycles.
(Security) Which portions of the project require threat models before release?
(Security) Which portions of the project require security design reviews before release?
(Security) Which portions of the project (if any) require penetration testing by an organization
that specializes in application security and is external to the project team?
o If the feature, product, or services stores sensitive authentication data (see definition), it is
high risk.
o If the feature, product, or service stores, processes, or transmits payment card data,
(including only the PAN, cardholder name, expiration code, or service code), it is medium
risk.
o If the feature, product, or services does not store, process, or transmit any cardholder
data or payment card data, it is low risk.
Secure cryptographic design is a critical piece of both Design Phase SDL practices and PCI DSS
compliance. Satisfying the minimal cryptographic design requirements established when creating product
security requirements should be a priority. The SDL cryptographic requirements at a high level are:
For additional details on this requirement, review the online SDL Process Guidance available at
http://www.microsoft.com/security/sdl/discover/design.aspx.
Use Code Access Security (CAS) correctly. When developing with managed code, use strong-
named assemblies and request minimal permission. When using strong-named assemblies, do
not use Allow Partially Trusted Caller Attribute (APTCA) unless a security review approved use of
the assembly.
Manage firewall exceptions carefully. Be
logical and consistent when making firewall Aligns with:
exceptions. Any product or component that Requirement to review firewall and router rule sets at
least every six months – PCI DSS Req. 6.1.1
requires changes to the host firewall settings
must adhere to the requirements that are Build a firewall configuration that restricts connections
outlined in the "Policy for Managing Firewall between untrusted networks and any components in the
Configurations" document, available at cardholder data environment – PCI DSS Req. 1.2
http://msdn.microsoft.com/en-
us/library/cc307394.aspx.
Verify that the application runs correctly for users without administrator privileges. This restriction
reduces the likelihood that a residual vulnerability in an application can be exploited to assume
complete control of the underlying system.
Complete threat models for all functionality identified as having known security risk or the
potential for risk during the Requirements Phase Security Risk Assessment. Threat models typically
must consider the following areas:
o All projects—all code exposed on the attack surface and all code written by or licensed
from a third party.
o New projects—all features and functionality.
o Updated versions of existing projects—new features or functionality added in the
updated version.
Verify that all threat models meet minimal quality requirements.
Threat model data and all associated documentation (functional and design specifications) should be
stored by the product team to enable review of the threat models during the Verification Phase.
In addition, review all security bugs identified against the quality gates and bug bars established in the
Requirements Practices of the project to verify that the security requirements were achieved and the
potential attack surface from exceptions is understood.
Archiving all pertinent information and data for reference during the Response Phase improves the speed
and quality of response during incident response or post-release servicing of the software. Having all of
the following items archived and available for reference and reuse equips a team with the full set of
information they need to address security incidents, project post-mortems, and planning for next-version
training and requirements:
Feature specifications
Source code, binaries, and private symbols
Threat models
Test cases
Other related product documentation
Emergency response plans
License and servicing terms for any third-party software
The official PCI PA-DSS Requirements and Security Assessment Procedures document 1 lists the types of
applications that are subject to PA-DSS requirements.
All “off-the-shelf” payment applications that can be sold and installed with little customization by
software vendors.
The following list summarizes the top-level requirements of the PA-DSS. Each top-level requirement has
sub-requirements listed in the PA-DSS document.
Do not retain full magnetic stripe, card validation, code/value, or PIN block data.
1
https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
Develop and maintain instructional documentation and training programs for customers, resellers,
and integrators.
Definitions
If you are well versed in PCI DSS language, you can skip to the Applicability of SDL to PCI DSS section.
Table 1 provides a brief review of the definitions of several key terms used within the PCI DSS and PA-
DSS.
Term Definition
At a minimum, cardholder data consists of the full PAN. Cardholder data may
also appear in the form of the full PAN plus any of the following: cardholder
Cardholder Data name, expiration date, and/or service code. See the definition of Sensitive
Authentication Data for additional data elements that may be transmitted or
processed (but not stored) as part of a payment transaction.
Compensating controls may be considered when an entity cannot meet a
requirement explicitly as stated due to legitimate technical or documented
business constraints, but has sufficiently mitigated the risk associated with the
requirement through implementation of other controls. Compensating controls
must:
Compensating
Meet the intent and rigor of the original PCI DSS requirement.
Controls
Provide a similar level of defense as the original PCI DSS requirement.
Be “above and beyond” other PCI DSS requirements (not simply in
compliance with other PCI DSS requirements).
Be commensurate with the additional risk imposed by not adhering to
the PCI DSS requirement.
Acronym for “point of sale.” Hardware and/or software used to process payment
POS
card transactions at merchant locations.
Also referred to as “track data.” Data encoded in the magnetic stripe or chip used
Magnetic Stripe for authentication and/or authorization during payment transactions. Can be the
Data (Track Data) magnetic stripe image on a chip or the data on the track 1 and/or track 2 portion
of the magnetic stripe.
For the purposes of the PCI DSS, a merchant is defined as any entity that accepts
payment cards bearing the logos of any of the five members of PCI SSC
(American Express, Discover, JCB, MasterCard, or Visa) as payment for goods
and/or services. Note that a merchant that accepts payment cards as payment
Merchant for goods and/or services can also be a service provider if the services sold result
in storing, processing, or transmitting cardholder data on behalf of other
merchants or service providers. For example, an ISP is a merchant that accepts
payment cards for monthly billing, but is also a service provider if it hosts
merchants as customers.
Acronym for “primary account number” and also referred to as “account
PAN number.” A unique payment card number (typically for credit or debit cards) that
identifies the issuer and the particular cardholder account.
The PCI DSS security requirements apply to all system components. System components are
defined as any network component, server, or application that is included in or connected to the
cardholder data environment. Applications include all purchased and custom applications,
including internal and external (Internet) applications.
PCI DSS requirements are applicable if a PAN is stored, processed, or transmitted. If a PAN is not
stored, processed, or transmitted, PCI DSS requirements do not apply.
2
Source: PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms
3
Source: The PCI Security Assessment Procedures (SAP)
Both the Adventure Works and Northwind Traders organizations must implement training programs to
support compliance with the PCI DSS requirements. Taking the time to append secure development
courseware to that curriculum verifies that their entire development organization understands the
importance of writing secure code and is equipped to start implementing SDL practices early in their
development lifecycle. Further, the training requirements of the SDL specifically target proactive developer
education in areas such as secure design, threat modeling, secure coding, security testing, and privacy.
Training requirements in PCI DSS, although crucial to implement are largely reactive in nature.2.0
Requirements Practices
Every team must determine which security and privacy requirements apply to its development or
integration project. However, the SDL practices of Establish Security Requirements, Create Quality Gate
and Bug Bars, and Perform Security and Privacy Risk Assessments can directly link to the PCI DSS and the
PA-DSS requirements.
If cardholder data is accessed, transmitted, or stored, the application development or integration project
should have a security advisor assigned and an issue-tracking system implemented. The use of the SDL
requirements practices can help drive out any potential PCI DSS or PA-DSS violations in the early phases
of the Software Development Life Cycle (SDLC), saving both compliance and development costs.
The SDL Requirements Phase practices help both Adventure Works’ New Software Build Scenario and
Northwind Traders’ Custom Software Integration Scenario. In the New Software Build Scenario, Adventure
Works needs to account for all points where any cardholder data is processed or held, consumer
transactions are performed, or back-office business transactions are completed. This PCI-required
accounting is part of what the SDL requires in a formal Security and Privacy Risk Assessment each
organization creates and should be an integral part of both establishing security requirements and
defining severity and priority in quality gates and bug bars. By establishing security requirements at the
outset of the Custom Software Integration Scenario and setting quality gates and bug bars, the Northwind
Traders team verifies that the data PCI mandates as sensitive are among the highest priorities entering the
Northwind Traders’ Security and Privacy Risk Assessment. Both scenarios should define and map their
security requirements to the software requirements for the project. Once security requirements are
established, the project team can put development controls (including quality gates and bug bars) in
place to verify that these requirements are met.
Particularly in the Custom Software Integration Scenario, the Northwind Traders team needs to maintain
rigorous control of changes to the requirements to verify that any change can be traced back to the
source. The additional layer of protection established by the security requirements and bug bars allows
the team to assess the risk associated with each potential change. The Custom Software Integration
Scenario is particularly susceptible to poor change control because custom software integration can be
implemented in a trial-and-error process. Overall, the SDL requirement practices decrease the risk of
integration injecting security errors into the systems both early and throughout a project.
The PA-DSS consists of fourteen requirements that a payment card processing application must meet to
be approved. These requirements were outlined earlier in this paper and are ideal for inclusion in the
Security and Privacy Risk Assessments of the SDL.
Both Adventure Works and Northwind Traders will set up quality gates and bug bars verifying that both
new software development and software integration are measurable against the PCI DSS and PA-DSS
requirements.
Appropriate cryptographic use and control is critical to meeting both the PCI DSS and PA-DSS
requirements. The SDL also requires that specific cryptographic standards are established well before
code is actually written. PCI DSS defines appropriate cryptographic standards in requirements 3.4, 3.5, 3.6,
and 6.5.3. Setting design requirements as part of the SDL Design Phase addresses the appropriate use,
storage, and disposal baselines. PA-DSS also calls for appropriate use, storage, and disposal of
cryptographic keys in requirements 2.5, 2.7, and requirement 5.1.1.
Adventure Works’ New Software Build Scenario teams must perform threat modeling while defining the
architecture of their application and prior to writing code. Threat modeling verifies that they have
reviewed all attack surfaces, identified potential security risks, and outlined mitigations that they can
account for in development. Threat modeling provides a critical input to the SDL Verification Phase and
gives QA/Test organizations the ability to start building test cases based on the issues identified during
threat modeling.
Requirement 6.5 of the PA-DSS goes into detail about specific flaws to look for during implementation
activities. The current version of the PA-DSS references the following common coding vulnerabilities in
software development processes (listed as PCI DSS Requirements 6.5.1-6.5.9):
Injection flaws, particularly SQL injection. Also, consider OS Command injection, LDAP and Path
injection flaws, and other injection flaws.
Buffer overflow.
Insecure communications.
All “High” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS
Requirement 6.2). Note: This requirement is considered a PCI DSS best practice until June 30,
2012, after which it becomes a requirement.
Improper access control (such as insecure direct object references, failure to restrict URL access,
and directory traversal).
Security tools are a critical piece of any development project. Equipping developers with tools that
improve their efficiency and assist them in writing more secure code is critical. The SDL practice requiring
the use of approved tools meets some of the requirements of PCI DSS 6.6 that call for the use of
automated vulnerability scanning tools where possible. In this case, the SDL provides a more extensive set
of mandates around static code analysis and preventing the use of unsafe functions or libraries in code.
Because the SDL calls for the deprecation of unsafe functions, this specific security practice surpasses both
PCI DSS and PA-DSS requirements. Use of unsafe functions in code makes software more susceptible to
security flaws. Both Adventure Works’ New Software Build Scenario and Northwind Traders’ Custom
Software Integration Scenario must be aware of known bad function calls and either provide headers that
block these calls from being inadvertently used or find other ways to document and verify that their code
does not contain such function calls. The use of static
analysis or operational review of the code is an SDL Using the banned.h header file available on the SDL
tools website is a simple way to protect developers
from using known bad function calls.
SDL and PCI 18
Implementation Phase practice that exceeds the PCI DSS requirements of 3.2.2 and 6.3.2 and meets the
PA-DSS requirements of 1.1.1, 1.1.2, 2.1, 2.2, 2.7, 5.1.7, and 5.2. The SDL practice of static analysis helps to
meet some of the requirements of PCI and PA-DSS. Static analysis tools apply in both the New Software
Build Scenario and the Custom Software Integration Scenario to verify that neither the underlying code in
Adventure Works’ payment processing software nor Northwind Traders’ customized POS system are
susceptible to known security issues and are written using basic security coding practices.
The SDL Verification Phase incorporates security testing practices into the broader testing efforts
performed by Adventure Works in the New Software Build Scenario. By using dynamic analysis and fuzz
testing, Adventure Works may uncover potential security issues across transaction processing, cardholder
data handling, and billing scenarios that they may otherwise miss. Performing an attack surface review
that refers to attack surface analysis performed in the Design Phase will further verify that they mitigate all
issues found during design and identify any areas of new attack surface developed during the
Implementation Phase.
Northwind Traders requires significant effort in the Custom Software Integration Scenario, as they may be
unaware of the full potential attack surface associated with the acquired custom POS software. Taking
time to perform thorough attack surface reviews and exercising the code through dynamic analysis and
fuzz testing is vital prior to deploying this software because the application contains critical customer
information.
Neither the PCI DSS nor the PA-DSS address the release practice of a Final Security Review (FSR).
However, an FSR is generally consistent with the PA-DSS’s emphasis on producing evidence that software
meets security requirements for cardholder data protection. Further, the FSR is an effective way to
evaluate a project’s success compared to initial security requirements, and understand and review any
potential risks that may remain unmitigated due to business decisions. Whether a project fits the New
Software Build Scenario or the Custom Software Integration Scenario, complete an incident response plan
and Final Security Review prior to releasing the product. Finally, ensuring that there is a complete archive
of all security-related information (requirements, risk assessments, tools outputs, final security reviews,
By reading this paper, an organization writing or integrating software in a PCI-regulated environment can
readily see how the security best practices of the SDL can help it meet many of the PCI DSS and PA-DSS
requirements. Applying SDL practices to a software development process provides a methodology for
improving the security of software during development in some PCI compliance scenarios. This paper can
serve as a valuable resource in applying the SDL to software development and integrated software
modules in payment card environments.
FURTHER READING
For further reading on the SDL:
REFERENCES
1. Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment
Procedures Version 1.2.1 July 2009
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
2. Payment Card Industry (PCI) Payment Application Data Security Standard Requirement and
Security Assessment Procedures version 1.2.1 July 2009
https://www.pcisecuritystandards.org/security_standards/pci_pa_dss.shtml
3. List of Validated Payment Applications
https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php
1.1.5.b Identify insecure services, protocols, and ports Design 3.2 Analyze Attack Surface
Examples of insecure services,
allowed; and verify they are necessary and that security Design 3.3 Complete Threat Models
protocols, or ports include but are
Do not store the card verification For a sample of system components, examine data Requirements 2.1 Establish Security
code or value (three digit or four- sources, including but not limited to the following, Requirements 2.3 Requirements
3.2.2 digit number printed on the front or and verify that the three digit or four-digit card Implementation Perform Security & Privacy
back of a payment card) used to verification code or value printed on the front of the 4.3 Risk Assessment
verify card-not present transactions. card or the signature panel (CVV2, CVC2, CID, CAV2 Verification 5.0- Perform Periodic Static Code
Render PAN unreadable anywhere it 3.4.a Obtain and examine documentation about the
Satisfy Minimum
is stored (including on portable system used to protect the PAN, including the
3.4 Design 3.1.3 Cryptographic Design
digital vendor, type of system/process, and the encryption
Requirements
media, backup media, and in logs) algorithms (if applicable). Verify that the PAN is
Production data (live PANs) are not Production data (live PANs) are not used for testing
6.4.3
used for testing or development. and development.
Requirement 9: Restrict physical access to cardholder data The Microsoft SDL focuses on application
Any physical access to data or systems that house cardholder data provides the opportunity for individuals development security. Physical security is not
to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. addressed in SDL practices.
Requirement 10: Track and monitor all access to network resources and cardholder data The Microsoft SDL focuses on application
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or development security. Tracking and monitoring
Securely delete any magnetic stripe data, 1.1.4.a Review the PA-DSS Implementation Requirements 2.1 Establish Security Requirements
1.1.4
card validation values or codes, and PINs Guide prepared by the vendor and verify the Requirements 2.3 Perform Security & Privacy Risk
Payment application must implement Verify the payment application implements Satisfy Minimum Cryptographic
2.6 Design 3.1.3
key management processes and key management techniques for keys, per PCI Design Requirements
Training 1.0 Training Practices A well thought-out training program allows software development
teams to learn about security and privacy basics, specific technical
issues and stay informed about recent trends in security and privacy.
Training 1.1 Complete Core Security All members of software development teams must receive appropriate More training resources available at:
Training training to stay informed about security basics and recent trends in http://www.microsoft.com/security/sdl/
security and privacy. getstarted/training.aspx
Requirements Requirements Practices Setting a designated time for defining project requirements allows
development teams to consider how to best integrate security and
Requirements Establish Security The need to consider security and privacy “up front” is a fundamental At a minimum, products that meet the
2.1 Requirements aspect of secure system development. The optimal point to define following criteria should follow a SDL
trustworthiness requirements for a software project is during the initial process:
planning stages. This early definition of requirements allows 1. Any product that is commonly used
development teams to identify key milestones and deliverables, and or deployed within a business (e.g.
permits the integration of security and privacy in a way that minimizes Email or database servers)
any disruption to plans and schedules. 2. Any product that regularly stores,
processes, or communicates personally
Create a basic questionnaire to verify whether your product should be identifiable information (PII) such as
subject to the SDL. If you determine is should be based on the results financial, medical, or sensitive customer
of your questionnaire, begin building your baseline security information.
requirements from the content of the questionnaire. 3. Any online products or services that
target or are attractive to children.
4. Any product that regularly touches or
listens on the internet.
5. Any product that automatically
downloads updates.
Requirements Assign Security Experts Identify the security advisor who will serve as your team's first point of
2.1.1 contact for security support and additional resources. This person will
serve as the security advisor for the project.
Requirements Specify bug/work Specify and deploy a security vulnerability/work item tracking system Recommendation: Be sure to configure
2.1.3 tracking tool that will allow you to assign, sort, filter, and track completion of bug reporting tools correctly; limit
security related bugs, work items or tasks. access to bugs with security
implications to the project team and
security advisors only.
Requirements Create Quality Gates/Bug Quality gates and bug bars are used to establish minimum acceptable A sample security bug bar document is
2.2 Bars levels of security and privacy quality. Defining these criteria at the start available at
of a project improves the understanding of risks associated with http://msdn.microsoft.com/en-
security issues and enables teams to identify and fix security bugs us/library/cc307404.aspx.
during development. A project team must negotiate quality gates (for
example, all compiler warnings must be triaged and fixed prior to code
check-in) for each development phase, and then have them approved
by the security advisor, who may add project-specific clarifications and
more stringent security requirements as appropriate. The project team
must also illustrate compliance with the negotiated quality gates in
order to complete the Final Security Review (FSR).
Requirements Perform Security & Security risk assessments (SRAs) and privacy risk assessments (PRAs) A sample Privacy Questionairre to
2.3 Privacy Risk Assessment are mandatory processes that identify functional aspects of the guide your risk assessment can be
software that require deep review. Such assessments must include the found here:
following information: http://msdn.microsoft.com/en-
us/library/cc307393.aspx
• (Security) Which portions of the project will require threat models
Design 3.0 Design Practices A design practices identifies the overall requirements and structure for
the software and establishes design best practices.
Design 3.1 Establish Security Design The design requirements activity contains a number of required
Requirements actions. Examples include the creation of security and privacy design
specifications, specification review, and specification of minimal
cryptographic design requirements. Design specifications should
describe security or privacy features that will be directly exposed to
users, such as those that require user authentication to access specific
data or user consent before use of a high-risk privacy feature. In
Design 3.1.1 Perform Security Design Complete a security design review with a security advisor for any
Review project or portion of a project that requires one. Some low-risk
components might not require a detailed security design review.
Design 3.1.2 Perform Privacy Design To avoid costly mistakes, projects with a high privacy impact based on A sample Privacy Questionnaire to
Review the Privacy Risk Assessment must hold a privacy design review. guide your review can be found here:
http://msdn.microsoft.com/en-
us/library/cc307393.aspx
2. Ensure that all threat models meet minimal threat model quality
requirements. All threat models must contain data flow diagrams, assets,
vulnerabilities, and mitigation. Threat modeling can be done in a variety of ways
using either tools or documentation/specifications to define the approach.
Implementation Implementation Practices During the Implementation practice, the development team mandates and
4.0 enforces best practices to be followed for the duration of the project.
Implementation Identify/Deprecate Unsafe Project teams should analyze all functions and APIs that will be used in New native C and C++ code must not use
4.2 Functions conjunction with a software development project and prohibit those that are banned versions of string buffer handling
determined to be unsafe. Once the banned list is determined, project teams functions. Based on analysis of previous
should use header files (such as banned.h and strsafe.h), newer compilers, or Microsoft Security Response Center (MSRC)
code scanning tools to check code (including legacy code where appropriate) cases, avoiding use of banned APIs is one
for the existence of banned functions, and replace those banned functions actionable way to remove many vulnerabilities.
with safer alternatives. The "SDL Banned APIs" check-in policy
provided with this template helps you enforce
this in your project. Check the "Setup check-in
policies" task for information on how to ensure
this.
Implementation Perform periodic static code Project teams should perform static analysis of source code. Static analysis of A list of Microsoft's SDL-related
4.3 analysis source code provides a scalable capability for security code review and can Implementation tools can be found at:
help ensure that secure coding policies are being followed. Static code http://www.microsoft.com/security/sdl/getstart
analysis by itself is generally insufficient to replace a manual code review. The ed/tools.aspx.
security team and security advisors should be aware of the strengths and
weaknesses of static analysis tools and be prepared to augment static The SDL ProNetwork Tools partners can be
analysis tools with other tools or human review as appropriate. accessed at:
http://www.microsoft.com/security/sdl/getstart
ed/pronetwork.aspx
Verification 5.0 Verification Practices Verification is the point at which the software is functionally complete and is
tested against security and privacy goals outlined in the requirements and
design phase.
Verification 5.1 Perform dynamic code Run-time verification of software programs is necessary to ensure that a A list of Microsoft's SDL-related
analysis program’s functionality works as designed. This verification task should Implementation tools can be found at:
specify tools that monitor application behavior for memory corruption, user http://www.microsoft.com/security/sdl/getstart
privilege issues, and other critical security problems. The SDL process uses ed/tools.aspx.
run-time tools, along with other techniques such as fuzz testing, to achieve
desired levels of security test coverage. The SDL ProNetwork Tools partners can be
accessed at:
http://www.microsoft.com/security/sdl/getstart
ed/pronetwork.aspx
Verification 5.2 Perform fuzz testing Fuzz testing is a specialized form of dynamic analysis used to induce A list of Microsoft's SDL-related
Verification 5.3 Conduct Attack Surface It is common for an application to deviate significantly from the functional
Review and design specifications created during the requirements and design phases
of a software development project. Therefore, it is critical to re-review threat
models and attack surface measurement of a given application when it is
code complete. This review ensures that any design or implementation
changes to the system have been accounted for, and that any new attack
vectors created as a result of the changes have been reviewed and mitigated.
Release 6.0 Release Practices In preparation for releasing a product, the team must create the incident
response plan, perform the Final Security Review and archive all pertinent
data for post-release servicing of the software.
Release 6.1 Create an Incident Response Every software release subject to the requirements of the SDL must include
Plan an incident response plan. Even programs with no known vulnerabilities at
the time of release can be subject to new threats that emerge over time. The
incident response plan should include:
• An identified sustained engineering (SE) team, or if the team is too small to
have SE resources, an emergency response plan (ERP) that identifies the
appropriate engineering, marketing, communications, and management staff
Release 6.2 Perform a Final Security The Final Security Review (FSR) is a deliberate examination of all the security
Review activities performed on a software application prior to release. The FSR is
performed by the security advisor with assistance from the regular
development staff and the security and privacy team leads. The FSR is not a
“penetrate and patch” exercise, nor is it a chance to perform security
activities that were previously ignored or forgotten. The FSR usually includes
an examination of threat models, exception requests, tool output, and
performance against the previously determined quality gates or bug bars.
The FSR results in one of three different outcomes:
• Passed FSR. All security and privacy issues identified by the FSR process are
fixed or mitigated.
• Passed FSR with exceptions. All security and privacy issues identified by the
FSR process are fixed or mitigated and/or all exceptions are satisfactorily
resolved. Those issues that cannot be addressed (for example, vulnerabilities
posed by legacy “design level” issues) are logged and corrected in the next
release.
• FSR with escalation. If a team does not meet all SDL requirements and the
security advisor and the product team cannot reach an acceptable
compromise, the security advisor cannot approve the project, and the project
cannot be released. Teams must either address whatever SDL requirements
that they can prior to launch or escalate to executive management for a
decision.
Release 6.3 Archive all release data Software release to manufacturing (RTM) or release to Web (RTW) is
In addition, all pertinent information and data must be archived to allow for
post-release servicing of the software. This includes all specifications, source
code, binaries, private symbols, threat models, documentation, emergency
response plans, license and servicing terms for any third-party software and
any other data necessary to perform post-release servicing tasks.