| Security Development Lifecycle

SDL and PCI DSS/PA-DSS

Aligning the Microsoft SDL with PCI DSS/PCI PA-DSS Compliance Activity
For the latest information, please see http://www.microsoft.com/sdl.

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.

© 2010 Microsoft Corporation. All rights reserved.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

Microsoft and Windows are trademarks of the Microsoft group of companies.

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

Scenario 1: New Software Build.......................................................................................................2

Scenario 2: Custom Software Integration.......................................................................................2

Security Development Lifecycle Overview......................................................................................2

The SDL Process.......................................................................................................................................................................... 2

1.0 SDL Security Training......................................................................................................................................................... 2

1.1 Complete Core Security Training 2

2.0 Requirements Practices..................................................................................................................................................... 2

2.1 Establish Security Requirements 2

2.2 Create Quality Gates and Bug Bars 2

2.3 Perform Security Risk Assessment 2

3.0 Design Practices................................................................................................................................................................... 2

3.1 Establish Security Design Requirements 2

3.2 Analyze Attack Surface 2

3.3 Complete Threat Models 2

4.0 Implementation Practices................................................................................................................................................. 2

4.1 Use Approved Tools 2

4.2 Deprecate Unsafe Functions 2

4.3 Perform Static Analysis 2

5.0 Verification Practices.......................................................................................................................................................... 2

5.1 Perform Dynamic Code Analysis 2

5.2 Perform Fuzz Testing 2

5.3 Conduct Attack Surface Review 2

6.0 Release Practices.................................................................................................................................................................. 2

6.1 Create an Incident Response Plan 2

6.2 Perform a Final Security Review 2

6.3 Archive All Release Data 2

Applicability of the SDL to PCI DSS and PA-DSS Regulatory Requirements..............................2
The Relationship Between PCI DSS and PA-DSS............................................................................................................. 2

Definitions..................................................................................................................................................................................... 2

Scope and Applicability............................................................................................................................................................ 2

Discussion on Applicability of the SDL to PCI DSS and PA-DSS................................................................................2

1.0 Security Training.................................................................................................................................................................. 2

3.0 Design Practices................................................................................................................................................................... 2

3.1 Establish Security Design Requirements 2

3.2 Attack Surface Analysis 2

3.3 Threat Modeling 2

4.0 Implementation Practices................................................................................................................................................. 2

5.0 Verification Practices.......................................................................................................................................................... 2

6.0 Release Practices.................................................................................................................................................................. 2

Further Reading.................................................................................................................................2

References..........................................................................................................................................2

APPENDIX A: PCI DSS REQUIREMENTS MAPPED TO THE SDL PRACTICES (PULL-OUT)..........2

APPENDIX B: PA-DSS REQUIREMENTS MAPPED TO THE SDL PRACTICES (PULL-OUT)...........2

APPENDIX C: Microsoft SDL Practices (PULL-OUT).......................................................................2

EXECUTIVE SUMMARY
This paper demonstrates how the Microsoft Security Development Lifecycle (SDL) can help meet some of
the requirements of the Payment Card Industry Data Security Standard (PCI DSS) and the Payment
Application Data Security Standard (PA-DSS). It is important for the reader to realize that PCI DSS is just
one of several regulatory controls under the PCI framework. This paper reflects the PCI DSS version 2.0
that was updated in October 2010. PCI DSS is an industry-accepted standard authored and approved by
the PCI Security Standards Council (PCI SSC). The PCI DSS includes several requirements that align closely
with SDL practices. In addition, PA-DSS also mandates SDL-like controls for licensed or distributed third-
party applications.

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:

 Developing new software

 Integrating software customizations with PCI controlled systems

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.

SCENARIO 1: NEW SOFTWARE BUILD

Developing new software is probably the most common scenario for applying the Security Development
Lifecycle in a PCI DSS regulated organization. For this scenario, a fictitious company named “Adventure
Works” is used. Adventure Works represents a merchant that is creating an online sales application for an

SDL and PCI 1

e-commerce portal that supports back-end data aggregation for statistical analysis of customer
purchasing patterns. This new e-commerce portal will launch under the name Adventure-works.com.
Adventure-works.com has a number of business requirements that include customer satisfaction and
compliance with the PCI DSS industry standards. Adventure-works.com will accept payment cards, so they
must protect and handle this information properly. The company will also reference the requirements of
the PCI PA-DSS in creating their online sales application. The PA-DSS contains specific requirements for
payment applications that have access to payment card data. This paper discusses those specific
requirements in a later section.

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.

SCENARIO 2: CUSTOM SOFTWARE INTEGRATION

In this scenario, a mid-sized retail merchant uses an existing point-of-sale (POS) system in each of its retail
stores. In this example, “Northwind Traders” is the mid-sized retail merchant. A third-party reseller
originally developed the POS software installed at Northwind Traders, but Northwind Traders obtained
the rights to retain the code and implement custom changes to accommodate their business
environment. As in the New Software Build Scenario, this software is subject to the requirements and

SDL and PCI 2

specific compliance activities of the PA-DSS to verify compliance with PCI regulations. In this paper, this
scenario is referred to as the Custom Software Integration 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.

SECURITY DEVELOPMENT LIFECYCLE OVERVIEW

The Security Development Lifecycle is a security assurance process that is focused on software
development. Combining a holistic and practical approach, the SDL introduces security and privacy
throughout all phases of the development process with the goal of reducing the number and severity of
vulnerabilities in software.

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.

SDL and PCI 3

The SDL Process
Any software development organization, regardless of development methodology, can adopt the SDL

p
rocess to integrate end-to-end security best practices.

Figure 1: The SDL Process

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.

1.0 SDL Security Training

1.1 Complete Core Security Training

All members of a software development team must receive appropriate training to stay informed about
security basics and recent trends in security and privacy. The PCI DSS requires training for anyone with
access to payment card data or who could influence the security of the cardholder data environment.
However, the SDL applies this requirement to the entire organization to verify that security training is
provided for everyone. Individuals in technical roles (developers, testers, and program managers) that are
directly involved with the development of software programs must attend at least one unique security
training class each year.

Basic software security training should cover foundational concepts such as:
Secure design
 Attack surface reduction
 Defense in depth
 Principle of least privilege
 Secure defaults

SDL and PCI 4

Threat modeling
 Overview of threat modeling
 Design implications of a threat model
 Coding constraints based on a threat model
Secure coding
 Buffer overruns (for applications using C and C++)
 Integer arithmetic errors (for applications using C and C++)
 Cross-site scripting (for managed code and web applications)
 SQL injection (for managed code and web applications)
 Weak cryptography
Security testing
 Differences between security testing and functional testing
 Risk assessment
 Security testing methods
Privacy
 Types of privacy-sensitive data
 Privacy design best practices
 Risk assessment
 Privacy development best practices
 Privacy testing best practices

2.0 Requirements Practices

2.1 Establish Security Requirements

The need to consider security and privacy “up front” is a fundamental aspect of secure system
development. The initial planning stages are the optimal point to define trustworthiness requirements for
a software project. This early definition of requirements allows development teams to identify key
milestones and deliverables and permits the integration of security and privacy that minimizes disruption
to plans and schedules.

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.

 Any online products or services that target or are attractive to children.

 Any product that regularly touches or listens on the internet.

 Any product that automatically downloads updates.

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

SDL and PCI 5

managing security for the product. This team or individual is not solely responsibility for addressing
security in a software release, but this team or individual is responsible for coordinating and
communicating the status of any security issues in the product. In smaller product groups, a single person
can fill these roles.

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.

2.2 Create Quality Gates and Bug Bars

Quality gates and bug bars establish minimum
acceptable levels of security and privacy quality. Aligns with:
Unique User ID - PCI DSS Req. 8.1 and 8.5.8
Defining these criteria at the start of a project Password Management - PCI DSS Req. 8.5.1-8.5.14
improves the understanding of risks associated Risk Assessment – PCI DSS Req. 12.1.2
with security issues and enables teams to identify Assignment of Roles & Responsibilities – PCI DSS Req. 12.5
and avoid or fix security bugs during development.
Establishing clear requirements early can improve engineering efficiencies in creating and executing
quality assurance (QA) and test plans. A project team should define 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 illustrate compliance with the
negotiated quality gates in order to complete the Final Security Review (FSR) before release.

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.

2.3 Perform Security Risk Assessment

PCI DSS Requirement 12.1.2 mandates an annual
risk assessment that includes processes to identify Aligns with:
Risk Assessment – PCI DSS Req. 12.1.2
threats and vulnerabilities. Companies that perform
in-house software development must include the
threats and vulnerabilities associated with the software they develop in this annual risk assessment. These
assessments should include some form of the following information:

 (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?

SDL and PCI 6

  (Security) Are there any additional testing or analysis requirements the security advisor deems
necessary to mitigate security risks?
 (Security) What is the specific scope of the fuzz testing requirements?
 (Compliance) What impact will compliance have on the product? Use your own framework to
measure the impact of compliance. The following guidelines are provided as a beginning
framework:

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.

3.0 Design Practices

3.1 Establish Security Design Requirements

Establishing security design requirements involves a
number of specific actions. These required activities
include creating and reviewing security specifications
for high-risk features, as well as defining secure
coding techniques for developers. The results from
these activities should be documented as the
product’s security design requirements. .
Aligns with:
PA DSS 5.2 - Develop all web payment applications
(internal and external, and including web administrative
access to product) based on secure coding guidelines
such as the Open Web Application Security Project
Guide.

All design specifications should describe how to

securely implement all functionality provided by a given feature or function. It is a good practice to
validate design specifications against the application’s functional specification. The functional specification
should:

 Accurately and completely describe the intended use of a feature or function.

 Describe how to deploy the feature or function in a secure fashion.
 Describe whether the feature or function will touch payment card data.

A key to PCI compliance is tying change control

(Requirement 6.4) to data classification. This change
control provides an archived record for developers to
review application changes that impact controlled data
such as payment card data.
Aligns with:
Follow change control procedures for all changes to
systems components… – PCI DSS Req. 6.4

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:

 Use AES for symmetric encryption/decryption

 Use 128-bit or better symmetric keys
 Use RSA for asymmetric encryption/decryption and signatures
 Use 1024-bit or better RSA keys

SDL and PCI 7

  Use SHA-256 or better for hashing and message authentication codes

For additional details on this requirement, review the online SDL Process Guidance available at
http://www.microsoft.com/security/sdl/discover/design.aspx.

SDL and PCI 8

3.2 Analyze Attack Surface
Attack surface reduction is a means of reducing risk by giving attackers less opportunity (surface) to
exploit a potential vulnerability. Attack surface reduction may include shutting off or restricting access to
system services, applying the principle of least privilege, and employing layered defenses wherever
possible. At a minimum, attack surface reduction should include the following:

 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.

3.3 Complete Threat Models

Use threat modeling for features or systems that were
Aligns with:
identified as having known security risk or the Risk Assessment – PCI DSS Req. 12.1.2
potential for risk during the Requirements Phase Information Security Policy – PCI DSS Req. 12.1
Security Risk Assessment. Threat modeling is a practice
that allows development teams to consider, document, and discuss the security implications of designs in
a planned operational environment. Threat modeling also allows consideration of security issues at the
component or application level. It is a team exercise, encompassing program/project managers,
developers, and testers, and represents the primary security analysis task performed during the software
design stage. Threat modeling activities include:

 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.

SDL and PCI 9

  Confirm that all threat models contain data
flow diagrams, assets, vulnerabilities, and STRIDE is an acronym used in threat modeling to
categorize identified threats into the six most common
mitigations.
types:
 Employ threat modeling using STRIDE. To
follow STRIDE, decompose the system into Spoofing
Tampering
components, analyze each component for
Repudiation
threats, and propose mitigations for each Information Disclosure
threat. Denial of Service
 Use tools such as the Microsoft SDL Threat Elevation of Privilege

Modeling Tool, a whiteboard or hand-drawn Learn more at http://www.microsoft.com/sdl.

exercise combined with a thorough
documentation of the results, or even using
the SDL Elevation of Privilege threat modeling card game to perform threat modeling.
 Ensure that all threat models and referenced mitigations are approved by at least one security
expert, one developer, one tester, and one program manager. Ask architects, developers, testers,
program managers, and others who understand the software to contribute to threat models and
to review them. Solicit broad input and review to verify that the threat models are as
comprehensive as possible.

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.

4.0 Implementation Practices

4.1 Use Approved Tools

All development teams should define and publish a list of approved tools and their associated security
checks, such as compiler/linker options and warnings. The security advisor for the project team should
approve this list. Development teams should use the latest versions of approved tools to take advantage
of new security analysis functionality and protections.

4.2 Deprecate Unsafe Functions

Project teams should analyze all functions and APIs used in conjunction with a software development
project and prohibit those that are determined to be unsafe. Once the banned API list is determined,
project teams should use header files (such as banned.h and strsafe.h), newer compilers, or code scanning
tools to check code (including legacy code where appropriate) for the existence of banned functions, and
replace those banned functions with safer alternatives.

4.3 Perform Static Analysis

Project teams should perform static analysis of source
code. Static analysis of source code provides a tool-
based scalable capability for security code review and
can help verify the use of secure coding practices.
Aligns with:
Review of custom code prior to release to production or
customers in order to identify any potential coding
vulnerability… – PCI DSS Req. 6.3.7

Static code analysis by itself is generally insufficient to

replace a manual code review for high-risk components. The security team and security advisors should
be aware of the strengths and weaknesses of static analysis tools and be prepared to augment static
analysis tools with other tools or human review as appropriate.

SDL and PCI 10

5.0 Verification Practices

5.1 Perform Dynamic Code Analysis

Run-time verification of software programs is
necessary to verify that a program’s functionality Aligns with:
Testing of all security patches, and systems and
works as designed. This verification task should specify
software changes before deployment… – PCI DSS Req.
tools that monitor application behavior for memory 6.3.1
corruption, user privilege issues, and other critical
security problems. The SDL process uses run-time
tools, along with other techniques such as fuzz testing, to achieve desired levels of security test coverage.

5.2 Perform Fuzz Testing

Fuzz testing is a specialized form of dynamic analysis
used to induce program failure by deliberately Aligns with:
Review Custom Code prior to release – PCI DSS Req.
introducing malformed or random data to an 6.4.4
application. The strategy for fuzz testing should be
derived from the intended use of the application and
the functional and design specifications for the application. The security advisor may require additional
fuzz tests or increases in the scope and duration of fuzz testing.

5.3 Conduct Attack Surface Review

It is common for an application to deviate significantly
from the functional and design specifications created Aligns with:
Incident Response Plan – PCI DSS Req. 12.9
during the requirements and design phases of a Back-out Procedures – PCI DSS Req. 6.4.4
software development project. Therefore, it is critical
to re-review the threat models and attack surface of
an application when it is code complete to account for any design or implementation changes to the
system and verify that mitigations are in place for any new attack vectors created.

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.

6.0 Release Practices

6.1 Create an Incident Response Plan

Every application, whether host- or web-based, should
be supported by an incident response plan. Even Aligns with:
Incident Response Plan – PCI DSS Req. 12.9
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:
 A contact list that identifies a sustained engineering team, or if the development group is too
small to have these resources, a list of the appropriate engineering, marketing, communications,
and management staff to act as points of first contact in a security emergency.
 On-call contacts with decision-making authority available 24 hours a day, seven days a week.

SDL and PCI 11

  Security servicing plans (escalation
procedures) for code inherited from other Aligns with:
groups within the organization. If cardholder data is shared with service providers,
maintain and implement policies and procedures to
 Security servicing plans (escalation
manage service providers… – PCI DSS Req. 12.8
procedures) for licensed third-party code,
including file names, versions, source code,
third-party contact information, and contractual permission to make changes (if appropriate).

6.2 Perform a Final Security Review

The Final Security Review (FSR) is a deliberate
Aligns with:
examination of all the security activities performed on
Review of custom code prior to release to production or
a software application prior to release. The FSR is not a customers in order to identify any potential coding
“penetrate-and-patch” exercise, nor is it a chance to vulnerability… – PCI DSS Req. 6.3.7
perform security activities that were previously ignored
or forgotten during the project. 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 two 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. If there’s an exception, it must be reviewed by product team and
security advisor. If the security advisor in partnership with the product team cannot reach an
acceptable compromise, the security advisor cannot approve the project for release. Teams must
either address whatever SDL requirements that they can prior to launch or escalate to executive
management for a decision.

6.3 Archive All Release Data

Software release must be conditional on completion of the SDL process. The security advisor assigned to
the release must certify that the project team has satisfied security requirements.

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

SDL and PCI 12

APPLICABILITY OF THE SDL TO PCI DSS AND PA-DSS REGULATORY
REQUIREMENTS
The PCI SSC codified the PCI DSS in 2006 as an industry standard and it was agreed upon by the five
major payment card brands: American Express, Discover Network, JCB (formerly Japan Credit Bureau),
MasterCard Worldwide, and Visa Inc.

The Relationship Between PCI DSS and PA-DSS

The Payment Application Data Security Standard (PA-DSS) is derived from the requirements of the PCI
DSS and replaces Visa’s Payment Application Best Practices (PABP) implemented in 2005. The PA-DSS
applies PCI security requirements for organizations that develop payment applications that store, process,
or transmit cardholder data as part of authorization or settlement, where these payment applications are
sold, distributed, or licensed to third parties. While the PCI DSS applies to organizations that store,
process, or transmit payment card data, those organizations do not always develop their own payment
applications. As a result, PA-DSS validated applications are meant to enable compliance with the PCI DSS.
Using a PA-DSS payment application does not guarantee compliance, but it does enable compliance
within an organization that adheres to the other PCI compliance requirements.

The official PCI PA-DSS Requirements and Security Assessment Procedures document 1 lists the types of
applications that are subject to PA-DSS requirements.

In short, PA-DSS applies to:

 All “off-the-shelf” payment applications that can be sold and installed with little customization by
software vendors.

 Software provided as modules.

It does not apply to application service providers.

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.

 Protect stored cardholder data.

 Provide secure authentication.

 Log payment application activity.

 Develop or use secure payment applications.

 Protect wireless transmissions if used.

 Test payment applications to address vulnerabilities.

 Facilitate secure network implementation.

 No cardholder data may be stored on Internet-facing servers or applications.

 Use secure remote software updates.

 Use secure remote access to payment applications.

1
https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

SDL and PCI 13

  Encrypt sensitive traffic when on public networks.

 Encrypt all non-console administrative access.

 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.

SDL and PCI 14

 Payment Any application that stores, processes, or transmits cardholder data as part of
Application authorization or settlement
For purposes of PCI DSS, any payment card/device that bears the logo of the
Payment Card founding members of PCI SSC, which are American Express, Discover Financial
Services, JCB International, MasterCard Worldwide, or Visa, Inc.
Sensitive Security-related information (including but not limited to card validation
Authentication codes/values, full magnetic-stripe data, PINs, and PIN blocks) used to
Data authenticate cardholders and/or authorize payment card transactions.
Business entity that is not a payment brand directly involved in the processing,
storage, or transmission of cardholder data. This also includes companies that
provide services that control or could impact the security of cardholder data.
Service Provider Examples include managed service providers that provide managed firewalls, IDS,
and other services, in addition to hosting providers and other entities. Entities
such as telecommunications companies that only provide communication links
without access to the application layer of the communication link are excluded.
Table 1: Common PCI-related definitions2

Scope and Applicability

The scope of a PCI DSS assessment is one of the most often discussed topics within the industry, and as
such is critical to the discussion of the PCI DSS standard. For the purposes of this paper, the following
description of an assessment3 is used:

 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.

Discussion on Applicability of the SDL to PCI DSS and PA-DSS

This section examines the phases of the SDL and discusses where the SDL specifically contributes to
meeting PCI DSS requirements in one or both of our scenarios: Adventure Works’ New Software Build
Scenario or Northwind Traders’ Custom Software Integration Scenario. Note that many of the
requirements within both PCI DSS and PA-DSS do not align with the SDL practices because many of them
focus on physical security and operational processes. The practices discussed in this section are mapped
to the PCI DSS requirements in a table included in Appendix A and the PA-DSS requirements in a table in
Appendix B.

1.0 Security Training

The SDL practice of security training focuses on training all team members in secure coding techniques
and the security and privacy requirements of the PCI DSS and the PA-DSS. PCI DSS and the PA-DSS

2
Source: PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms
3
Source: The PCI Security Assessment Procedures (SAP)

SDL and PCI 15

documents both specifically require this training. Much of the default SDL training will help a
development organization meet the PCI DSS training requirement.

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.

SDL and PCI 16

During the SDL Requirements Phase the items in Table 2 would be included in the security requirements,
the Security and Privacy Risk Assessment, and the privacy assessment and placed under change control.
Change control is a requirement in PA-DSS 5.3 and aligns with the requirements practices of the SDL in
managing quality gates and bug bars. The change control call outs in PA-DSS 5.3 are very specific in the
type, customer impact, management sign-off, and back-out procedures that must be included. These
change requirements can be met using a strong development process, such as 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.

3.0 Design Practices

The SDL Design Phase practices include Establish Design Requirements, Analyze Attack Surface, and
Complete Threat Model. The PCI DSS and PA-DSS requirements of appropriate cryptographic use and
control should be established alongside these important SDL practices. Designing software that aligns
with these requirements and practices should go hand-in-hand for Adventure Works and Northwind
Traders.

3.1 Establish Security Design Requirements

Whether designing new software applications or making changes in a customized development system,
accounting for security in the design and architecture of a system is critical. For Adventure Works’ New
Software Build Scenario, each design specification should adhere to a predefined set of requirements
related to the PA-DSS requirements in authentication, access to data, user consent before use of high-risk
features, secure implementation of all functionality, and proper use of cryptography. For Northwind
Traders, the integration of their custom development POS system requires design considerations on two
sides: review of the security design for existing systems and review of the intended security design
requirements for the POS system code they acquired. Any changes they make to the acquired third-party
software require revalidation for both PCI DSS compliance and SDL-based security coding practices.
Fortunately, many of these requirements align.

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.

3.2 Attack Surface Analysis

Requirement 5.2 of the PA-DSS, which requires that all development of web payment applications use
established secure coding guidelines, aligns well with the attack surface analysis and the threat modeling
SDL practices.

3.3 Threat Modeling

The SDL threat modeling process uses the STRIDE approach to help the development team identify
potential threats in an architectural review of their software. This activity closely aligns with the PA-DSS in
requirement 5.3. By reviewing the threat models created in the SDL Design Phase, an organization can

SDL and PCI 17

also more comprehensively meet the PCI DSS requirement of 6.3.2 and 6.6 that call for the review of
custom code prior to any release to production.

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.

4.0 Implementation Practices

The Implementation Phase practices of Use Approved Tools, Deprecate Unsafe Practices, and Perform Static
Analysis can meet some of the requirements of both PCI DSS and PA-DSS.

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 cryptographic storage.

 Insecure communications.

 Improper error handling.

 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.

 Cross-site scripting (XSS).

 Improper access control (such as insecure direct object references, failure to restrict URL access,
and directory traversal).

 Cross-site request forgery (CSRF).

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.

5.0 Verification Practices

The SDL Verification Phase practices of Perform Dynamic Code Analysis, Perform Fuzz Testing, and
Conduct Attack Surface Review are not individually specified in PCA DSS or PA-DSS requirements.
However, requirement 6.5 does require that software development processes are in place to prevent
common coding vulnerabilities. The SDL takes the requirement of testing further and dictates three
specific proven activities to enhance the verification of code security. A development organization should
implement the three SDL practices of the Verification Phase—dynamic analysis, fuzz testing, and attack
surface review—to address the security of its code and the PCI DSS and PA-DSS requirements. It should
be noted that these three SDL practices are intended to help achieve compliance with PCI DSS
Requirement and Testing Procedures of 6.5 and the Testing Procedures associated with PCI DSS
Requirements 6.5.1-6.5.9.

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.

6.0 Release Practices

The SDL Release Phase practices of Create an Incident Response Plan, Perform a Final Security Review, and
Archive All Release Data align to some of the requirements of the PCI DSS and PA-DSS. PCI DSS
requirements 1.3.6, 11.1, 12.5.3, and 12.9 call for creation of an incident response plan. See the SDL
requirements earlier in this paper for what an incident response plan should contain.

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,

SDL and PCI 19

and a repository of the final code) is a critical final step, enabling future reference that will speed
investigations of new incidents as they arise.

SDL and PCI 20

CONCLUSION
This paper examined how the Security Development Lifecycle (SDL) can help an organization meet some
of the requirements of the PCI DSS and PA-DSS. It provided an overview of how a software developer can
use the SDL process to meet many of the requirements of the PCI DSS and PA-DSS while creating or
integrating more secure software. Throughout the paper, activities were associated with common
software scenarios where cardholder data required consideration of the PCI DSS and PA-DSS, and it
explained how the SDL process might help structure the protection of cardholder data in payment card
software.

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:

 Simplified Implementation of the Microsoft SDL (http://go.microsoft.com/?linkid=9708425)

 The SDL Optimization Model (http://www.microsoft.com/security/sdl/learn/assess.aspx)
 The Microsoft Security Development Lifecycle Process Guidance – Version 5
(http://go.microsoft.com/?linkid=9724944)
 The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure
Software, Steve Lipner and Michael Howard, MS Press, 2006.
(http://www.microsoft.com/learning/en/us/book.aspx?ID=8753)

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

SDL and PCI 21

APPENDIX A: PCI DSS REQUIREMENTS MAPPED TO THE SDL PRACTICES (PULL-OUT)
PCI DSS Requirements   SDL Practice Practice Description
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee
Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or
via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key
protection mechanism for any computer network.
Obtain and inspect the firewall and router configuration
Establish firewall and router
standards and other documentation specified below to
1.1 configuration standards that include    
verify that standards are complete. Complete the
the following:
following:
A formal process for approving and
Verify that there is a formal process for testing and
testing all network connections and
1.1.1 approval of all network connections and changes to    
changes to the firewall and router
firewall and router configurations.
configurations.
1.1.2.a Verify that a current network diagram (for example,
Current network diagram with all
one that shows cardholder data flows over the network) Design 3.3 Complete Threat Models
1.1.2 connections to cardholder data,
exists and that it documents all connection.
including any wireless networks.
1.1.2.b Verify that the diagram is kept current. Design 3.3 Complete Threat Models
1.1.3.a Verify that firewall configuration standards include
Requirements for a firewall at each requirements for a firewall at each Internet connection and
Internet connection and between between any DMZ and the internal network zone. Design 3.2 Analyze Attack Surface
1.1.3
any demilitarized zone (DMZ) and Design 3.3 Complete Threat Models
1.1.3.b Verify that the current network diagram is
the internal network zone.
consistent with the firewall configuration standards.

Description of groups, roles, and

responsibilities for logical
1.1.4
management of network
components.
Documentation and business
justification for use of all services,
protocols, and ports allowed,
including documentation of security
1.1.5 features implemented for those
protocols considered to be insecure.
Verify that firewall and router configuration standards
Design 3.2 Analyze Attack Surface
include a description of groups, roles, and responsibilities
Design 3.3 Complete Threat Models
for logical management of network components.
1.1.5.a Verify that firewall and router configuration
standards include a documented list of services, protocols
and ports necessary for business—for example, hypertext
Design 3.2 Analyze Attack Surface
transfer protocol (HTTP) and Secure Sockets Layer (SSL),
Secure Shell (SSH), and Virtual Private Network (VPN)
protocols.

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

SDL and PCI 22


not limited to FTP, Telnet, POP3,
IMAP, and SNMP.
Requirement to review firewall and
1.1.6 router rule sets at least every six
months.
Build firewall configurations that
restrict connections between
untrusted networks and any system
components in the cardholder data
environment.
1.2
Note: An “untrusted network” is any
network that is external to the
networks belonging to the entity
under review, and/or which is out of
the entity's ability to control or
manage.
Restrict inbound and outbound
1.2.1 traffic to that which is necessary for
the cardholder data environment.
Secure and synchronize router
1.2.2
configuration files.
1.2.3 Install perimeter firewalls between
any wireless networks and the
cardholder data environment, and
configure these firewalls to deny or
control (if such traffic is necessary
SDL and PCI
features are documented and implemented by examining
firewall and router configuration standards and settings
for each service. An example of an insecure service,
protocol, or port is FTP, which passes user credentials in
clear-text.
1.1.6.a Verify that firewall and router configuration
standards require review of firewall and router rule sets at    
least every six months.
1.1.6.b Obtain and examine documentation to verify that
the rule sets are reviewed at least every six months.
Examine firewall and router configurations to verify that
connections are restricted between untrusted networks Design 3.2 Analyze Attack Surface
and system components in the cardholder data Design 3.3 Complete Threat Models
environment, as follows:
1.2.1.a Verify that inbound and outbound traffic is limited
Design 3.2 Analyze Attack Surface
to that which is necessary for the cardholder data
Design 3.3 Complete Threat Models
environment, and that the restrictions are documented.
1.2.1.b Verify that all other inbound and outbound traffic is
Design 3.2 Analyze Attack Surface
specifically denied; for example, by using an explicit “deny
Design 3.3 Complete Threat Models
all” or an implicit deny after allow statement.
Verify that router configuration files are secure and
synchronized—for example, running configuration files
(used for normal running of the routers) and start-up    
configuration files (used when machines are re-booted),
have the same, secure configurations.
Verify that there are perimeter firewalls installed between    
any wireless networks and systems that store cardholder
data, and that these firewalls deny or control (if such traffic
is necessary for business purposes) any traffic from the
wireless environment into the cardholder data
23
 for business purposes) any traffic
from the wireless environment into environment.
the cardholder data environment.
Examine firewall and router configurations—including but
not limited to the choke router at the Internet, the DMZ
Prohibit direct public access
router and firewall, the DMZ cardholder segment, the
between the Internet and any system
1.3 perimeter router, and the internal cardholder network    
component in the cardholder data
segment—to determine that there is no direct access
environment.
between the Internet and system components in the
internal cardholder network segment, as detailed below.
Implement a DMZ to limit inbound
traffic to only system components Verify that a DMZ is implemented to limit inbound traffic
1.3.1 that provide authorized publicly to only system components that provide authorized    
accessible services, protocols, and publicly accessible services, protocols, and ports.
ports.
Limit inbound Internet traffic to IP Verify that inbound Internet traffic is limited to IP
1.3.2    
addresses within the DMZ. addresses within the DMZ.
Do not allow any direct routes
Verify direct connections inbound or outbound are not
inbound or outbound for traffic
1.3.3 allowed for traffic between the Internet and the cardholder    
between the Internet and the
data environment.
cardholder data environment.
Do not allow internal addresses to Verify that internal addresses cannot pass from the
1.3.4    
pass from the Internet into the DMZ. Internet into the DMZ.
Do not allow unauthorized
Verify that outbound traffic from the cardholder data
1.3.5 outbound traffic from the cardholder    
environment to the Internet is explicitly authorized
data environment to the Internet.
Implement stateful inspection, also
Verify that the firewall performs stateful inspection
known as dynamic packet filtering.
(dynamic packet filtering). (Only established connections
1.3.6 (That is, only ”established”    
should be allowed in, and only if they are associated with a
connections are allowed into the
previously established session.)
network.)
Place system components that store
cardholder data (such as a database) Verify that system components that store cardholder data
1.3.7 in an internal network zone, are on an internal network zone, segregated from the    
segregated from the DMZ and other DMZ and other untrusted networks..
untrusted networks.

SDL and PCI 24

 Do not disclose private IP addresses 1.3.8.a Verify that methods are in place to prevent the
and routing information to disclosure of private IP addresses and routing information
unauthorized parties. from internal networks to the Internet.

Note: Methods to obscure IP

addressing may include, but are not
limited to:
- Network Address Translation (NAT)
1.3.8    
- Placing servers containing
cardholder data behind proxy 1.3.8.b Verify that any disclosure of private IP addresses
servers/firewalls or content caches, and routing information to external entities is authorized.
- Removal or filtering of route
advertisements for private networks
that employ registered addressing,
- Internal use of RFC1918 address
space instead of registered addresses.
1.4.a Verify that mobile and/or employee-owned
computers with direct connectivity to the Internet (for
Install personal firewall software on
example, laptops used by employees), and which are used    
any mobile and/or employee-owned
to access the organization’s network, have personal
computers with direct connectivity
1.4 firewall software installed and active.
to the Internet (for example, laptops
1.4.b Verify that the personal firewall software is
used by employees), which are used
configured by the organization to specific standards and is
to access the organization’s network.    
not alterable by users of mobile and/or employee-owned
computers.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security
The Microsoft SDL focuses on application
parameters
development security. Use of vendor-
Malicious individuals (external and internal to a company) often use vendor default passwords and other
supplied passwords is not addressed in SDL
vendor default settings to compromise systems. These passwords and settings are well known by hacker
practices.
communities and are easily determined via public information.
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents
other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other
effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example methods for minimizing risk include
not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-
user messaging technologies, such as e-mail and instant messaging.

SDL and PCI 25

 Keep cardholder data storage to a
minimum. Develop a data retention
and disposal policy. Limit storage
amount and retention time to that
3.1
which is required for business, legal,
and/or regulatory purposes, as
documented in the data retention
policy.
Implement a data retention and
disposal policy that includes:
 Limiting data storage amount
and
 retention time to that which is
required for legal, regulatory,
and
 business requirements
 Processes for secure deletion of
 data when no longer needed
3.1.1
 Specific retention requirements
for
 cardholder data
 A quarterly automatic or manual
process for identifying and
securely
 deleting stored cardholder data
that
 exceeds defined retention
 requirements
SDL and PCI
Obtain and examine the policies, procedures and
processes for
   
data retention and disposal, and perform the
following:
3.1.1.a Verify that policies and procedures are
implemented and include legal, regulatory, and
business requirements for data retention, including
specific requirements for retention of cardholder
data (for example, cardholder data needs to be held
for X period for Y business reasons).
3.1.1.b Verify that policies and procedures include
provisions for secure disposal of data when no
longer needed for legal, regulatory, or business
reasons, including disposal of cardholder data.
3.1.1.c Verify that policies and procedures include
coverage for all storage of cardholder data.
3.1.1.d Verify that policies and procedures include at
least one of the following:
A programmatic process (automatic or manual) to
remove, at least quarterly, stored cardholder data
that exceeds requirements defined in the data
retention policy.
Requirements for a review, conducted at least
quarterly, to verify that stored cardholder data does
not exceed requirements defined in the data
retention policy.
3.1.1.e For a sample of system components that
store cardholder data, verify that the data stored
does not exceed the requirements defined in the
data retention policy.
26

Do not store sensitive authentication
data after authorization (even if
encrypted).
3.2
Sensitive authentication data
includes the data as cited in the
following Requirements 3.2.1
through 3.2.3:
Do not store the full contents of any
track from the magnetic stripe ((from
the magnetic stripe located on the
back of a card, equivalent data
contained on a chip, or elsewhere).
This data is alternatively called full
track, track, track 1, track 2, and
magnetic-stripe data.
Note: In the normal course of
3.2.1 business, the following data
elements from the magnetic stripe
may need to be retained:
 The cardholder’s name,
 Primary account number (PAN),
 Expiration date, and
 Service code
3.2.a For issuers and/or companies that support Establish Security
issuing services and store sensitive authentication Requirements
data, verify there is a business justification for the Perform Security & Privacy
storage of sensitive authentication data, and that Requirements 2.1 Risk Assessment
the data is secured. Requirements 2.3 Perform periodic static code
3.2.b For all other entities, if sensitive authentication Implementation analysis
data is received and deleted, obtain and review the 4.3 Verification Practices
processes for securely deleting the data to verify Verification 5.0- -Perform dynamic code
that the data is unrecoverable. Verification 5.3 analysis
-Perform fuzz testing
3.2.c For each item of sensitive authentication data -Conduct Attack Surface
below, perform the following steps: Review
For a sample of system components, examine data
Establish Security
sources, including but not limited to the following,
Requirements
and verify that the full contents of any track from
Perform Security & Privacy
the magnetic stripe on the back of card or
Requirements 2.1 Risk Assessment
equivalent data on a chip are not stored under any
Requirements 2.3 Perform Periodic Static Code
circumstance:
Implementation Analysis
 Incoming transaction data
4.3 Verification Practices
 All logs (for example, transaction, history,
Verification 5.0- -Perform Dynamic Code
debugging, error)
Verification 5.3 Analysis
 History files
-Perform Fuzz Testing
 Trace files
-Conduct Attack Surface
 Several database schemas
Review
 Database contents

To minimize risk, store only these

data elements as needed for
business.

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

SDL and PCI 27


Note: See PCI DSS Glossary of Terms,
Abbreviations, and Acronyms for
additional information.
Do not store the personal
3.2.3 identification number (PIN) or the
encrypted PIN block.
Mask PAN when displayed (the first
six and last four digits are the
maximum number of digits to be
displayed).
Notes:
 This requirement does not apply
to employees and other parties
3.3
with a legitimate business need
to see the full PAN.
 This requirement does not
supersede stricter requirements
in place for displays of
cardholder data—for example,
for point-of sale (POS) receipts.
Render PAN unreadable anywhere it
is stored (including on portable
3.4
digital
media, backup media, and in logs)
SDL and PCI
data) is not stored under any circumstance:
Analysis
 Incoming transaction data
Verification Practices
 All logs (for example, transaction, history,
-Perform Dynamic Code
debugging, error)
Verification 5.3 Analysis
 History files
-Perform Fuzz Testing
 Trace files
-Conduct Attack Surface
 Several database schemas
Review
 Database contents
For a sample of system components, examine the Establish Security
following and verify that PINs and encrypted PIN Requirements
blocks are not stored under any circumstance: Perform Security & Privacy
 Incoming transaction data Requirements 2.1 Risk Assessment
 All logs (for example, transaction, history, Requirements 2.3 Perform Periodic Static Code
debugging, error) Implementation Analysis
 History files 4.3 Verification Practices
 Trace files Verification 5.0- -Perform Dynamic Code
 Several database schemas Verification 5.3 Analysis
 Database contents -Perform Fuzz Testing
-Conduct Attack Surface
Review
Obtain and examine written policies and examine
displays of PAN (for example, on screen, on paper
receipts) to verify that primary account numbers
   
(PANs) are masked when displaying cardholder
data, except for those with a legitimate business
need to see full PAN.
3.4.a Obtain and examine documentation about the
Satisfy Minimum
system used to protect the PAN, including the
Design 3.1.3 Cryptographic Design
vendor, type of system/process, and the encryption
Requirements
algorithms (if applicable). Verify that the PAN is
28
by rendered unreadable using any of the following
using any of the following methods:
approaches:  One-way hashes based on strong cryptography
 One-way hashes based on  Truncation
strong  Index tokens and pads, with the pads being
 cryptography (hash must be of securely stored
the  Strong cryptography, with associated key-
 entire PAN) management processes and procedures
 Truncation (hashing cannot be 3.4.b Examine several tables or files from a sample Satisfy Minimum
used of data repositories to verify the PAN is rendered Design 3.1.3 Cryptographic Design
 to replace the truncated unreadable (that is, not stored in plain-text). Requirements
segment of 3.4.c Examine a sample of removable media (for Satisfy Minimum
 PAN) example, back-up tapes) to confirm that the PAN is Design 3.1.3 Cryptographic Design
 Index tokens and pads (pads rendered unreadable. Requirements
must
 be securely stored)
 Strong cryptography with
associated
 key-management processes and
 procedures

Note: It is a relatively trivial effort for

a malicious individual to reconstruct 3.4.d Examine a sample of audit logs to confirm that Satisfy Minimum
original PAN data if they have access the PAN is rendered unreadable or removed from Design 3.1.3 Cryptographic Design
to both the truncated and hashed the logs. Requirements
version of a PAN. Where hashed and
truncated versions of the same PAN
are present in an entity’s
environment, additional controls
should be in place to ensure that the
hashed and truncated versions
cannot be correlated to reconstruct
the original PAN.

SDL and PCI 29


If disk encryption is used (rather
than file- or column-level database
encryption), logical access must be
managed independently of native
3.4.1 operating system access control
mechanisms (for example, by not
using local user account databases).
Decryption keys must not be tied to
user accounts.
Protect cryptographic keys used for
encryption of cardholder data
against both disclosure and misuse:
Note: This requirement also applies
3.5
to
key-encrypting keys used to protect
data-encrypting keys—such key-
encrypting keys must be at least as
strong as the data-encrypting key.
Restrict access to cryptographic keys
3.5.1 to the fewest number of custodians
necessary.
Store cryptographic keys securely in
3.5.2 the fewest possible locations and
forms.
SDL and PCI
3.4.1.a If disk encryption is used, verify that logical
access to encrypted file systems is implemented via Satisfy Minimum
a mechanism that is separate from the native Design 3.1.3 Cryptographic Design
operating systems mechanism (for example, not Requirements
using local user account databases).
3.4.1.b Verify that cryptographic keys are stored
Satisfy Minimum
securely (for example, stored on removable media
Design 3.1.3 Cryptographic Design
that is adequately protected with strong access
Requirements
controls).
3.4.1.c Verify that cardholder data on removable
media is encrypted wherever stored.
Satisfy Minimum
Note: If disk encryption is not used to encrypt Design 3.1.3 Cryptographic Design
removable media, the data stored on this media will Requirements
need to be rendered unreadable through some other
method.
Verify processes to protect keys used for encryption Satisfy Minimum
of cardholder data against disclosure and misuse by Design 3.1.3 Cryptographic Design
performing the following: Requirements
Examine user access lists to verify that access to
keys is restricted to the fewest number of    
custodians necessary.
3.5.2.a Examine system configuration files to verify
that keys are stored in encrypted format and that
key-encrypting keys are stored separately from
data-encrypting keys.
3.5.2.b Identify key storage locations to verify that
keys are stored in the fewest possible locations and
forms.
30

Fully document and implement all
key-management processes and
procedures for cryptographic keys
used for encryption of cardholder
data, including the following:
3.6
Note: Numerous industry standards
for key management are available
from various resources including
NIST, which can be found at
http://csrc.nist.gov.
Generation of strong cryptographic
3.6.1
keys
Secure cryptographic key
3.6.2
distribution
3.6.3 Secure cryptographic key storage
Cryptographic key changes for keys
that have reached the end of their
cryptoperiod (for example, after a
defined period of time has passed
and/or after a certain amount of
ciphertext has been produced by a
3.6.4
given key), as defined by the
associated application vendor or key
owner, and based on industry best
practices and guidelines (for
example, NIST Special Publication
800-57).
SDL and PCI
3.6.a Verify the existence of key-management Satisfy Minimum
procedures for keys used for encryption of Design 3.1.3 Cryptographic Design
cardholder data. Requirements
3.6.b For service providers only: If the service
provider shares keys with their customers for
transmission or storage of cardholder data, verify
Satisfy Minimum
that the service provider provides documentation to
Design 3.1.3 Cryptographic Design
customers that includes guidance on how to
Requirements
securely transmit, store and update customer’s keys,
in accordance with Requirements 3.6.1 through
3.6.8 below.
Satisfy Minimum
3.6.c Examine the key-management procedures and
Design 3.1.3 Cryptographic Design
perform the following:
Requirements
Verify that key-management procedures are Satisfy Minimum
implemented to require the generation of strong Design 3.1.3 Cryptographic Design
keys. Requirements
Satisfy Minimum
Verify that key-management procedures are
Design 3.1.3 Cryptographic Design
implemented to require secure key distribution.
Requirements
Satisfy Minimum
Verify that key-management procedures are
Design 3.1.3 Cryptographic Design
implemented to require secure key storage.
Requirements
Verify that key-management procedures are
implemented to require periodic key changes at the    
end of the defined cryptoperiod.
31
 Retirement or replacement (for 3.6.5.a Verify that key-management procedures are
example, archiving, destruction, implemented to require the retirement of keys    
and/or revocation) of keys as when the integrity of the key has been weakened.
deemed necessary when the 3.6.5.b Verify that the key-management procedures
integrity of the key has been are implemented to require the replacement of    
weakened (for example, departure of known or suspected compromised keys.
an employee with knowledge of a
clear-text key), or keys are suspected
3.6.5 of being compromised.
Note: If retired or replaced
3.6.c If retired or replaced cryptographic keys are
cryptographic keys need to be
retained,
retained, these keys must be securely
verify that these keys are not used for encryption
archived (for example, by using a key
operations.
encryption key). Archived
cryptographic keys should only be
used for decryption/verification
purposes.
If manual clear-text cryptographic
key management operations are
used, these operations must be
managed using split knowledge and
dual control (for example, requiring
two or three people, each knowing Verify that manual clear-text key-management
3.6.6 only their own key component, to procedures require split knowledge and dual    
reconstruct the whole key). control of keys.
Note: Examples of manual key
management operations include, but
are not limited to: key generation,
transmission, loading, storage and
destruction.
Verify that key-management procedures are
Prevention of unauthorized
3.6.7 implemented to require the prevention of    
substitution of cryptographic keys
unauthorized substitution of keys.
3.6.8 Requirement for cryptographic key Verify that key-management procedures are    
custodians to formally acknowledge implemented to require key custodians to
that they understand and accept acknowledge (in writing or electronically) that they
their key-custodian responsibilities. understand and accept their key-custodian

SDL and PCI 32

 responsibilities.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks
and vulnerabilities in legacy encryption and authentication protocols can be continued targets of malicious individuals who exploit these vulnerabilities to gain
privileged access to cardholder data environments.
4.1 Verify the use of security protocols wherever
cardholder data is transmitted or received over open,
Use strong cryptography and public networks. Verify that strong cryptography is
security used during data transmission, as follows:
protocols (example, SSL/TLS, IPSEC, 4.1.a Select a sample of transactions as they are
SSH, etc.) to safeguard sensitive received and observe transactions as they occur to
cardholder data during transmission verify that cardholder data is encrypted during transit.
over open, public networks. 4.1.b Verify that only trusted keys and/or certificates
Examples of open, public networks are accepted. Satisfy Minimum
4.1 that are in scope of the PCI DSS 4.1.c Verify that the protocol is implemented to use Design 3.1.3 Cryptographic Design
include but are not limited to: only secure configurations, and does not support Requirements
 The Internet insecure versions or configurations.
 Wireless technologies, 4.1.d Verify that the proper encryption strength is
 Global System for Mobile implemented for the encryption methodology in use.
 communications (GSM) (Check vendor recommendations/best practices.)
 General Packet Radio Service 4.1.e For SSL/TLS implementations: Verify that HTTPS
 (GPRS). appears as a part of the browser Universal Record
Locator (URL). Verify that no cardholder data is
required when HTTPS does not appear in the URL.
Verify wireless networks transmitting For wireless networks transmitting cardholder data or
cardholder data or connected to the connected to the cardholder data environment, verify
cardholder data environment, use that industry best practices (for example, IEEE 802.11i)
industry best practices (for example, are used to implement strong encryption for
IEEE 802.11i) to implement strong authentication and transmission. Satisfy Minimum
4.1.1 encryption for authentication and Design 3.1.3 Cryptographic Design
transmission. Requirements

Note: The use of WEP as a security

control was prohibited as of 30 June
2010.
4.2 Never send unprotected PANs by 4.2.a Verify that PAN is rendered unreadable or Design 3.1.3 Satisfy Minimum
end-user messaging technologies secured with strong cryptography whenever it is sent Cryptographic Design
(for via end-user messaging technologies. Verification 5.3 Requirements

SDL and PCI 33

 Conduct Attack Surface
example, e-mail, instant messaging, Review
chat, 4.2.b Verify the existence of a policy stating that
etc.). unprotected PANs are not to be sent via end-user    
messaging technologies.
Requirement 5: Use and regularly update antivirus software or programs
Malicious software, commonly referred to as “malware” enters the network during many business approved activities including employees’ email and use of
the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Antivirus software must be used on all systems
commonly affected by malware to protect systems from current and evolving malicious software threats.
Deploy antivirus software on all For a sample of system components including all
systems commonly affected by operating system types commonly affected by Establish Security Design
5.1 Design 3.1
malicious software (particularly malicious software, verify that antivirus software is Requirements
personal computers and servers). deployed if applicable antivirus technology exists.
For a sample of system components, verify that all
Ensure that all anti-virus programs
antivirus programs detect, remove, and protect
are capable of detecting, removing, Perform Security Design
5.1.1 against all known types of malicious software (for Design 3.1.1
and protecting against all known Review
example, viruses, Trojans, worms, spyware, adware,
types of malicious software.
and rootkits).
Verify that all antivirus software is current, actively
running, and generating logs by performing the    
following:
5.2.a Obtain and examine the policy and verify that it
requires updating of antivirus software and    
definitions.
5.2.b Verify that the master installation of the software
Ensure that all antivirus mechanisms    
is enabled for automatic updates and periodic scans.
5.2 are current, actively running, and
5.2.c For a sample of system components including all
generating audit logs.
operating system types commonly affected by
   
malicious software, verify that automatic updates and
periodic scans are enabled.
5.2.d For a sample of system components, verify that
anti-virus software log generation is enabled and that
   
such logs are retained in accordance with PCI DSS
Requirement 10.7.
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these
   
vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that
manage the systems. All critical systems must have the most recently released, appropriate software

SDL and PCI 34

patches to protect against exploitation and compromise of cardholder data by malicious individuals and
malicious software.
Ensure that all system components 6.1.a For a sample of system components and related
and software are protected from software, compare the list of security patches installed
known vulnerabilities by having the on each system to the most recent vendor security    
latest vendor-supplied security patch list, to verify that current vendor patches are
patches installed. Install critical installed.
security patches within one month of
release.

Note: An organization may consider

applying a risk-based approach to
6.1
prioritize their patch installations. For
example, by prioritizing critical 6.1.b Examine policies related to security patch
infrastructure (for example, public- installation to verify they require installation of all    
facing devices and systems, critical new security patches within one month.
databases) higher than less-critical
internal devices, to ensure high-
priority systems and devices are
addressed within one month, and
addressing less critical devices and
systems within three months.
6.2 Establish a process to identify and 6.2.a Interview responsible personnel to verify that
assign a risk ranking to newly processes are implemented to identify new security
discovered security vulnerabilities. vulnerabilities, and that a risk ranking is assigned to Requirements
Create Quality Gates/Bug Bars
such vulnerabilities. (At minimum, the most critical, 2.2
Notes: highest risk vulnerabilities should be ranked as
 Risk rankings should be based “High.”)
on industry best practices. For 6.2.b Verify that processes to identify new security Requirements Create Quality Gates/Bug Bars
example, criteria for ranking vulnerabilities include using outside sources for 2.2
“High” risk vulnerabilities may security vulnerability information.
include a CVSS base score of 4.0
or above, and/or a vendor-
supplied patch classified by the
vendor as “critical,” and/or a
vulnerability affecting a critical
system component.
 The ranking of vulnerabilities as

SDL and PCI 35

 defined in 6.2.a is considered a
best practice until June 30, 2012,
after which it becomes a
requirement.

6.3.a Obtain and examine written software

Develop software applications
(internal and external, and including
web-based administrative access to
applications) in accordance with PCI
DSS (for example, secure
authentication and logging), and
6.3
based on industry best practices.
Incorporate information security
throughout the software
development life cycle. These
processes must include the
following:
development processes to verify that the processes
are based on industry standards and/or best practices.
6.3.b Examine written software development
processes to verify that information security is
Adoption of the entire Microsoft SDL Process
included throughout the life cycle.
will enable a development organization to meet
6.3.c Examine written software development this PCI DSS requirement.
processes to verify that software applications are  
developed in accordance with PCI DSS.  
6.3.d From an examination of written software
development processes, and interviews of software
developers, verify that:

Removal of custom application

Custom application accounts, user IDs and/or
accounts, user IDs, and passwords
6.3.1 passwords are removed before system goes into
before applications become active or
production or is released to customers.
are released to customers

SDL and PCI 36

 Review of custom code prior to
release to production or customers
in
order to identify any potential
coding vulnerability.
Note: This requirement for code
reviews applies to all custom code
(both internal and public-facing), as
6.3.2
part of the system development life
cycle. Code reviews can be conducted
by knowledgeable internal personnel
or third parties. Web applications are
also subject to additional controls, if
they are public facing, to address
ongoing threats and vulnerabilities
after implementation, as defined at
PCI DSS Requirement 6.6.
Follow change control processes and
procedures for all changes to system
6.4
components. The processes must
include the following:
Separate development/test and
6.4.1
production environments.
Separation of duties between
6.4.2 development/test and production
environments.
Production data (live PANs) are not
6.4.3
used for testing or development.
Removal of test data and accounts
6.4.4 before production systems become
active.
SDL and PCI
6.3.2.a Obtain and review policies to confirm that all
custom application code changes must be reviewed
(using either manual or automated processes) as
follows:
 Code changes are reviewed by individuals other
than the originating code author, and by
individuals who are knowledgeable in code
review techniques and secure coding practices.    
 Code reviews ensure code is developed
according to secure coding guidelines (see PCI
DSS Requirement 6.5).
 Appropriate corrections are implemented prior to
release.
 Code review results are reviewed and approved
by management prior to release.
6.3.2.b Select a sample of recent custom application
changes and verify that custom application code is
reviewed according to 6.3.2.a, above.
From an examination of change control processes,
interviews with system and network administrators,
and examination of relevant data (network
configuration documentation, production and test
data, etc.), verify the following:
The development/test environments are separate
from the production environment, with access control    
in place to enforce the separation.
There is a separation of duties between personnel
assigned to the development/test environments and
those assigned to the production environment.
Production data (live PANs) are not used for testing
   
and development.
Test data and accounts are removed before a
   
production system becomes active.
37
 Management sign-off by
6.4.2
appropriate parties
6.4.3 Testing of operational functionality
6.4.4 Back-out procedures
Change control procedures for the
implementation of security patches
6.4.5 and software modifications.
Procedures must include the
following:
6.4.5.1 Documentation of impact.
6.4.5.2 Documented change approval by
authorized parties.
Functionality testing to verify that
6.4.5.3
the change does not adversely
impact the security of the system.
6.4.5.4 Back-out procedures.
6.5 Develop applications based on
secure coding guidelines. Prevent
common coding vulnerabilities in
software development processes, to
include the following:
Note: The vulnerabilities listed at
6.5.1 through 6.5.9 were current with
industry best practices when this
version of PCI DSS was published.
However, as industry best practices
for vulnerability management are
SDL and PCI
Verify that management sign-off by appropriate
   
parties is present for each sampled change.
Verify that operational functionality testing is Perform a Final Security
Release 6.2
performed for each sampled change. Review
Verify that back-out procedures are prepared for each
   
sampled change
6.4.5.a Verify that change-control procedures related
to implementing security patches and software
modifications are documented and require items
6.4.5.1 – 6.4.5.4 below.
6.4.5.b For a sample of system components and
recent changes/security patches, trace those changes
back to related change control documentation. For
each change examined, perform the following:
Verify that documentation of impact is included in the
change control documentation for each sampled
change.
Verify that documented approval by authorized
parties is present for each sampled change.
For each sampled change, verify that functionality
Perform Dynamic Code
testing is performed to verify that the change does Verification 5.1
Analysis
not adversely impact the security of the system.
For custom code changes, verify that all updates are
tested for compliance with PCI DSS Requirement 6.5
before being deployed into production.
Verify that back-out procedures are prepared for each
sampled change.
6.5.a Obtain and review software development
processes. Verify that processes require training in
secure coding techniques for developers, based on
industry best practices and guidance.
6.5.b Interview a sample of developers and obtain
Perform Dynamic Code
evidence that they are knowledgeable in secure Verification 5.1
Analysis
coding techniques.
6.5.c Verify that processes are in place to verify that Verification 5.2 Perform Fuzz Testing
web applications are not vulnerable to the following:
38
 updated (for example, the OWASP
Guide, SANS CWE Top 25, CERT
Secure Coding, etc.), the current best
Injection flaws, particularly SQL
Injection flaws, particularly SQL injection. (Validate
injection. Also consider OS
input to verify user data cannot modify meaning of
6.5.1 Command Injection, LDAP and Xpath
commands and queries, utilize parameterized queries,
injection flaws as well as other
etc.)
injection flaws.
Buffer overflow (Validate buffer boundaries and
6.5.2 Buffer overflow
truncate input strings.)
Insecure cryptographic storage (Prevent cryptographic
6.5.3 Insecure cryptographic storage.
flaws.).
Insecure communications (Properly encrypt all
6.5.4 Insecure communications.
authenticated and sensitive communications.).
Improper error handling (Do not leak information via
6.5.5 Improper error handling.
error messages).
All “High” vulnerabilities identified
in the vulnerability identification
process (as defined in PCI DSS
Requirement 6.2). All “High” vulnerabilities as identified in PCI DSS
6.5.6
Note: This requirement is considered Requirement 6.2.
a best practice until June 30, 2012,
after which it becomes a
requirement.
Note: Requirements 6.5.7 through 6.5.9, below, apply to web applications and application interfaces (internal
or
external):
Cross-site scripting (XSS) (Validate all parameters
6.5.7 Cross-site scripting (XSS). before inclusion, utilize context-sensitive escaping,
etc.)
6.5.8 Improper Access Control (such as Improper Access Control, such as insecure direct
insecure direct object references, object
failure to restrict URL access, and references, failure to restrict URL access, and directory
directory traversal) traversal (Properly authenticate users and sanitize
input. Do not expose internal object references to
users.)

SDL and PCI 39

 Cross-site request forgery (CSRF). (Do not reply on
6.5.9 Cross-site request forgery (CSRF) authorization credentials and tokens automatically
submitted by browsers.)
For public-facing web applications, verify that either Perform Dynamic Code
Verification 5.1
one of the following methods are in place as follows: Analysis
 Verify that public-facing web applications are Perform Dynamic Code
Verification 5.1
reviewed (using either manual or automated Analysis
For public-facing web applications,
vulnerability security assessment tools or
address new threats and
methods), as follows:
vulnerabilities on an ongoing basis
- At least annually.
and verify these applications are
- After any changes.
protected against known attacks by
- By an organization that specializes in
either of the following methods:
application security.
 Reviewing public-facing web
- That all vulnerabilities are corrected.
6.6 applications via manual or
- That the application is re-evaluated after the
automated application
corrections.
vulnerability security assessment
 Verify that a web-application firewall is in place in
tools or methods, at least
front of public-facing web applications to detect
annually and after any changes.
and prevent web-based attacks. Verification 5.2 Perform Fuzz Testing
 Installing a web-application
firewall in front of public-facing
Note: “An organization that specializes in application
web applications.
security” can be either a third-party company or an
internal organization, as long as the reviewers
specialize in application security and can demonstrate
independence from the development team.
Requirement 7: Restrict access to cardholder data by business need to know
To verify critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and
according to job responsibilities.
Limit access to system components
and cardholder data to only those
Obtain and examine written policy for data control,
7.1 individuals whose job requires such    
and verify that the policy incorporates the following:
access. Access limitations must
include the following:
Restriction of access rights to
Confirm that access rights for privileged user IDs are
privileged user IDs to least privileges
7.1.1 restricted to least privileges necessary to perform job    
necessary to perform job
responsibilities.
responsibilities.
7.1.2 Assignment of privileges is based on Confirm that privileges are assigned to individuals Requirements Establish Security

SDL and PCI 40

 individual personnel’s job
classification and function.
Requirement for a documented
7.1.3 approval by authorized parties
specifying required privileges.
Implementation of an automated
7.1.4
access control system.
Establish an access control system
for systems components with
multiple users that restricts access
7.2 based on a user’s need to know, and
is set to “deny all” unless specifically
allowed. This access control system
must include the following:
7.2.1 Coverage of all system components.
Assignment of privileges to
7.2.2 individuals based on job
classification and function.
Default “deny-all” setting.
based on job classification and function (also called
2.1 Requirements
“role-based access control” or RBAC).
Confirm that documented approval by authorized
parties is required (in writing or electronically) for all    
access, and that it must specify required privileges.
Confirm that access controls are implemented via an
   
automated access control system.
Examine system settings and vendor documentation
to verify that an access control system is implemented    
as follows:
Confirm that access control systems are in place on all
   
system components.
Confirm that access control systems are configured to
enforce privileges assigned to individuals based on    
job classification and function.

Note: Some access control systems

Confirm that the access control systems have a Requirements Establish Security
7.2.3 are set by default to “allow-all,”
default “deny-all” setting. 2.1 Requirements
thereby permitting access
unless/until a rule is written to
specifically deny it.
The Microsoft SDL focuses on application
Requirement 8: Assign a unique ID to each person with computer access development security. Although authentication
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely requirements should be established in
accountable for his or her actions. When such accountability is in place, actions taken on critical data and Requirements and Verified, SLD practices do not
systems are performed by, and can be traced to, known and authorized users. align with most of the PCI-DSS or PA-DSS post-
deployment requirements

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

SDL and PCI 41

minimizing the impact of a data compromise. The presence of logs in all environments allows thorough
of deployed systems is not addressed in SDL
tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is
practices.
very difficult without system activity logs.
Requirement 11: Regularly test security systems and processes
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components,
processes, and custom software should be tested frequently to verify security controls continue to reflect a changing environment.

SDL and PCI 42

 11.1.a Verify that the entity has a documented process
to detect and identify wireless access points on a
quarterly basis.
11.1.b Verify that the methodology is adequate to
Test for the presence of wireless
detect and identify any unauthorized wireless access
access points and detect
points, including at least the following:
unauthorized wireless access points
 WLAN cards inserted into system components
on a quarterly basis.    
 Portable wireless devices connected to system
Note: Methods that may be used in
components (for example, by USB, etc.)
the process include but are not
 Wireless devices attached to a network port or
limited to wireless network scans,
11.1 network device
physical/logical inspections of system
11.1.c Verify that the documented process to identify
components and infrastructure,
unauthorized wireless access points is performed at
network access control (NAC), or    
least quarterly for all system components and
wireless IDS/IPS. Whichever methods
facilities.
are used, they must be sufficient to
11.1.d If automated monitoring is utilized (for
detect and identify any unauthorized
example, wireless IDS/IPS, NAC, etc.), verify the
devices.
configuration will generate alerts to personnel.
11.1.e Verify the organization’s incident response plan
(Requirement 12.9) includes a response in the event
unauthorized wireless devices are detected.
11.2 Run internal and external network Verify that internal and external vulnerability scans are
vulnerability scans at least quarterly performed as follows:
and after any significant change in
the
network (such as new system
component installations, changes in
network topology, firewall rule
modifications, product upgrades).
Note: It is not required that four
passing quarterly scans must be
completed for initial PCI DSS
compliance if the assessor verifies 1)
the most recent scan result was a
passing scan, 2) the entity has
documented policies and procedures
requiring quarterly scanning, and 3)

SDL and PCI 43

 vulnerabilities noted in the scan
results have been corrected as shown
in a rescan. For subsequent years
after the initial PCI DSS review, four
passing quarterly scans must have
occurred.
11.2.1 Perform quarterly internal
vulnerability scans.
Perform quarterly external
vulnerability scans via an Approved
Scanning Vendor (ASV), approved by
the Payment Card Industry Security
Standards Council (PCI SSC).
Note: Quarterly external
vulnerability
11.2.2
scans must be performed by an
Approved Scanning Vendor (ASV),
approved by the Payment Card
Industry Security Standards Council
(PCI SSC). Scans conducted after
network changes may be performed
by internal staff.
11.2.3 Perform internal and external scans
after any significant change.
Note: Scans conducted after changes
may be performed by internal staff.
SDL and PCI
11.2.1.a Review the scan reports and verify that four
quarterly internal scans occurred in the most recent
12-month period.
11.2.1.b Review the scan reports and verify that the
scan process includes rescans until passing results are
obtained, or all “High” vulnerabilities as defined in PCI    
DSS Requirement 6.2 are resolved.
11.2.1.c Validate that the scan was performed by a
qualified internal resource(s) or qualified external third
party, and if applicable, organizational independence
of the tester exists (not required to be a QSA or ASV).
11.2.2.a Review output from the four most recent
quarters of external vulnerability scans and verify that
   
four quarterly scans occurred in the most recent 12-
month period.
11.2.2.b Review the results of each quarterly scan to
ensure that they satisfy the ASV Program Guide Requirements
Create Quality Gates/Bug Bars
requirements (for example, no vulnerabilities rated 2.2
higher than a 4.0 by the CVSS and no automatic
failures).
11.2.2.c Review the scan reports to verify that the
scans were completed by an Approved Scanning
Vendor (ASV), approved by the PCI SSC.
11.2.3.a Inspect change control documentation and    
scan reports to verify that system components subject
to any significant change were scanned.
11.2.3.b Review scan reports and verify that the scan
process includes rescans until:
44

Perform external and internal
penetration testing at least once a
year and after any significant
infrastructure or application upgrade
or modification (such as an
11.3 operating system upgrade, a sub-
network added to the environment,
or a web server added to the
environment). These penetration
tests must include the
following:
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests
11.4 Use intrusion-detection systems,
and/or intrusion-prevention systems
to monitor all traffic at the perimeter
of the cardholder data environment
as well as at critical points inside of
the cardholder data environment,
and alert personnel to suspected
compromises. Keep all intrusion-
detection and prevention engines,
baselines, and signatures up-to-date.
SDL and PCI
 For external scans, no vulnerabilities exist that are
scored greater than a 4.0 by the CVSS,
 For internal scans, a passing result is obtained or
all “High” vulnerabilities as defined in PCI DSS
Requirement 6.2 are resolved.
11.2.3.c Validate that the scan was performed by a
qualified internal resource(s) or qualified external third
party, and if applicable, organizational independence
of the tester exists (not required to be a QSA or ASV).
11.3.a Obtain and examine the results from the most
recent penetration test to verify that penetration
testing is performed at least annually and after any
significant changes to the environment.
11.3.b Verify that noted exploitable vulnerabilities
were corrected and testing repeated.
11.3.c Verify that the test was performed by a    
qualified internal resource or qualified external third
party, and if applicable, organizational independence
of the tester exists (not required to be a QSA or ASV).
Verify that the penetration test includes network layer
penetration tests. These tests should include
   
components that support network functions as well as
operating systems.
Verify that the penetration test includes application-  
Perform Dynamic Code
layer penetration tests. The tests should include, at a Verification 5.1
Analysis
minimum, the vulnerabilities listed in Requirement 6.5.
Verification 5.2 Perform Fuzz Testing
11.4.a Verify the use of intrusion-detection systems
and/or intrusion-prevention systems and that all
traffic at the perimeter of the cardholder data
environment as well as at critical points in the
cardholder data environment is monitored.
11.4.b Confirm IDS and/or IPS are configured to alert
personnel of suspected compromises.
11.4.c Examine IDS/IPS configurations and confirm    
IDS/IPS devices are configured, maintained, and
updated per vendor instructions to verify optimal
45

Deploy file-integrity monitoring
tools to alert personnel to
unauthorized modification of critical
system files, configuration files, or
content files; and configure the tools
to perform critical file comparisons
at least weekly.
Note: For file-integrity monitoring
purposes, critical files are usually
11.5 those that do not regularly change,
but the modification of which could
indicate a system compromise or
risk of compromise. File-integrity
monitoring products usually come
pre-configured with critical files for
the related operating system. Other
critical files, such as those for custom
applications, must be evaluated and
defined by the entity (that is, the
merchant or service provider).
Requirement 12: Maintain a policy that addresses information security for all personnel
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the
sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees,
temporary employees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environment.
Establish, publish, maintain, and
12.1 disseminate a security policy that
accomplishes the following:
12.1.1 Addresses all PCI DSS requirements.
12.1.2 Includes an annual process that
identifies threats, and vulnerabilities,
and results in a formal risk
assessment.
(Examples of risk assessment
methodologies include but are not
protection.
11.5.a Verify the use of file-integrity monitoring tools
within the cardholder data environment by observing
system settings and monitored files, as well as
reviewing results from monitoring activities. Examples
of files that should be monitored:
a) System executables
b) Application executables
c) Configuration and parameter files
d) Centrally stored, historical or archived, log and
audit files    
11.5.b Verify the tools are configured to alert
personnel to unauthorized modification of critical
files, and to perform critical file comparisons at least
weekly.
Examine the information security policy and verify
that the policy is published and disseminated to all
relevant personnel (including vendors, contractors,
and business partners).
Verify that the policy addresses all PCI DSS
   
requirements.
12.1.2.a Verify that an annual risk assessment process    
is documented that identifies threats, vulnerabilities, Requirements Perform Security and Risk
and results in a formal risk assessment. 2.3 Assessment
12.1.2.b Review risk assessment documentation to
verify that the risk assessment process is performed
at least annually.

SDL and PCI 46

 limited to OCTAVE, ISO 27005 and
Verify that the information security policy is reviewed
Includes a review at least annually
at least annually and updated as needed to reflect
12.1.3 and updates when the environment Design 3.3 Complete Threat Models
changes to business objectives or the risk
changes.
environment.
Develop daily operational security
procedures that are consistent
Examine the daily operational security procedures.
with requirements in this
Verify that they are consistent with this specification,
12.2 specification (for example, user    
and include administrative and technical procedures
account
for each of the requirements.
maintenance procedures, and log
review procedures).
Develop usage policies for critical
technologies (for example, remote
access technologies, wireless
technologies, removable electronic
media, laptops, tablets, personal Obtain and examine the usage policies for critical
12.3    
data/digital assistants (PDAs), e-mail technologies and perform the following:
usage and Internet usage) and define
proper use of these technologies.
Ensure these usage policies require
the following:
Explicit approval by authorized Verify that the usage policies require explicit approval
12.3.1    
parties from authorized parties to use the technologies.
Authentication for use of the Verify that the usage policies require that all
technology. technology use be authenticated with user ID and
12.3.2    
password or other authentication item (for example,
token).
A list of all such devices and Verify that the usage policies require a list of all
12.3.3    
personnel with access. devices and personnel authorized to use the devices.
Labeling of devices to determine Verify that the usage policies require labeling of    
12.3.4 owner, contact information and devices with information that can be correlated to
purpose owner, contact information and purpose.
Verify that the usage policies require acceptable uses
12.3.5 Acceptable uses of the technology.    
for the technology.
Acceptable network locations for the Verify that the usage policies require acceptable
12.3.6    
technologies. network locations for the technology.

SDL and PCI 47


12.3.7 List of company-approved products.
Automatic disconnect of sessions for
12.3.8 remote-access technologies after a
specific period of inactivity.
Activation of remote-access
technologies for vendors and
business
partners only when needed by
12.3.9
vendors
and business partners, with
immediate
deactivation after use
For personnel accessing cardholder
data via remote-access technologies,
prohibit copy, move, and storage of
12.3.10 cardholder data onto local hard
drives and removable electronic
media, unless explicitly authorized for
a defined business need.
Verify that the security policy and
procedures clearly define information
12.4
security responsibilities for all
personnel.
Assign to an individual or team the
12.5 following information security
management responsibilities:
Establish, document, and distribute
12.5.1
security policies and procedures.
Monitor and analyze security alerts
12.5.2 and information, and distribute to
appropriate personnel.
SDL and PCI
Verify that the usage policies require a list of
   
company-approved products.
Verify that the usage policies require automatic
disconnect of sessions for remote-access    
technologies after a specific period of inactivity.
Verify that the usage policies require activation of
remote-access technologies used by vendors and
business partners only when needed by vendors and    
business partners, with immediate deactivation after
use.
12.3.10.a Verify that the usage policies prohibit
copying, moving, or storing of cardholder data onto
local hard drives and removable electronic media
when accessing such data via remote-access
technologies.    
12.3.10.b For personnel with proper authorization,
verify that usage policies require the protection of
cardholder data in accordance with PCI DSS
Requirements.
Verify that information security policies clearly define
   
information security responsibilities for all personnel.
Verify the formal assignment of information security
to a Chief Security Officer or other security-
knowledgeable member of management. Obtain and
   
examine information security policies and procedures
to verify that the following information security
responsibilities are specifically and formally assigned:
Verify that responsibility for creating and distributing Requirements
Assign Security Experts
security policies and procedures is formally assigned. 2.1.1
Verify that responsibility for monitoring and
analyzing security alerts and distributing information Requirements
Assign Security Experts
to appropriate information security and business unit 2.1.1
management personnel is formally assigned.
48
 Establish, document, and distribute
security incident response and
12.5.3 escalation procedures to verify timely
and effective handling of all
situations.
Administer user accounts, including
12.5.4 additions, deletions, and
modifications
Monitor and control all access to
12.5.5
data.
SDL and PCI
Verify that responsibility for creating and distributing
Requirements
security incident response and escalation procedures Assign Security Experts
2.1.1
is formally assigned.
Verify that responsibility for administering user
Create an Incident Response
account and authentication management is formally Release 6.1
Plan
assigned.
Verify that responsibility for monitoring and
   
controlling all access to data is formally assigned.
49

Implement a formal security
awareness program to make all
12.6
personnel aware of the importance of
cardholder data security.
Educate personnel upon hire and at
least annually.
12.6.1 Note: Methods can vary depending on
the role of the personnel and their
level of access to the cardholder data.
Require personnel to acknowledge at
least annually that they have read
12.6.2
and understood the security policy
and procedures.
Screen potential personnel prior to
hire to minimize the risk of attacks
from internal sources. (Examples of
background checks include previous
employment history, criminal record,
credit history, and reference checks.)
12.7 Note: For those potential personnel to
be hired for certain positions such as
store cashiers who only have access to
one card number at a time when
facilitating a transaction, this
requirement is a recommendation
only.
If cardholder data is shared with
service providers, maintain and
implement policies and procedures
12.8
to
manage service providers, to include
the following:
SDL and PCI
12.6.a Verify the existence of a formal security
   
awareness program for all personnel.
12.6.b Obtain and examine security awareness
Complete Core Security
program procedures and documentation and Training 1.1
Training
perform the following:
12.6.1.a Verify that the security awareness program
provides multiple methods of communicating
awareness and educating personnel (for example,    
posters, letters, memos, web based training,
meetings, and promotions).
12.6.1.b Verify that personnel attend awareness
training upon hire and at least annually.
Verify that the security awareness program requires
personnel to acknowledge, in writing or
   
electronically, at least annually that they have read
and understand the information security policy.
Inquire with Human Resource department
management and verify that background checks are
conducted (within the constraints of local laws) on
   
potential personnel prior to hire who will have access
to cardholder data or the cardholder data
environment.
If the entity being assessed shares cardholder data
with service providers (for example, back-up tape
storage facilities, managed service providers such as
Web hosting companies or security service providers,
   
or those that receive data for fraud modeling
purposes), through observation, review of policies
and procedures, and review of supporting
documentation, perform the following:
50
12.8.1 Maintain a list of service providers.
Maintain a written agreement that
includes an acknowledgement that
12.8.2 the service providers are responsible
for the security of cardholder data
the service providers possess.
Verify there is an established process
for engaging service providers
12.8.3
including proper due diligence prior
to engagement.
Maintain a program to monitor
12.8.4 service providers’ PCI DSS
compliance status at least annually.
Implement an incident response plan.
12.9 Be prepared to respond immediately
to a system breach.
12.9.1 Create the incident response plan to
be implemented in the event of
system breach. Ensure the plan
addresses the following, at a
minimum:
 Roles, responsibilities, and
communication and contact
strategies in the event of a
compromise including
notification of the payment
brands, at a minimum
 Specific incident response
procedures
 Business recovery and continuity
procedures
 Data back-up processes
 Analysis of legal requirements
for reporting compromises
 Coverage and responses of all
critical system components
 Reference or inclusion of
incident response procedures
SDL and PCI
Verify that a list of service providers is maintained.    
Verify that the written agreement includes an
acknowledgement by the service providers of their    
responsibility for securing cardholder data.
Verify that policies and procedures are documented
and were followed including proper due diligence    
prior to engaging any service provider.
Verify that the entity maintains a program to monitor
its service providers’ PCI DSS compliance status at    
least annually.
 
Obtain and examine the Incident Response Plan and  
Create an Incident Response
related procedures and perform the following: Release 6.1
Plan
12.9.1.a Verify that the incident response plan Release 6.1 Create an Incident Response
includes: Plan
 Roles, responsibilities, and communication
strategies in the event of a compromise
including notification of the payment brands, at
a minimum:
 Specific incident response procedures
 Business recovery and continuity procedures
 Data back-up processes
 Analysis of legal requirements for reporting
compromises (for example, California Bill 1386
which requires notification of affected
consumers in the event of an actual or suspected
compromise for any business with California
residents in their database)
 Coverage and responses for all critical system
components
 Reference or inclusion of incident response
procedures from the payment brands
12.9.1.b Review documentation from a previously
reported incident or alert to verify that the
documented incident response plan and procedures
51
 were followed.
from the payment brands

SDL and PCI 52


12.9.2 Test the plan at least annually.
Designate specific personnel to be
12.9.3 available on a 24/7 basis to respond
to alerts.
Provide appropriate training to staff
12.9.4 with security breach response
responsibilities.
Include alerts from intrusion
12.9.5 detection, intrusion-prevention, and
file-integrity monitoring systems.
Develop a process to modify and
evolve the incident response plan
12.9.6
according to lessons learned and to
incorporate industry developments.
SDL and PCI
Create an Incident Response
Verify that the plan is tested at least annually. Release 6.1
Plan
Verify through observation and review of policies,
that designated personnel are available for 24/7
incident response and monitoring coverage for any
evidence of unauthorized activity, detection of    
unauthorized wireless access points, critical IDS alerts,
and/or reports of unauthorized critical system or
content file changes.
Verify through observation and review of policies that
Create an Incident Response
staff with security breach responsibilities are Release 6.1
Plan
periodically trained.
Verify through observation and review of processes
that monitoring and responding to alerts from
Complete Core Security
security systems including detection of unauthorized Training 1.1
Training
wireless access points are covered in the Incident
Response Plan.
Verify through observation and review of policies that
there is a process to modify and evolve the incident
   
response plan according to lessons learned and to
incorporate industry developments.
53
APPENDIX B: PA-DSS REQUIREMENTS MAPPED TO THE SDL PRACTICES (PULL-OUT)
PA-DSS Requirement
1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
Do not store sensitive authentication
data after authorization (even if
encrypted): Sensitive authentication data
includes the data as cited in the
following Requirements 1.1.1 through
1.1.3.
Note: By prohibiting storage of sensitive
authentication data after authorization,
1.1
the assumption is that the transaction
has completed the authorization process
and the customer has received the final
transaction approval. After authorization
has completed, this sensitive
authentication data cannot be stored.
Aligns with PCI Data Security
Standard Requirement 3.2
After authorization, do not store the full (commercial tools, scripts, etc.)4 to examine
contents of any track from the magnetic
stripe (located on the back of a card,
contained in a chip, or elsewhere). This
data is alternatively called full track,
track, track 1, track 2, and magnetic-
stripe data. In the normal course of
business, the following data elements
1.1.1
from the magnetic stripe may need to be - Incoming transaction data
retained: The accountholder’s name,
primary account number (PAN),
Expiration date, and Service code. To
minimize risk, store only those data
elements needed for business. Aligns
with PCI Data Security Standard
Requirement 3.2.1
SDL and PCI
Testing Procedures SDL Practice SDL Practice
If sensitive authentication data (see 1.1.1–1.1.3
below) is stored prior to authorization and Establish Security Requirements
then deleted, obtain and review methodology Perform Security & Privacy Risk
for deleting the data to determine that the Requirements 2.1 Assessment
data is unrecoverable. For each item of Requirements 2.3 Perform Periodic Static Code
sensitive authentication data below, perform Implementation 4.3 Analysis
the following steps after completing Verification 5.0- Verification Practices
numerous test transactions that simulate all Verification 5.3 -Perform Dynamic Code Analysis
functions of the payment application, to -Perform Fuzz Testing
include generation of error conditions and log -Conduct Attack Surface Review
entries.
Use forensic tools and/or methods
all output created by the payment application
and verify that the full contents of any track
from the magnetic stripe on the back of the
Establish Security Requirements
card are not stored after authorization.
Perform Security & Privacy Risk
Include the following types of files (as well as
Requirements 2.1 Assessment
any other output generated by the payment
Requirements 2.3 Perform Periodic Static Code
application):
Implementation 4.3 Analysis
Verification 5.0- Verification Practices
- All logs (for example, transaction, history,
Verification 5.3 -Perform Dynamic Code Analysis
debugging, error)
-Perform Fuzz Testing
- History files
-Conduct Attack Surface Review
- Trace files
- Non-volatile memory, including non-volatile
cache
- Database schemas
- Database contents
54

After authorization, do not store the card
validation value or code (three-digit or
four-digit number printed on the front
1.1.2 or back of a payment card) used to verify
card-not-present transactions. Aligns
with PCI Data Security Standard
Requirement 3.2.2
After authorization, do not store the
personal identification number (PIN) or
1.1.3 the encrypted PIN block. Aligns with
PCI Data Security Standard
Requirement 3.2.3
Securely delete any magnetic stripe data,
1.1.4
card validation values or codes, and PINs
SDL and PCI
Use forensic tools and/or methods
(commercial tools, scripts, etc.) to examine all
output created by the payment application
and verify that the three-digit or four-digit
card validation code printed on the front of
the card or the signature panel (CVV2, CVC2, Establish Security Requirements
CID, CAV2 data) is not stored after Perform Security & Privacy Risk
authorization. Include the following types of Requirements 2.1 Assessment
files (as well as any other output generated by Requirements 2.3 Perform Periodic Static Code
the payment application): Implementation 4.3 Analysis
- Incoming transaction data Verification 5.0- Verification Practices
- All logs (for example, transaction, history, Verification 5.3 -Perform Dynamic Code Analysis
debugging, error) -Perform Fuzz Testing
- History files -Conduct Attack Surface Review
- Trace files
- Non-volatile memory, including non-volatile
cache
- Database schemas
- Database contents
Use forensic tools and/or methods
(commercial tools scripts, etc.) to examine all
output created by the payment application,
and verify that PINs and encrypted PIN blocks
are not stored after authorization. Include the Establish Security Requirements
following types of files (as well as any other Perform Security & Privacy Risk
output generated by the payment Requirements 2.1 Assessment
application): Requirements 2.3 Perform Periodic Static Code
- Incoming transaction data Implementation 4.3 Analysis
- All logs (for example, transaction, history, Verification 5.0- Verification Practices
debugging, error) Verification 5.3 -Perform Dynamic Code Analysis
- History files -Perform Fuzz Testing
- Trace files -Conduct Attack Surface Review
- Non-volatile memory, including non-volatile
cache
- Database schemas
- Database contents
1.1.4.a Review the PA-DSS Implementation Requirements 2.1 Establish Security Requirements
Guide prepared by the vendor and verify the Requirements 2.3 Perform Security & Privacy Risk
55

or PIN block data stored by previous
versions of the payment application, in
accordance with industry accepted
standards for secure deletion, as defined,
for example by the list of approved
products maintained by the National
Security Agency, or by other State or
National standards or regulations. Aligns
with PCI Data Security Standard
Requirement 3.2 Note: This
requirement only applies if previous
versions of the payment application
stored sensitive authentication data.
Securely delete any sensitive
authentication data (pre-authorization
data) used for debugging
or troubleshooting purposes from log
files, debugging files, and other data
sources received from customers, to
verify that magnetic stripe data, card
validation codes or values, and PINs or
1.1.5
PIN block data are not stored on
software vendor systems. These data
sources must be collected in limited
amounts and only when necessary to
resolve a problem, encrypted while
stored, and deleted immediately after
use. Aligns with PCI Data Security
Standard Requirement 3.2
SDL and PCI
documentation includes the following
instructions for customers and
resellers/integrators:
- That historical data must be removed
(magnetic stripe data, card validation codes,
Assessment
PINs, or PIN blocks stored by previous
versions of the payment application)
- How to remove historical data
- That such removal is absolutely necessary
for PCI DSS compliance
Establish Security Requirements
1.1.4.b Verify the vendor provides a secure Requirements 2.1
Perform Security & Privacy Risk
wipe tool or procedure to remove the data. Requirements 2.3
Assessment
1.1.4.c Verify, through the use of forensic tools
and/or methods, that the secure wipe tool or
Establish Security Requirements
procedure provided by vendor securely Requirements 2.1
Perform Security & Privacy Risk
removes the data, in accordance with Requirements 2.3
Assessment
industry-accepted standards for secure
deletion of data.
1.1.5.a Examine the software vendor’s
procedures for troubleshooting customers’
problems and verify the procedures include:
- Collection of sensitive authentication data
only when needed to solve a specific problem.
- Storage of such data in a specific, known Establish Security Requirements
Requirements 2.1
location with limited access. Perform Security & Privacy Risk
Requirements 2.3
- Collection of only a limited amount of data Assessment
needed to solve a specific problem.
- Encryption of sensitive authentication data
while stored.
- Secure deletion of such data immediately
after use.
1.1.5.b Select a sample of recent
troubleshooting requests from customers, and Perform Security & Privacy Risk
Requirements 2.3
verify each event followed the procedure Assessment
examined at 1.1.5.a.
1.1.5.c Review the PA-DSS Implementation
Guide prepared by the vendor and verify the
56

2. Protect stored cardholder data
Software vendor must provide guidance
to customers regarding purging of
cardholder data after expiration of
2.1
customer-defined retention period.
Aligns with PCI Data Security
Standard Requirement 3.1
Mask PAN when displayed (the first six
and last four digits are the maximum
number of digits to be displayed). - This
requirement does not apply to those
employees and other parties with a
legitimate business need to see full PAN.
2.2
- This requirement does not supersede
stricter requirements in place for displays
of cardholder data—for example, for
point-of-sale (POS) receipts. Aligns with
PCI Data Security Standard
Requirement 3.3
SDL and PCI
documentation includes the following
instructions for customers and
resellers/integrators:
- Collect sensitive authentication only when
needed to solve a specific problem.
- Store such data only in specific, known
locations with limited access.
- Collect only the limited amount of data
needed to solve a specific problem.
- Encrypt sensitive authentication data while
stored.
- Securely delete such data immediately after
use.
Review the PA-DSS Implementation Guide
prepared by the vendor and verify the
documentation includes the following
guidance for customers and
resellers/integrators:
- That cardholder data exceeding the
   
customer-defined retention period must be
purged.
- A list of all locations where the payment
application stores cardholder data (so that
customer knows the locations of data that
needs to be deleted).
Review displays of credit card data, including
but not limited to POS devices, screens, logs,
and receipts, to determine that credit card
numbers are masked when displaying    
cardholder data, except for those with a
legitimate business need to see full credit
card numbers.
57
 Render PAN, at a minimum, unreadable 2.3.a Verify that the PAN is rendered
Satisfy Minimum Cryptographic
anywhere it is stored, (including data on unreadable anywhere it is stored, in Design 3.1.3
Design Requirements
portable digital media, backup media, accordance with PCI DSS Requirement 3.4.
and in logs) by using any of the
following approaches:
- One-way hashes based on strong
cryptography
- Truncation
- Index tokens and pads (pads must be
2.3.b If the software vendor stores the PAN for
securely stored)
any reason (for example, because log files,
2.3 - Strong cryptography with associated
debugging files, and other data sources are
key management processes and Satisfy Minimum Cryptographic
received from customers for debugging or Design 3.1.3
procedures. Design Requirements
troubleshooting purposes), verify that the
The MINIMUM account information that
PAN is rendered unreadable in accordance
must be rendered unreadable is the
with PCI DSS Requirement 3.4.
PAN.
Aligns with PCI Data Security
Standard Requirement 3.4
The PAN must be rendered unreadable
anywhere it is stored, even outside the
payment application.
If disk encryption is used (rather than
file- or column-level database
encryption), logical access must be
managed independently of native
If disk encryption is used, verify that it is
operating system access control Satisfy Minimum Cryptographic
2.4 implemented in accordance with PCI DSS Design 3.1.3
mechanisms (for example, by not using Design Requirements
Requirements 3.4.1.a through 3.4.1.c.
local user account databases).
Decryption keys must not be tied to user
accounts. Aligns with PCI Data Security
Standard Requirement 3.4.1
Payment application must protect
cryptographic keys used for encryption Verify the payment application protects keys
Satisfy Minimum Cryptographic
2.5 of cardholder data against disclosure against disclosure and misuse, per PCI DSS Design 3.1.3
Design Requirements
and misuse. Aligns with PCI Data requirement 3.5.1 and 3.5.2.
Security Standard Requirement 3.5

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

SDL and PCI 58

 procedures for cryptographic keys used
for encryption of cardholder data. Aligns
with PCI Data Security Standard
Requirement 3.6
Securely delete any cryptographic key
material or cryptogram stored by
previous versions of the payment
application, in accordance with industry-
accepted standards for secure deletion,
as defined, for example the list of
approved products maintained by the
National Security Agency, or by other
State or National standards or
2.7
regulations. These are cryptographic
keys used to encrypt or verify cardholder
data. Aligns with PCI Data Security
Standard Requirement 3.6
Note: This requirement only applies if
previous versions of the payment
application used cryptographic key
materials or cryptograms to encrypt
cardholder data.
3. Provide secure authentication features
SDL and PCI
DSS Requirements 3.6.1 through 3.6.8.
2.7.a Review the PA-DSS Implementation
Guide prepared by the vendor and verify the
documentation includes the following
instructions for customers and
resellers/integrators:
- That cryptographic material must be Satisfy Minimum Cryptographic
Design 3.1.3
removed Design Requirements
- How to remove cryptographic material
- That such removal is absolutely necessary
for PCI DSS compliance
- How to re-encrypt historic data with new
keys
2.7.b Verify vendor provides a secure wipe
Satisfy Minimum Cryptographic
tool or procedure to remove cryptographic Design 3.1.3
Design Requirements
material.
2.7.c Verify, through use of forensic tools
and/or methods, that the secure wipe tool or
procedure securely removes the Satisfy Minimum Cryptographic
Design 3.1.3
cryptographic material, in accordance with Design Requirements
industry-accepted standards for secure
deletion of data.
The Microsoft SDL focuses on application development
security. Although authentication requirements should
be established in the Requirements and Verification
Phases, SLD practices do not align with most of the PCI-
DSS or PA-DSS post-deployment requirements
59

The “out-of-the-box” installation of
the payment application in place at
the completion of the installation
process, must facilitate use of unique
user IDs and secure authentication
(defined at PCI DSS Requirements 8.1,
8.2, and 8.5.8–8.5.15) for all
administrative access and for all
access to cardholder data. Aligns
with PCI Data Security Standard
Requirements 8.1, 8.2, and 8.5.8–
8.5.15
3.1
Note: These password controls are not
intended to apply to employees who
only have access to one card number
at a time to facilitate a single
transaction. These controls are
applicable for access by employees
with administrative capabilities, for
access to servers with cardholder data,
and for access controlled by the
payment application. This requirement
applies to the payment application and
all associated tools used to view or
access cardholder data.
SDL and PCI
3.1.a Test the payment application to verify that
unique user IDs and secure authentication are
Establish Security Design
required for all administrative access and for all  Design 3.1
Requirements 
access to cardholder data, in accordance with
PCI DSS Requirements 8.1, 8.2, and 8.5.8–8.5.15.
3.1.b Test the payment application to verify the
payment application does not use (or require the
use of) default administrative accounts for other Establish Security Design
 Design 3.1
necessary software (for example, the payment Requirements 
application must not use the administrative
account for database software).
3.1.c Examine PA-DSS Implementation Guide
created by vendor to verify the following:
- Customers and resellers/integrators are
advised against using default administrative
accounts for payment application logins (for
example, don’t use the “sa” account for payment
application access to the database).
- Customers and resellers/integrators are
advised to assign secure authentication to these
default accounts (even if they won’t be used),
and then disable or do not use the accounts.
- Customers and resellers/integrators are
advised to assign secure authentication for    
payment applications and systems whenever
possible.
- Customers and resellers/integrators are
advised how to create PCI DSS-compliant secure
authentication to access the payment
application, per PCI DSS Requirements 8.5.8
through 8.5.15
- Customers and resellers/integrators are
advised that changing “out of the box”
installation settings for unique user IDs and
secure authentication will result in
noncompliance with PCI DSS.
60
 Examine PA-DSS Implementation Guide created
Access to PCs, servers, and databases
by vendor to verify customers and
with payment applications must
resellers/integrators are strongly advised to
require a unique user ID and secure
3.2 control access, via unique user ID and PCI DSS-    
authentication. Aligns with PCI Data
compliant secure authentication, to any PCs,
Security Standard Requirements 8.1
servers, and databases with payment
and 8.2
applications and cardholder data.
Render payment application
passwords unreadable during
transmission and storage, using
strong cryptography based on
Examine payment application password files
approved standards Note: “Strong
3.3 during storage and transmission to verify that    
cryptography” is defined in PCI DSS
passwords are unreadable at all times.
and PA-DSS Glossary of Terms,
Abbreviations, and Acronyms. Aligns
with PCI Data Security Standard
Requirement 8.4
The Microsoft SDL focuses on application development
4. Log Payment application activity security. Tracking and monitoring of deployed systems
is not addressed in SDL practices.
At the completion of the installation
process, the “out of the box” default
installation of the payment application Examine payment application settings to verify
must log all user access (especially that payment application audit trails are
4.1    
users with administrative privileges), automatically enabled or are available to be
and be able to link all activities to enabled by customers.
individual users. Aligns with PCI Data
Security Standard Requirement 10.1
4.2.a Examine payment application log
Payment application must implement parameters and verify that logs contain the data
Requirements 2.0 Establish Security Requirements
an automated audit trail to track and required in PCI DSS Requirements 10.2.1
monitor access. PCI Data Security through 10.2.7 and 10.3.1 through 10.3.6.
Standard Requirements 10.2 and
4.2.b If payment application log settings are
4.2 10.3Payment application must
configurable by the customer and
implement an automated audit trail to
resellers/integrators, or customers or
track and monitor access. Aligns with    
resellers/integrators are responsible for
PCI Data Security Standard
implementing logging, examine PA-DSS
Requirements 10.2 and 10.3
Implementation Guide prepared by the vendor

SDL and PCI 61


5. Develop secure payment applications
Develop all payment applications in
accordance with PCI DSS (for example,
secure authentication and logging)
and based on industry best practices
and incorporate information security
5.1
throughout the software development
lifecycle. These processes must
include the following:
Aligns with PCI Data Security
Standard Requirement 6.3
Testing of all security patches and
system and software configuration
5.1.1 changes before deployment, including
but not limited to testing for the
following:
Validation of all input (to prevent
5.1.1.1 cross-site scripting, injection flaws,
malicious file execution, etc.).
5.1.1.2 Validation of proper error handling.
Validation of secure cryptographic
5.1.1.3
storage.
5.1.1.4 Validation of secure communications.
Validation of proper role-based access
5.1.1.5
control (RBAC).
Separate development/test, and
5.1.2
product environments.
Separation of duties between
5.1.3 development/test, and production
environments.
SDL and PCI
to verify the following information is included:
- How to set PCI DSS-compliant log settings, per
PCI DSS Requirements 10.2.1 through 10.2.7 and
10.3.1 through 10.3.6
- That disabling of the logs should not be done
and will result in non-compliance with PCI DSS
Obtain and examine written software development
processes to verify that they are based on industry
standards, that security is included throughout the
lifecycle, and that software applications are Verification Practices
developed in accordance with PCI DSS. From an Verification 5.0- -Perform Dynamic Code Analysis
examination of written software development Verification 5.3 -Perform Fuzz Testing
processes, interviews of software developers, and -Conduct Attack Surface Review
examination of relevant data (network
configuration documentation, production and test
data, etc.), verify that:
All security patches and system and software Verification Practices
changes are tested before being deployed, Verification 5.0- -Perform Dynamic Code Analysis
including but not limited to testing for the Verification 5.3 -Perform Fuzz Testing
following: -Conduct Attack Surface Review
Validation of all input (to prevent cross-site
scripting, injection flaws, malicious file execution, Verification 5.1 Perform Dynamic Code Analysis
etc.).
Validation of proper error handling. Verification 5.1 Perform Dynamic Code Analysis
Validation of secure cryptographic storage. Verification 5.1 Perform Dynamic Code Analysis
Validation of secure communications. Verification 5.1 Perform Dynamic Code Analysis
Validation of proper role-based access control
Verification 5.1 Perform Dynamic Code Analysis
(RBAC).
The test/development environments are separate  
from the production environment, with access  
control in place to enforce the separation.
There is a separation of duties between personnel  
assigned to the development/test environments
 
and those assigned to the production
environment.
62
 Live PANs are not used for testing or
5.1.4
development.
Removal of test data and accounts
5.1.5 before production systems become
active.
Removal of custom payment
application accounts, user IDs, and
5.1.6 passwords before payment
applications are released to
customers.
Review of payment application code
prior to release to customers after any
significant change, to identify any
potential coding vulnerability.
Note: This requirement for code
reviews applies to all payment
application components (both internal
5.1.7
and public-facing web applications), as
part of the system development
lifecycle required by PA-DSS
Requirement 5.1 and PCI DSS
Requirement 6.3. Code reviews can be
conducted by knowledgeable internal
personnel or third parties.
SDL and PCI
Live PANs are not used for testing or  
 
development, or are sanitized before use.
 
Test data and accounts are removed before
 
production systems become active.
 
Custom payment application accounts, user IDs,
and passwords are removed before payment  
application is released to customers.
5.1.7.a Confirm the vendor performs code reviews
for all application code changes for internal
applications (either using manual or automated
processes), as follows:
- Code changes are reviewed by individuals other
than the originating code author, and by Design 3.1 Establish Design Requirements
individuals who are knowledgeable in code review Verification 5.3 Conduct Attack Surface Review
techniques and secure coding practices.
- Appropriate corrections are implemented prior
to release.
- Code review results are reviewed and approved
by management prior to release.
5.1.7.b Confirm the vendor performs code reviews
for all application code changes for web
applications (using either manual or automated
processes) as follows:
- Code changes are reviewed by individuals other
than the originating code author, and by
individuals who are knowledgeable in code review
techniques and secure coding practices. Design 3.1 Establish Design Requirements
- Code reviews verify code is developed according Verification 5.3 Conduct Attack Surface Review
to secure coding guidelines such as the Open Web
Security Project Guide. (See PA-DSS Requirement
5.2 and PCI DSS Requirement 6.5.)
- Appropriate corrections are implemented prior
to release.
- Code review results are reviewed and approved
by management prior to release.
63
 Develop all web payment applications (internal and external, and including web
administrative access to product) based on secure coding guidelines such as the Open Web
Application Security Project Guide. Cover prevention of common coding vulnerabilities in
software development processes, to include:
Note: The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.10 and in PCI DSS
5.2
at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published.
However, if and when the OWASP guide is updated, the current version must be used for
these requirements.
Aligns with PCI Data Security Standard Requirement 6.5
 

5.2.1 Cross-site scripting (XSS) (Validate all

5.2.1 Cross Site Scripting (XSS)
parameters before inclusion.)
Injection Flaws, particularly SQL 5.2.2 Injection flaws, particularly SQL injection
5.2.2 injection but including LDAP and (Validate input to verify user data cannot modify
Xpath injection meaning of commands and queries.)
5.2.3 Malicious file execution (Validate input to
5.2.3 Malicious file execution verify application does not accept filenames or Full SDL applies Full SDL applies
files from users.) Design 3.1 Establish Design Requirements
5.2.4 Insecure direct object references (Do not Verification 5.3 Conduct Attack Surface Review
5.2.4 Insecure direct object references
expose internal object references to users.)
5.2.5 Cross-site request forgery (CSRF) (Do not rely
5.2.5 Cross site request forgery (CSRF) on authorization credentials and tokens
automatically submitted by browsers.)
5.2.6 Information leakage and improper error
Information Leakage and improper
5.2.6 handling (Do not leak information via error
error handling
messages or other means.)
5.2.7 Broken authentication and session
Broken authentication and session
5.2.7 management (Properly authenticate users and
management
protect account credentials and session tokens.)
5.2.8 Insecure cryptographic storage (Prevent
5.2.8 Insecure cryptographic storage
cryptographic flaws.)
5.2.9 Insecure communications (Properly encrypt
5.2.9 Insecure communications
all authenticated and sensitive communications.)
5.2.10 Failure to restrict URL access (Consistently
5.2.10 Failure to restrict URL access enforce access control in presentation layer and
business logic for all URLs.)

SDL and PCI 64


Software vendor must follow change
control procedures for all product
software configuration changes. The
5.3 procedures must include the
  following:
Aligns with PCI Data Security
Standard Requirement 6.4
 
5.3.1 Documentation of impact
Management sign-off by appropriate
5.3.2
parties
5.3.3 Testing of operational functionality
Back-out or product de-installation
5.3.4
procedures
The payment application must not use
or require use of unnecessary and
insecure services and protocols (for
5.4 example, NetBIOS, file-sharing, Telnet,
unencrypted FTP, etc.). Aligns with
PCI Data Security Standard
Requirement 2.2.2
6. Protect wireless transmissions
SDL and PCI
5.3.a Obtain and examine the vendor’s change-
control procedures for software modifications, and Establish Security Design
Design 3.1
verify that the procedures require items 5.3.1–5.3.4 Requirements
below.
5.3.b Examine recent payment application
changes, and trace those changes back to related
change control documentation. Verify that, for
Release 6.1 Create an Incident Response Plan
each change examined, the following was
\documented according to the change control
procedures:
Verify that documentation of customer impact is
included in the change control documentation for Release 6.2 Perform a Final Security Review
each change.
Verify that management sign-off by appropriate
Release 6.2 Perform a Final Security Review
parties is present for each change.
Verify that operational functionality testing was
Release 6.2 Perform a Final Security Review
performed for each change.
Verify that back-out or product de-installation  
 
procedures are prepared for each change.
Examine system services, daemons, and protocols  
enabled or required by the payment application.
Verify that unnecessary and insecure services or
protocols are not enabled by default or required  
by the payment application (for example, FTP is
not enabled, or is encrypted via SSH or other
technology).
The Microsoft SDL focuses on application
development security. Although wireless and other
network traffic security can be included in design
requirements, protection of deployed wireless
systems is not addressed.
65
7. Test payment applications to address vulnerabilities
Software vendors must establish a 7.1.a Obtain and examine processes to identify
process to identify newly discovered new vulnerabilities and to test payment
security vulnerabilities (for example, applications for new vulnerabilities. Verify the Verification Practices
subscribe to alert services freely processes include: Verification 5.0- -Perform Dynamic Code Analysis
available on the Internet) and to test - Using outside sources for security vulnerability Verification 5.3 -Perform Fuzz Testing
their payment applications for information -Conduct Attack Surface Review
vulnerabilities. Any underlying - Testing of payment applications for new
7.1
software or systems that are provided vulnerabilities
with or required by the payment 7.1.b Verify that processes to identify new
application (for example, web servers, vulnerabilities and implement corrections into
3rd-party libraries and programs) payment application apply to all software
Release 6.1 Create an Incident Response Plan
must be included in this process. provided with or required by the payment
Aligns with PCI Data Security application (for example, web servers, third-party
Standard Requirement 6.2 libraries and programs).
7.2.a Obtain and examine processes to develop
and deploy security patches and upgrades for
software. Verify the processes include:
Software vendors must establish a - Timely development and deployment of patches
process for timely development and to customers.
deployment of security patches and - Delivery of patches and updates in a secure Release 6.1 Create an Incident Response Plan
upgrades, which includes delivery of manner with a known chain-of-trust.
7.2 updates and patches in a secure - Delivery of patches and updates in a manner that
manner with a known chain-of-trust, maintains the integrity of the deliverable.
and maintenance of the integrity of - Integrity testing of the patch or update by the
patch and update code during target system prior to installation.
delivery and deployment. 7.2.b To verify that the integrity of patch and
update code is maintained, run the update process
Release 6.1 Create an Incident Response Plan
with arbitrary code and determine that the system
will not allow the update to occur.
The Microsoft SDL focuses on application
development. Although SDL practices can be applied,
8. Facilitate secure network implementation
security of a deployed network is not specifically
addressed
The Microsoft SDL focuses on application
9. Cardholder data must never be stored on a server connected to the Internet development. Privacy of cardholder data can be
included in the Privacy Risk assessment, but security

SDL and PCI 66


10. Facilitate secure remote software updates
11. Facilitate secure remote access to payment applications
12. Encrypt sensitive traffic over public networks
If the payment application sends, or
facilitates sending, cardholder data
over public networks, the payment
application must support use of
strong cryptography and security
protocols such as SSL/TLS and
Internet protocol security (IPSEC) to
safeguard sensitive cardholder data
during transmission over open, public
networks. Examples of open, public
12.1
networks that are in scope of the PCI
DSS are:
- The Internet.
- Wireless technologies.
- Global System for Mobile
Communications (GSM).
- General Packet Radio Service (GPRS).
Aligns with PCI Data Security
Standard Requirement 4.1
The payment application must never
send unencrypted PANs by end-user
messaging technologies (for example,
12.2
email, instant messaging, chat). Aligns
with PCI Data Security Standard
Requirement 4.2
SDL and PCI
12.1.a If the payment application sends, or
facilitates sending, cardholder data over public
networks, verify that secure encryption
transmission technology (for example, IPSEC, VPN
or SSL/TLS) is provided, or that use thereof is
specified.
12.1.b If the payment application allows data
transmission over public networks, examine PA-
DSS Implementation Guide prepared by the
vendor, and verify the vendor includes directions
for customers and resellers/integrators to use
secure encryption transmission technology (for
example, IPSEC, VPN or SSL/TLS).
12.2.a If the payment application allows and/or
facilitates sending of PANs by end-user messaging
technologies, verify that a strong cryptography
solution is provided, or that use thereof is
specified.
12.2.b If the payment application allows and/or
facilitates the sending of PANs by end-user
messaging technologies, examine PA-DSS
& privacy of data on a deployed network/application
is not addressed
The Microsoft SDL focuses on application
development. Security of a deployed network or
features of a "live" system are not addressed
The Microsoft SDL focuses on application
development. Security of a deployed network or
features of a "live" system are not addressed
Design 3.1.3 Satisfy Minimum Cryptographic
Design Requirements
Verification 5.3 Conduct Attack Surface Review
Design 3.1.3 Satisfy Minimum Cryptographic
Design Requirements
Verification 5.3 Conduct Attack Surface Review
Design 3.1.3 Satisfy Minimum Cryptographic
Design Requirements
Verification 5.3 Conduct Attack Surface Review
Design 3.1.3 Satisfy Minimum Cryptographic
Design Requirements
Verification 5.3 Conduct Attack Surface Review
67
 Implementation Guide prepared by the vendor,
and verify the vendor includes directions for
customers and resellers/integrators to use a
solution that implements strong cryptography.
13. Encrypt all non-console administrative access
14. Maintain instructional documentation and training programs for customers, resellers, and
integrators
SDL and PCI
The Microsoft SDL focuses on application
development. Security of a deployed network or
features of a "live" system are not addressed
The Microsoft SDL focuses on application
development. Although training is covered in the SDL
Practices, details on training specific to PA-DSS
requirements is not addressed
68
APPENDIX C: MICROSOFT SDL PRACTICES (PULL-OUT)
This information is based on the Microsoft Simplified Implementation of the SDL paper (http://go.microsoft.com/?linkid=9708425). Please read
that document and visit the Microsoft SDL website for further details (http://www.microsoft.com/sdl)

Practice Practice Name Implementation Details Additional Notes

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

Basic software security training should cover foundational concepts

such as:
- Secure design, including the following topics: Attack surface
reduction, Defense in depth, rinciple of least privilege, Secure defaults
- Threat modeling, including the following topics: Overview of threat
modeling, Design implications of a threat model, Coding constraints
based on a threat model
- Secure coding, including the following topics: Buffer overruns (for
applications using C and C++), Integer arithmetic errors (for
applications using C and C++), Cross-site scripting (for managed code
and Web applications), SQL injection (for managed code and Web
applications), Weak cryptography
- Security testing, including the following topics: Differences between
security testing and functional testing, Risk assessment, Security
testing methods
- Privacy, including the following topics: Types of privacy-sensitive
data, Privacy design best practices, Risk assessment, Privacy
development best practices, Privacy testing best practices

Requirements Requirements Practices Setting a designated time for defining project requirements allows  
development teams to consider how to best integrate security and

SDL and PCI 69

2.0 privacy into the development process and identify key security
objectives while minimizing disruption to application usability, plans,
and schedules.

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.

Identify the team or individual that is responsible for tracking and

managing security for the product. This team or individual does not
have sole responsibility for ensuring that a software release is secure,
but this team or individual is responsible for coordinating and
communicating the status of any security issues in the product.

In smaller product groups, a single person may fill these roles.

SDL and PCI 70

Requirements Define Minimum Security Establish the minimum security requirements for the application as it is  
2.1.2 Criteria designed to run in its planned operational environment.

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).

A process should be defined to regulate the approval of exceptions to

the Quality Gate/Bug Bar throughout the lifecycle of your 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.

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

SDL and PCI 71

 before release?
• (Security) Which portions of the project will require security design
reviews before release?
• (Security) Which portions of the project (if any) will require
penetration testing by a mutually agreed upon group that is external
to the project team?
• (Security) Are there any additional testing or analysis requirements
the security advisor deems necessary to mitigate security risks?
• (Security) What is the specific scope of the fuzz testing requirements?
• (Privacy) What is the Privacy Impact Rating? The answer to this
question is based on the following guidelines:

P1 High Privacy Risk: The feature, product, or service stores or

transfers PII, changes settings or file type associations, or installs
software.
P2 Moderate Privacy Risk: The sole behavior that affects privacy in
the feature, product, or service is a one-time, user-initiated,
anonymous data transfer (for example, the user clicks on a link and the
software goes out to a Web site).
P3 Low Privacy Risk: No behaviors exist within the feature, product,
or service that affect privacy. No anonymous or personal data is
transferred, no PII is stored on the machine, no settings are changed
on the user's behalf, and no software is installed.

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

SDL and PCI 72

 addition, all design specifications should describe how to securely
implement all functionality provided by a given feature or function. It’s
a good practice to validate design specifications against the
application’s functional specification. The functional specification
should:
• Accurately and completely describe the intended use of a feature or
function.
• Describe how to deploy the feature or function in a secure fashion.

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

SDL and PCI 73

Design 3.1.3 Satisfy minimum Satisfy the minimal cryptographic design requirements established for your The SDL crypto requirements, at a high-level,
cryptographic design product when you established Security Requirements. are:
requirements
Use AES for symmetric
encryption/decryption
Use 128-bit or better symmetric keys
Use RSA for asymmetric
encryption/decryption and signatures
Use 1024-bit or better RSA keys
Use SHA-256 or better for hashing and
message authentication codes

For additional details on this requirement,

please read through the online SDL Process
Guidance available at:
http://msdn.microsoft.com/en-
us/security/cc420639.aspx

SDL and PCI 74

Design 3.2 Analyze Attack Surface 1. Use Code Access Secuirty (CAS) correctly
2. Manage firewall exceptions carefully
3. Ensure your application runs correctly as a non-administrator
1. Use Code Access Secuirty (CAS) correctly:
When developing with managed code, use
strong-named assemblies and request
minimal permission. When using strong-
named assemblies, do not use APTCA (Allow
Partially Trusted Caller Attribute) unless the
assembly was approved by a security review.
2. Manage firewall exceptions carefully: Be
logical and consistent when you make
firewall exceptions. Any product or
component that requires changes to the
host firewall settings must adhere to the
requirements that are outlined in the "Policy
for Managing Firewall Configurations."
document, available at
http://msdn.microsoft.com/en-
us/library/cc307394.aspx.
3. Ensure your application runs correctly as a
non-administrator: following the
requirement will enable teams to design and
develop their applications with a standard
user in mind. This will result in reducing
attack surface exposed by applications,
increasing the security of the user and
system.

SDL and PCI 75

Design 3.3 Complete Threat Models 1. Complete threat models for all functionality identified during the cost For more information on Threat Modeling:
analysis phase. Threat models typically must consider the following areas: http://www.microsoft.com/security/sdl/resou
- All projects. All code exposed on the attack surface and all code written by or rces/publications.aspx
licensed from a third party.
- New projects. All features and functionality.
- Updated versions of existing projects. New features or functionality added in
the updated version.

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.

3. Have all threat models and referenced mitigations reviewed and

approved by at least one developer, one tester, and one program
manager. Ask architects, developers, testers, program managers, and others
who understand the software to contribute to threat models and to review
them. Solicit broad input and reviews to ensure the threat models are as
comprehensive as possible.

4. Threat model data and associated documentation (functional/design

specs) should be stored using the document control system used by the
product team.

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.

SDL and PCI 76

Implementation Specify/Approve secure All development teams should define and publish a list of approved tools A list of Microsoft's SDL-related
4.1 compilers, tools, flags & and their associated security checks, such as compiler/linker options and Implementation tools can be found at:
options warnings. This list should be approved by the security advisor for the project http://www.microsoft.com/security/sdl/getstart
team. Generally speaking, development teams should strive to use the latest ed/tools.aspx.
version of approved tools to take advantage of new security analysis
functionality and protections. The SDL ProNetwork Tools partners can be
accessed at:
http://www.microsoft.com/security/sdl/getstart
ed/pronetwork.aspx

Use the currently required (or later) versions of

compilers to compile options for the Win32,
Win64, WinCE and Macintosh target platforms.
- Compile C/C++ code with /GS or approved
alternative on other platforms. The "SDL Buffer
Security Check" check-in policy provided with
this template helps you enforce this in your
project.
- Link C/C++ code with /SAFESEH or approved
alternative on other platforms. The "SDL Safe
Exception Handlers" check-in policy provided
with this template helps you enforce this in
your project.
- Link C/C++ code with /NXCOMPAT or
approved alternative on other platforms. The
"SDL DEP and ASLR" check-in policy provided
with this template helps you enforce this in
your project.
- Use MIDL with /robust or approved
alternative on other platforms.

SDL and PCI 77

 Use the currently required (or later) versions of
code analysis tools for either native C and C++
or managed (C#) code that are available for the
target platforms. The "Code Analysis" check-in
policy provided out-of-the-box with Visual
Studio Team Suite or Visual Studio Team
System Development Edition helps you enforce
this in your project

Implementation Identify/Deprecate Unsafe Project teams should analyze all functions and APIs that will be used in
4.2 Functions conjunction with a software development project and prohibit those that are
determined to be unsafe. Once the banned list is determined, project teams
should use header files (such as banned.h and strsafe.h), newer compilers, or
code scanning tools to check code (including legacy code where appropriate)
for the existence of banned functions, and replace those banned functions
with safer alternatives.
New native C and C++ code must not use
banned versions of string buffer handling
functions. Based on analysis of previous
Microsoft Security Response Center (MSRC)
cases, avoiding use of banned APIs is one
actionable way to remove many vulnerabilities.
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.

Sections marked as shared in shipping binaries

represent a security threat. Use properly
secured dynamically created shared memory
objects instead.

All ASP.NET pages that require authentication

must set the
System.Web.UI.Page.ViewStateUserKey
property to a unique value per user (such as
the user's session ID) to help protect the
application against Cross-Site Request Forgery
attacks.

SDL and PCI 78

 Ensure that the application domain group is
granted only execute permissions only on your
stored procedures. Do not grant any other
permission on your database to any other user
or group.

All web applications accessing databases

should always use stored procedures.

Do not use "exec @sql" construct in your

stored procedures.

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

Run a static code analysis tool against all

managed code and fix all security sensitive
issues discovered.

If you are writing code in Visual Studio or .NET

Framework, the FxCop code analysis tool can
be used in this situation. If using FxCop, you
must fix all violations that fall within the
"Security rules" for the version used.

SDL and PCI 79

 Note that there are slight differences in the
security rules for FXCop 1.35 (from Visual
Studio 2005) and FXCop 1.36 (from Visual
Studio 2008). These are explained in this code
analysis blog entry:
http://blogs.msdn.com/fxcop/archive/2008/01/
07/faq-which-rules-shipped-in-which-
version.aspx

.Net Framework version 3.5 requires FXCop

1.36

Security rules for FXCop 1.35 can be found

here: http://msdn.microsoft.com/en-
us/library/ms182296(VS.80).aspx
Security rules for FXCop 1.36 can be found
here: http://msdn.microsoft.com/en-
us/library/ms182296.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

SDL and PCI 80

 program failure by deliberately introducing malformed or random data to an Implementation tools can be found at:
application. The fuzz testing strategy is derived from the intended use of the http://www.microsoft.com/security/sdl/getstart
application and the functional and design specifications for the application. ed/tools.aspx.
The security advisor may require additional fuzz tests or increases in the
scope and duration of fuzz testing. The SDL ProNetwork Tools partners can be
accessed at:
http://www.microsoft.com/security/sdl/getstart
ed/pronetwork.aspx

Verification 5.3 Conduct Attack Surface
Review
It is common for an application to deviate significantly from the functional  
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.

In addition, all security bugs identified in your project should be reviewed

against the security bug bar/quality criteria established for your project to
ensure you have met the criteria or understand the potential attack surface
associated with any bugs granted exceptions.

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

SDL and PCI 81

 to act as points of first contact in a security emergency.
• On-call contacts with decision-making authority that are available 24 hours
a day, seven days a week.
• Security servicing plans for code inherited from other groups within the
organization.
• Security servicing plans for licensed third-party code, including file names,
versions, source code, third-party contact information, and contractual
permission to make changes (if appropriate).

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  

SDL and PCI 82

 conditional on completion of the SDL process. The security advisor assigned
to the release must certify (using the FSR and other data) that the project
team has satisfied security requirements. Similarly, for all products that have
at least one component with a Privacy Impact Rating of P1, the project’s
privacy advisor must certify that the project team has satisfied the privacy
requirements before the software can be shipped.

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.

SDL and PCI 83