You are on page 1of 84

c

c
c| Security Development Lifecyclec
S ccc SS
SSc
  cc cS c cc SSc
SSc c   c
c
c
c
c
c
c

c
c
]or 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.

c
c

Table of Contents

¦ 
 

  



 


 

 

       !


The SDL Process ..................................................................................................................................................................... 3

1.0 SDL Security Training..................................................................................................................................................... 4

1.1 Complete Core Security Training 4

2.0 Requirements Practices................................................................................................................................................. 5

2.1 Establish Security Requirements 5

2.2 Create Quality Gates and Bug Bars 6

2.3 Perform Security Risk Assessment 6

3.0 Design Practices .............................................................................................................................................................. 7

3.1 Establish Security Design Requirements 7

3.2 Analyze Attack Surface 8

3.3 Complete Threat Models 8

4.0 Implementation Practices............................................................................................................................................. 9

4.1 Use Approved Tools 9

4.2 Deprecate Unsafe ]unctions 9

4.3 Perform Static Analysis 9

5.0 Verification Practices ................................................................................................................................................... 10

5.1 Perform Dynamic Code Analysis 10

5.2 Perform ]uzz Testing 10

5.3 Conduct Attack Surface Review 10

6.0 Release Practices........................................................................................................................................................... 10

6.1 Create an Incident Response Plan 10

6.2 Perform a ]inal Security Review 11

6.3 Archive All Release Data 11

c
c

d
" #$
$d %
 %&   
The Relationship Between PCI DSS and PA-DSS........................................................................................................ 12

Definitions.............................................................................................................................................................................. 13

Scope and Applicability ..................................................................................................................................................... 14

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

1.0 Security Training ........................................................................................................................................................... 15

3.0 Design Practices ............................................................................................................................................................ 16

3.1 Establish Security Design Requirements 16

3.2 Attack Surface Analysis 17

3.3 Threat Modeling 17

4.0 Implementation Practices........................................................................................................................................... 17

5.0 Verification Practices ................................................................................................................................................... 18

6.0 Release Practices........................................................................................................................................................... 18

] # %
 '

%  '

d$$¦(d$%¦)*%¦+¦,+d$$¦, ,-¦$%d,¦.$* *,/ 

d$$¦($d %¦)*%¦+¦,+d$$¦, ,-¦$%d,¦.$* *,/ 0'

d$$¦(+ $
.$* *,/ 10

c
c

¦(¦*,2¦*++d%3
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.

,% *, 
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:

ôc Developing new software


ôc 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.
 ,¦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.

¦d% ¦4 ],4d%¦*


Developing new software is probably the most common scenario for applying the Security Development
Lifecycle in a PCI DSS regulated organization. ]or this scenario, a fictitious company named ´Adventure
Worksµ is used. Adventure Works represents a merchant that is creating an online sales application for an
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.

SDL and PCIc 1c

c c
c

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:
ôc Transaction processing
Pc Authorization
Pc Clearing
Pc Settlement
ôc Cardholder data handling
Pc Cardholder name
Pc Cardholder address
Pc Primary account number (PAN)
Pc Expiration date
Pc Card verification value or code (CVV2, CVC2, CID)
ôc Chargebacks
ôc Billing
Pc Single transaction
Pc Reoccurring transactions
ôc Troubleshooting transactions
Pc Help desk access to customer accounts
Pc 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.

¦d% *, + ],4d%¦,¦5%d, 


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
specific compliance activities of the PA-DSS to verify compliance with PCI regulations. In this paper, this
scenario is referred to as the ustom Software Integration Scenario.
The changes necessary for the Northwind Traders POS software include the following:

SDL and PCIc 2c

c c
c

ôc Customized transaction processing


Pc In-store returns and reversals
Pc Chargebacks
ôc Cardholder data handling related to
Pc Cardholder name
Pc PAN
Pc Expiration date
Pc Magnetic stripe or track data (track 1 and/or track 2 data)
ôc Data analysis
Pc Purchase data analytics
Pc Loyalty cards
ôc Troubleshooting transactions
Pc 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.

¦*%,3¦2¦ $+¦,]¦3¦ 2¦%2¦4


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. ]inally, 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.

,#$ 
Any software development organization, regardless of development methodology, can adopt the SDL
process to integrate end-to-end security best practices.

SDL and PCIc 3c

c c
c

] ,#$ 

It is important to notice that the five core phases roughly correspond to the phases within the software
development lifecycle:
ôc Requirements
ôc Design
ôc Implementation
ôc Verification
ôc 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. 

 '  ,


a a 
    
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
ôc Attack surface reduction
ôc Defense in depth
ôc Principle of least privilege
ôc Secure defaults
6 reat modeling
ôc Overview of threat modeling
ôc Design implications of a threat model
ôc Coding constraints based on a threat model
Secure coding
ôc Buffer overruns (for applications using C and C++)
ôc Integer arithmetic errors (for applications using C and C++)

SDL and PCIc 4c

c c
c

ôc Cross-site scripting (for managed code and web applications)


ôc SQL injection (for managed code and web applications)
ôc Weak cryptography
Security testing
ôc Differences between security testing and functional testing
ôc Risk assessment
ôc Security testing methods
rivacy
ôc Types of privacy-sensitive data
ôc Privacy design best practices
ôc Risk assessment
ôc Privacy development best practices
ôc Privacy testing best practices

 '%&  $


3 a 
  
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:

ôc Any product that is commonly used or deployed within a business (e.g. Email or database servers)
ôc Any product that regularly stores, processes, or communicates personally identifiable information
(PII) such as financial, medical, or sensitive customer information.

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


ôc Any product that regularly touches or listens on the internet.
ôc 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
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

SDL and PCIc 5c

c c
c

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.

3 3     


Quality gates and bug bars establish minimum
acceptable levels of security and privacy quality. ! " #
Defining these criteria at the start of a project §nique §ser ID - I DSS Req. 8.1 and 8.5.8
assword Management - I DSS Req. 8.5.1-8.5.14
improves the understanding of risks associated Risk Assessment ² I DSS Req. 12.1.2
with security issues and enables teams to identify Assignment of Roles & Responsibilities ² I 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 ]inal Security Review (]SR) 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.

3   
   !
PCI DSS Requirement 12.1.2 mandates an annual
risk assessment that includes processes to identify ! " #
Risk Assessment ² I 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:

ôc (Security) Which portions of the project require threat models before release?
ôc (Security) Which portions of the project require security design reviews before release?
ôc (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?
ôc (Security) Are there any additional testing or analysis requirements the security advisor deems
necessary to mitigate security risks?
ôc (Security) What is the specific scope of the fuzz testing requirements?
ôc (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:

SDL and PCIc 6c

c c
c

Pc If the feature, product, or services stores sensitive aut entication data (see definition), it is
high risk.
Pc 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.
Pc If the feature, product, or services does not store, process, or transmit any cardholder
data or payment card data, it is low risk.

! '$


 a 
 $  
Establishing security design requirements involves a
number of specific actions. These required activities
! " #
include creating and reviewing security specifications A DSS 5.2 - Develop all web payment applications
for high-risk features, as well as defining secure (internal and external, and including web
administrative access to product) based on secure
coding techniques for developers. The results from
coding guidelines suc as t e Open Web Application
these activities should be documented as the Security roject Guide.
product·s security design requirements. .

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:

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


ôc Describe how to deploy the feature or function in a secure fashion.
ôc 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 ! " #
]ollow c ange control procedures for all c anges to
control provides an archived record for developers to systems components¬ ² I DSS Req. 6.4
review application changes that impact controlled c
data such as payment card data.
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:
ôc Use AES for symmetric encryption/decryption
ôc Use 128-bit or better symmetric keys
ôc Use RSA for asymmetric encryption/decryption and signatures
ôc Use 1024-bit or better RSA keys
ôc Use SHA-256 or better for hashing and message authentication codes
]or additional details on this requirement, review the online SDL Process Guidance available at
http://www.microsoft.com/security/sdl/discover/design.aspx.

SDL and PCIc 7c

c c
c

 3!%! 
 
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:
ôc 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.
ôc Manage firewall exceptions carefully. Be
logical and consistent when making firewall ! " #
exceptions. Any product or component that Requirement to review firewall and router rule sets at
least every six mont s ² I DSS Req. 6.1.1
requires changes to the host firewall settings 
must adhere to the requirements that are Build a firewall configuration t at restricts connections
outlined in the "Policy for Managing ]irewall between untrusted networks and any components in
t e card older data environment ² I DSS Req. 1.2
Configurations" document, available at
c
http://msdn.microsoft.com/en-
us/library/cc307394.aspx.
ôc 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.

  & 
Use threat modeling for features or systems that were
! " #
identified as having known security risk or the
Risk Assessment ² I DSS Req. 12.1.2
potential for risk during the Requirements Phase Information Security olicy ² I 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:

ôc 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:
Pc All projects³all code exposed on the attack surface and all code written by or licensed
from a third party.
Pc New projects³all features and functionality.
Pc Updated versions of existing projects³new features or functionality added in the
updated version.
ôc Verify that all threat models meet minimal quality requirements.

SDL and PCIc 8c

c c
c

ôc Confirm that all threat models contain data


flow diagrams, assets, vulnerabilities, and

*$is anacronym used in t reat modeling to
mitigations. categorize identified t reats into t e six most
ôc Employ threat modeling using STRIDE. To common types:
follow STRIDE, decompose the system into

poofing
components, analyze each component for ampering
threats, and propose mitigations for each epudiation
*nformation Disclosure
threat.
$enial of Service
ôc Use tools such as the Microsoft SDL Threat levation of rivilege
Modeling Tool, a whiteboard or hand-drawn
Learn more at ttp://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.
ôc 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.

ë '  


$


ë a'! (
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.

ë 3$  ')   


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.

ë   
 ! 
Project teams should perform static analysis of source
! " #
code. Static analysis of source code provides a tool-
Review of custom code prior to release to production or
based scalable capability for security code review and customers in order to identify any potential coding
can help verify the use of secure coding practices. vulnerability¬ ² I 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 PCIc 9c

c c
c

0 '2 
$


 a  $ ! 


Run-time verification of software programs is
necessary to verify that a program·s functionality ! " #
works as designed. This verification task should specify 6esting of all security patc es, and systems and
software c anges before deployment¬ ² I 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.

 3  ) %% 


]uzz testing is a specialized form of dynamic analysis
used to induce program failure by deliberately ! " #
Review ustom ode prior to release ² I 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.

  ! 
 ( "
It is common for an application to deviate significantly
from the functional and design specifications created ! " #
Incident Response lan ² I DSS Req. 12.9
during the requirements and design phases of a
Back-out rocedures ² I 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.

1 '%
$


^ a * 


Every application, whether host- or web-based, should
be supported by an incident response plan. Even ! " #
programs with no known vulnerabilities at the time of Incident Response lan ² I DSS Req. 12.9

release can be subject to new threats that emerge over


time. The incident response plan should include:
ôc 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.
ôc On-call contacts with decision-making authority available 24 hours a day, seven days a week.

SDL and PCIc 10c

c c
c

ôc Security servicing plans (escalation


procedures) for code inherited from other ! " #
groups within the organization. If card older data is s ared wit service providers,
ôc Security servicing plans (escalation maintain and implement policies and procedures to
manage service providers¬ ² I DSS Req. 12.8
procedures) for licensed third-party code,
including file names, versions, source code, c
third-party contact information, and contractual
permission to make changes (if appropriate).

^ 3  ) 


 ( "
The ]inal Security Review (]SR) is a deliberate
examination of all the security activities performed on ! " #
Review of custom code prior to release to production
a software application prior to release. The ]SR is not a or customers in order to identify any potential coding
´penetrate-and-patchµ exercise, nor is it a chance to vulnerability¬ ² I DSS Req. 6.3.7
perform security activities that were previously ignored c
or forgotten during the project. The ]SR usually
includes an examination of threat models, exception requests, tool output, and performance against the
previously determined quality gates or bug bars. The ]SR results in one of two different outcomes:
ôc $
]% All security and privacy issues identified by the ]SR process are fixed or mitigated.
ôc $
 ]% #    All security and privacy issues identified by the ]SR 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.

^ !  (!$
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:
ôc ]eature specifications
ôc Source code, binaries, and private symbols
ôc Threat models
ôc Test cases
ôc Other related product documentation
ôc Emergency response plans
ôc License and servicing terms for any third-party software

SDL and PCIc 11c

c c
c

d$$d,3 ],-¦, $d$d %¦5*d, %3


%¦)*%¦+¦,
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.

,#%
#$
$d 
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 document1 lists the types of
applications that are subject to PA-DSS requirements.
In short, PA-DSS applies to:

ôc All ´off-the-shelfµ payment applications that can be sold and installed with little customization by
software vendors.
ôc 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.

ôc Do not retain full magnetic stripe, card validation, code/value, or PIN block data.
ôc Protect stored cardholder data.
ôc Provide secure authentication.

ôc Log payment application activity.


ôc Develop or use secure payment applications.
ôc Protect wireless transmissions if used.

ôc Test payment applications to address vulnerabilities.


ôc ]acilitate secure network implementation.
ôc No cardholder data may be stored on Internet-facing servers or applications.

ccccccccccccccccccccccccccccccccccccccccccccccccccc

chttps://www.pcisecuritystandards.org/security_standards/pa_dss.shtmlc

SDL and PCIc 12c

c c
c

ôc Use secure remote software updates.


ôc Use secure remote access to payment applications.

ôc Encrypt sensitive traffic when on public networks.


ôc Encrypt all non-console administrative access.
ôc Develop and maintain instructional documentation and training programs for customers, resellers,
and integrators.


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.

,  
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 name,
Cardholder Data 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
ôc Meet the intent and rigor of the original PCI DSS requirement.
Controls
ôc Provide a similar level of defense as the original PCI DSS requirement.
ôc Be ´above and beyondµ other PCI DSS requirements (not simply in
compliance with other PCI DSS requirements).
ôc 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.
]or 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 for goods and/or
Merchant
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. ]or 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.

SDL and PCIc 13c

c c
c

Acronym for ´primary account numberµ and also referred to as ´account number.µ
PAN A unique payment card number (typically for credit or debit cards) that identifies
the issuer and the particular cardholder account.
Payment Any application that stores, processes, or transmits cardholder data as part of
Application authorization or settlement
]or 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 ]inancial
Services, JCB International, MasterCard Worldwide, or Visa, Inc.
Security-related information (including but not limited to card validation
Sensitive
codes/values, full magnetic-stripe data, PINs, and PIN blocks) used to authenticate
Authentication Data
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.
,
" $ 



d
" 
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. ]or the purposes of this paper, the following
3
description of an assessment is used:
ôc 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.
ôc 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.

d
" #$
$d 
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

ccccccccccccccccccccccccccccccccccccccccccccccccccc

cSource: I DSS and A-DSS Glossary of 6erms, Abbreviations, and Acronymsc


cSource: The PCI Security Assessment Procedures (SAP)c

SDL and PCIc 14c

c c
c

to the PCI DSS requirements in a table included in Appendix A and the PA-DSS requirements in a table in
Appendix B.

 '  ,

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
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. ]urther, 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 ¦stablis Security Requirements, reate Quality Gate and
Bug Bars, and erform Security and rivacy 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 rivacy 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

SDL and PCIc 15c

c c
c

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 rivacy Risk Assessments of the SDL.

During the SDL Requirements Phase the items in 6able 2 would be included in the security requirements,
the Security and rivacy 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.

! '$

The SDL Design Phase practices include ¦stablis Design Requirements, Analyze Attack Surface, and
omplete 6 reat 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.

 a 
 $  
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. ]or 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. ]or 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.
]ortunately, 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.

SDL and PCIc 16c

c c
c

 3! 
 ! 
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.

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

ë '  


$

The Implementation Phase practices of §se Approved 6ools, Deprecate §nsafe ractices, and erform 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):
ôc Injection flaws, particularly SQL injection. Also, consider OS Command injection, LDAP and Path
injection flaws, and other injection flaws.
ôc Buffer overflow.
ôc Insecure cryptographic storage.

ôc Insecure communications.
ôc Improper error handling.
ôc 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.
ôc Cross-site scripting (XSS).

ôc Improper access control (such as insecure direct object references, failure to restrict URL access,
and directory traversal).
ôc Cross-site request forgery (CSR]).

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

SDL and PCIc 17c

c c
c

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 §sing t e banned. eader file available on t e SDL
Implementation Phase practice that exceeds the PCI DSS tools website is a simple way to protect developers
from using known bad function calls.
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.

0 '2 
$

The SDL Verification Phase practices of erform Dynamic ode Analysis, erform ]uzz 6esting, and onduct
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.

1 '%
$

The SDL Release Phase practices of reate an Incident Response lan, erform a ]inal Security Review, and
Arc ive All Release Data align to some of the requirements of the PCI DSS and PA-DSS. PCI DSS

SDL and PCIc 18c

c c
c

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 ]inal Security Review (]SR).
However, an ]SR is generally consistent with the PA-DSS·s emphasis on producing evidence that software
meets security requirements for cardholder data protection. ]urther, the ]SR 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 ]inal Security Review prior to releasing the product. ]inally, ensuring that there is a complete archive
of all security-related information (requirements, risk assessments, tools outputs, final security reviews,
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 PCIc 19c

c c
c

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

]*%,-¦%%¦d5
]or further reading on the SDL:
ôc Simplified Implementation of the Microsoft SDL (http://go.microsoft.com/?linkid=9708425)
ôc The SDL Optimization Model (http://www.microsoft.com/security/sdl/learn/assess.aspx)
ôc The Microsoft Security Development Lifecycle Process Guidance ² Version 5
(http://go.microsoft.com/?linkid=9724944)
ôc 6 e Security Development Lifecycle: SDL: A rocess 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)

%¦]¦%¦¦
1.c 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.c 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.c List of Validated Payment Applications
https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php

SDL and PCIc 20c

c c
c

d$$¦(d$%¦)*%¦+¦,+d$$¦, ,-¦$%d,¦.$* *,/


$%&    $
 $
 
%&  




 

 
# 


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. ]irewalls are a key protection
mechanism for any computer network.
Establish firewall and router Obtain and inspect the firewall and router configuration
1.1 configuration standards that include standards and other documentation specified below to verify
the following: that standards are complete. Complete the following:
A formal process for approving and
Verify that there is a formal process for testing and approval
testing all network connections and
1.1.1 of all network connections and changes to firewall and router
changes to the 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 any between any DMZ and the internal network zone. Design 3.2 Analyze Attack Surface
1.1.3
demilitarized zone (DMZ) and the Design 3.3 Complete Threat Models
1.1.3.b Verify that the current network diagram is consistent
internal network zone.
with the firewall configuration standards.

Description of groups, roles, and Verify that firewall and router configuration standards
Design 3.2 Analyze Attack Surface
1.1.4 responsibilities for logical include a description of groups, roles, and responsibilities for
Design 3.3 Complete Threat Models
management of network components. logical management of network components.
Documentation and business 1.1.5.a Verify that firewall and router configuration standards
justification for use of all services, include a documented list of services, protocols and ports
protocols, and ports allowed, necessary for business³for example, hypertext transfer Design 3.2 Analyze Attack Surface
including documentation of security protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell
features implemented for those (SSH), and Virtual Private Network (VPN) protocols.
1.1.5
protocols considered to be insecure. 1.1.5.b Identify insecure services, protocols, and ports
 allowed; and verify they are necessary and that security
Design 3.2 Analyze Attack Surface
Examples of insecure services, features are documented and implemented by examining
Design 3.3 Complete Threat Models
protocols, or ports include but are not firewall and router configuration standards and settings for
limited to ]TP, Telnet, POP3, IMAP, each service. An example of an insecure service, protocol, or

c SDL and PCIc 21c


c

and SNMP. port is ]TP, which passes user credentials in clear-text.

1.1.6.a Verify that firewall and router configuration standards


Requirement to review firewall and require review of firewall and router rule sets at least every
1.1.6 router rule sets at least every six six months.
months. 1.1.6.b Obtain and examine documentation to verify that the
rule sets are reviewed at least every six months.
Build firewall configurations that
restrict connections between
untrusted networks and any system
components in the cardholder data
Examine firewall and router configurations to verify that
environment.
connections are restricted between untrusted networks and Design 3.2 Analyze Attack Surface
1.2
system components in the cardholder data environment, as Design 3.3 Complete Threat Models
Note: An ´untrusted networkµ is any
follows:
network t at is external to t e networks
belonging to t e entity under review,
and/or w ic is out of t e entity's
ability to control or manage.
1.2.1.a Verify that inbound and outbound traffic is limited to
Design 3.2 Analyze Attack Surface
that which is necessary for the cardholder data environment,
Restrict inbound and outbound traffic Design 3.3 Complete Threat Models
and that the restrictions are documented.
1.2.1 to that which is necessary for the
1.2.1.b Verify that all other inbound and outbound traffic is
cardholder data environment. 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
Secure and synchronize router
1.2.2 for normal running of the routers) and start-up configuration
configuration files.
files (used when machines are re-booted), have the same,
secure configurations.
Install perimeter firewalls between any
wireless networks and the cardholder Verify that there are perimeter firewalls installed between any
data environment, and configure these wireless networks and systems that store cardholder data,
1.2.3 firewalls to deny or control (if such and that these firewalls deny or control (if such traffic is
traffic is necessary for business necessary for business purposes) any traffic from the wireless
purposes) any traffic from the wireless environment into the cardholder data environment.
environment into the cardholder data

c SDL and PCIc 22c


c

environment.

Examine firewall and router configurations³including but


not limited to the choke router at the Internet, the DMZ
Prohibit direct public access between
router and firewall, the DMZ cardholder segment, the
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
Verify that a DMZ is implemented to limit inbound traffic to
traffic to only system components that
1.3.1 only system components that provide authorized publicly
provide authorized publicly accessible
accessible services, protocols, and ports.
services, protocols, and ports.
Limit inbound Internet traffic to IP Verify that inbound Internet traffic is limited to IP addresses
1.3.2
addresses within the DMZ. 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 Internet
1.3.4
pass from the Internet into the DMZ. into the DMZ.
Do not allow unauthorized outbound
Verify that outbound traffic from the cardholder data
1.3.5 traffic from the cardholder data
environment to the Internet is explicitly authorized
environment to the Internet.
Implement stateful inspection, also
Verify that the firewall performs stateful inspection (dynamic
known as dynamic packet filtering.
packet filtering). (Only established connections should be
1.3.6 (That is, only µestablishedµ
allowed in, and only if they are associated with a previously
connections are allowed into the
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 DMZ
segregated from the DMZ and other and other untrusted networks..
untrusted networks.

c SDL and PCIc 23c


c

Do not disclose private IP addresses 1.3.8.aVerify 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.

#Met ods to obscure I


addressing may include, but are not
limited to:
- Network Address 6ranslation (NA6)
1.3.8
- lacing servers containing card older
data be ind proxy servers/firewalls or 1.3.8.bVerify that any disclosure of private IP addresses and
content cac es, routing information to external entities is authorized.
- Removal or filtering of route
advertisements for private networks
t at employ registered addressing,
- Internal use of R]1918 address
space instead of registered addresses.
1.4.a Verify that mobile and/or employee-owned computers
Install personal firewall software on with direct connectivity to the Internet (for example, laptops
any mobile and/or employee-owned used by employees), and which are used to access the
computers with direct connectivity to organization·s network, have personal firewall software
1.4
the Internet (for example, laptops installed and active.
used by employees), which are used to 1.4.b Verify that the personal firewall software is configured
access the organization·s network. by the organization to specific standards and is not alterable
by users of mobile and/or employee-owned computers.
%&   
   
 
#   

 
The Microsoft SDL focuses on application
Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor
development security. Use of vendor-supplied
default settings to compromise systems. These passwords and settings are well known by hacker communities and
passwords is not addressed in SDL practices.
are easily determined via public information.
%&  !$  
# 


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. ]or 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.

c SDL and PCIc 24c


c

Keep cardholder data storage to a


minimum. Develop a data retention
and disposal policy. Limit storage Obtain and examine the policies, procedures and
amount and retention time to that processes for
3.1
which is required for business, legal, data retention and disposal, and perform the
and/or regulatory purposes, as following:
documented in the data retention
policy.
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
Implement a data retention and period for Y business reasons).
disposal policy that includes: 3.1.1.b Verify that policies and procedures include
ôc Limiting data storage amount and provisions for secure disposal of data when no longer
ôc retention time to that which is needed for legal, regulatory, or business reasons,
required for legal, regulatory, and including disposal of cardholder data.
ôc business requirements
ôc Processes for secure deletion of 3.1.1.c Verify that policies and procedures include
ôc data when no longer needed coverage for all storage of cardholder data.
ôc Specific retention requirements
3.1.1
for 3.1.1.d Verify that policies and procedures include at
ôc cardholder data least one of the following:
ôc A quarterly automatic or manual A programmatic process (automatic or manual) to
process for identifying and remove, at least quarterly, stored cardholder data that
securely exceeds requirements defined in the data retention
ôc deleting stored cardholder data policy.
that Requirements for a review, conducted at least
ôc exceeds defined retention quarterly, to verify that stored cardholder data does
ôc requirements not exceed requirements defined in the data retention
policy.
3.1.1.e ]or 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.

c SDL and PCIc 25c


c

3.2.a ]or 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
Do not store sensitive authentication
storage of sensitive authentication data, and that the Risk Assessment
data after authorization (even if Requirements 2.1
data is secured. Perform periodic static code
encrypted). Requirements 2.3
3.2.b ]or all other entities, if sensitive authentication analysis
3.2 Implementation 4.3
data is received and deleted, obtain and review the Verification Practices
Sensitive authentication data includes Verification 5.0-
processes for securely deleting the data to verify that -Perform dynamic code
the data as cited in the following Verification 5.3
the data is unrecoverable. analysis
Requirements 3.2.1 through 3.2.3:
-Perform fuzz testing
3.2.c]or each item of sensitive authentication data -Conduct Attack Surface
below, perform the following steps: Review
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). ]or a sample of system components, examine data Establish Security
This data is alternatively called full sources, including but not limited to the following, Requirements
track, track, track 1, track 2, and and verify that the full contents of any track from the Perform Security & Privacy
magnetic-stripe data. magnetic stripe on the back of card or equivalent data Risk Assessment
Requirements 2.1
on a chip are not stored under any circumstance: Perform Periodic Static Code
Requirements 2.3
Note: In the normal course of ôc Incoming transaction data Analysis
3.2.1 Implementation 4.3
business, the following data elements ôc All logs (for example, transaction, history, Verification Practices
Verification 5.0-
from the magnetic stripe may need to debugging, error) -Perform Dynamic Code
Verification 5.3
be retained: ôc History files Analysis
ôc The cardholder·s name, ôc Trace files -Perform ]uzz Testing
ôc Primary account number (PAN), ôc Several database schemas -Conduct Attack Surface
ôc Expiration date, and ôc Database contents Review
ôc Service code

To minimize risk, store only these data


elements as needed for business.

c SDL and PCIc 26c


c

]or a sample of system components, examine data


Establish Security
sources, including but not limited to the following,
Requirements
Do not store the card verification code and verify that the three digit or four-digit card
Perform Security & Privacy
or value (three digit or four-digit verification code or value printed on the front of the
Risk Assessment
number printed on the front or back card or the signature panel (CVV2, CVC2, CID, CAV2 Requirements 2.1
Perform Periodic Static Code
of a payment card) used to verify data) is not stored under any circumstance: Requirements 2.3
Analysis
3.2.2 card-not present transactions. ôc Incoming transaction data Implementation 4.3
Verification Practices
ôc All logs (for example, transaction, history, Verification 5.0-
-Perform Dynamic Code
Note: See I DSS Glossary of 6erms, debugging, error) Verification 5.3
Analysis
Abbreviations, and Acronyms for ôc History files
-Perform ]uzz Testing
additional information. ôc Trace files
-Conduct Attack Surface
ôc Several database schemas
Review
ôc Database contents
Establish Security
]or a sample of system components, examine the Requirements
following and verify that PINs and encrypted PIN Perform Security & Privacy
blocks are not stored under any circumstance: Risk Assessment
Requirements 2.1
ôc Incoming transaction data Perform Periodic Static Code
Do not store the personal Requirements 2.3
ôc All logs (for example, transaction, history, Analysis
3.2.3 identification number (PIN) or the Implementation 4.3
debugging, error) Verification Practices
encrypted PIN block. Verification 5.0-
ôc History files -Perform Dynamic Code
Verification 5.3
ôc Trace files Analysis
ôc Several database schemas -Perform ]uzz Testing
ôc Database contents -Conduct Attack Surface
Review
Mask PAN when displayed (the first six
and last four digits are the maximum
number of digits to be displayed).
Notes:
Obtain and examine written policies and examine
ôc This requirement does not apply
displays of PAN (for example, on screen, on paper
to employees and other parties
receipts) to verify that primary account numbers
3.3 with a legitimate business need to
(PANs) are masked when displaying cardholder data,
see the full PAN.
except for those with a legitimate business need to
ôc This requirement does not
see full PAN.
supersede stricter requirements in
place for displays of cardholder
data³for example, for point-of
sale (POS) receipts.

c SDL and PCIc 27c


c

Render PAN unreadable anywhere it 3.4.a Obtain and examine documentation about the
is stored (including on portable digital system used to protect the PAN, including the vendor,
media, backup media, and in logs) by type of system/process, and the encryption algorithms
using any of the following approaches: (if applicable). Verify that the PAN is rendered
ôc One-way hashes based on strong unreadable using any of the following methods: Satisfy Minimum
ôc cryptography (hash must be of ôc One-way hashes based on strong cryptography Design 3.1.3 Cryptographic Design
the ôc Truncation Requirements
ôc entire PAN) ôc Index tokens and pads, with the pads being
ôc Truncation (hashing cannot be securely stored
used ôc Strong cryptography, with associated key-
ôc to replace the truncated segment management processes and procedures
of 3.4.b Examine several tables or files from a sample of Satisfy Minimum
ôc PAN) data repositories to verify the PAN is rendered Design 3.1.3 Cryptographic Design
ôc Index tokens and pads (pads must unreadable (that is, not stored in plain-text). Requirements
ôc be securely stored) 3.4.c Examine a sample of removable media (for Satisfy Minimum
3.4 ôc Strong cryptography with example, back-up tapes) to confirm that the PAN is Design 3.1.3 Cryptographic Design
associated rendered unreadable. Requirements
ôc key-management processes and
ôc procedures

#It is a relatively trivial effort for a
malicious individual to reconstruct
original AN data if t ey ave access
3.4.d Examine a sample of audit logs to confirm that Satisfy Minimum
to bot t e truncated and as ed
the PAN is rendered unreadable or removed from the Design 3.1.3 Cryptographic Design
version of a AN. W ere as ed and
logs. Requirements
truncated versions of t e same AN are
present in an entity·s environment,
additional controls s ould be in place
to ensure t at t e as ed and
truncated versions cannot be correlated
to reconstruct t e original AN.

c SDL and PCIc 28c


c

3.4.1.a If disk encryption is used, verify that logical


access to encrypted file systems is implemented via a Satisfy Minimum
mechanism that is separate from the native operating Design 3.1.3 Cryptographic Design
If disk encryption is used (rather than systems mechanism (for example, not using local user Requirements
file- or column-level database account databases).
encryption), logical access must be 3.4.1.b Verify that cryptographic keys are stored Satisfy Minimum
managed independently of native securely (for example, stored on removable media that Design 3.1.3 Cryptographic Design
3.4.1 operating system access control is adequately protected with strong access controls). Requirements
mechanisms (for example, by not 3.4.1.c Verify that cardholder data on removable
using local user account databases). media is encrypted wherever stored.
Decryption keys must not be tied to Satisfy Minimum
user accounts. Note: If disk encryption is not used to encrypt Design 3.1.3 Cryptographic Design
removable media, t e data stored on t is media will Requirements
need to be rendered unreadable t roug some ot er
met od.
Protect cryptographic keys used for
encryption of cardholder data against
both disclosure and misuse:
Verify processes to protect keys used for encryption of Satisfy Minimum
3.5 Note: 6 is requirement also applies to cardholder data against disclosure and misuse by Design 3.1.3 Cryptographic Design
key-encrypting keys used to protect performing the following: Requirements
data-encrypting keys³suc key-
encrypting keys must be at least as
strong as t e data-encrypting key.
Restrict access to cryptographic keys Examine user access lists to verify that access to keys
3.5.1 to the fewest number of custodians is restricted to the fewest number of custodians
necessary. necessary.
3.5.2.a Examine system configuration files to verify
that keys are stored in encrypted format and that key-
Store cryptographic keys securely in encrypting keys are stored separately from data-
3.5.2 the fewest possible locations and encrypting keys.
forms. 3.5.2.b Identify key storage locations to verify that
keys are stored in the fewest possible locations and
forms.

c SDL and PCIc 29c


c

3.6.a Verify the existence of key-management Satisfy Minimum


procedures for keys used for encryption of cardholder Design 3.1.3 Cryptographic Design
]ully document and implement all
data. Requirements
key-management processes and
procedures for cryptographic keys
3.6.b ]or service providers only: If the service provider
used for encryption of cardholder
shares keys with their customers for transmission or
data, including the following:
3.6 storage of cardholder data, verify that the service Satisfy Minimum
provider provides documentation to customers that Design 3.1.3 Cryptographic Design
Note: Numerous industry standards for
includes guidance on how to securely transmit, store Requirements
key management are available from
and update customer·s keys, in accordance with
various resources including NIS6, w ic
Requirements 3.6.1 through 3.6.8 below.
can be found at ttp://csrc.nist.gov.
Satisfy Minimum
3.6.c Examine the key-management procedures and
Design 3.1.3 Cryptographic Design
perform the following:
Requirements
Satisfy Minimum
Generation of strong cryptographic Verify that key-management procedures are
3.6.1 Design 3.1.3 Cryptographic Design
keys implemented to require the generation of strong keys.
Requirements
Satisfy Minimum
Verify that key-management procedures are
3.6.2 Secure cryptographic key distribution Design 3.1.3 Cryptographic Design
implemented to require secure key distribution.
Requirements
Satisfy Minimum
Verify that key-management procedures are
3.6.3 Secure cryptographic key storage Design 3.1.3 Cryptographic Design
implemented to require secure key storage.
Requirements
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 Verify that key-management procedures are
3.6.4 ciphertext has been produced by a implemented to require periodic key changes at the
given key), as defined by the end of the defined cryptoperiod.
associated application vendor or key
owner, and based on industry best
practices and guidelines (for example,
NIST Special Publication 800-57).

c SDL and PCIc 30c


c

Retirement or replacement (for 3.6.5.a Verify that key-management procedures are


example, archiving, destruction, implemented to require the retirement of keys when
and/or revocation) of keys as deemed the integrity of the key has been weakened.
necessary when the integrity of the 3.6.5.b Verify that the key-management procedures
key has been weakened (for example, are implemented to require the replacement of known
departure of an employee with or suspected compromised keys.
knowledge of a clear-text key), or keys
3.6.5 are suspected of being compromised.
Note: If retired or replaced
3.6.c If retired or replaced cryptographic keys are
cryptograp ic keys need to be retained,
retained,
t ese keys must be securely arc ived
verify that these keys are not used for encryption
(for example, by using a key encryption
operations.
key). Arc ived cryptograp ic keys
s ould 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 only their Verify that manual clear-text key-management
3.6.6 own key component, to reconstruct procedures require split knowledge and dual control
the whole key). of keys.
Note: ¦xamples 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.
Verify that key-management procedures are
Requirement for cryptographic key
implemented to require key custodians to
custodians to formally acknowledge
3.6.8 acknowledge (in writing or electronically) that they
that they understand and accept their
understand and accept their key-custodian
key-custodian responsibilities.
responsibilities.

c SDL and PCIc 31c


c

%&  ë¦ 


 
# 


 6" 7
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,
public networks. Verify that strong cryptography is used
Use strong cryptography and security
during data transmission, as follows:
protocols (example, SSL/TLS, IPSEC,
4.1.a Select a sample of transactions as they are received
SSH, etc.) to safeguard sensitive
and observe transactions as they occur to verify that
cardholder data during transmission
cardholder data is encrypted during transit.
over open, public networks.
4.1.b Verify that only trusted keys and/or certificates are
¦xamples of open, public networks t at
accepted.
are in scope of t e I DSS include but Satisfy Minimum Cryptographic
4.1 4.1.c Verify that the protocol is implemented to use only Design 3.1.3
are not limited to: Design Requirements
secure configurations, and does not support insecure
ôc The Internet
versions or configurations.
ôc Wireless technologies,
4.1.d Verify that the proper encryption strength is
ôc Global System for Mobile
implemented for the encryption methodology in use.
ôc communications (GSM)
(Check vendor recommendations/best practices.)
ôc General Packet Radio Service
4.1.e ]or SSL/TLS implementations: Verify that HTTPS
ôc (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 ]or 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 Cryptographic
4.1.1 encryption for authentication and Design 3.1.3
Design Requirements
transmission.

Note: 6 e use of W¦ as a security


control was pro ibited as of 30 June
2010.
Never send unprotected PANs by 4.2.a Verify that PAN is rendered unreadable or secured Design 3.1.3 Satisfy Minimum Cryptographic
4.2 end-user messaging technologies (for with strong cryptography whenever it is sent via end- Design Requirements
example, e-mail, instant messaging, user messaging technologies. Verification 5.3 Conduct Attack Surface Review

c SDL and PCIc 32c


c

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.
%&  0*
 
 

 
  

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 ]or a sample of system components including all
systems commonly affected by operating system types commonly affected by malicious Establish Security Design
5.1 Design 3.1
malicious software (particularly software, verify that antivirus software is deployed if Requirements
personal computers and servers). applicable antivirus technology exists.
Ensure that all anti-virus programs are ]or a sample of system components, verify that all
capable of detecting, removing, and antivirus programs detect, remove, and protect against
5.1.1 Design 3.1.1 Perform Security Design Review
protecting against all known types of all known types of malicious software (for example,
malicious software. viruses, Trojans, worms, spyware, adware, 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 is
Ensure that all antivirus mechanisms enabled for automatic updates and periodic scans.
5.2 are current, actively running, and 5.2.c ]or 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 ]or 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.
%&  1


   



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 patches to
protect against exploitation and compromise of cardholder data by malicious individuals and malicious
software.

c SDL and PCIc 33c


c

Ensure that all system components


and software are protected from 6.1.a ]or a sample of system components and related
software, compare the list of security patches installed
known vulnerabilities by having the
on each system to the most recent vendor security patch
latest vendor-supplied security
list, to verify that current vendor patches are installed.
patches installed. Install critical
security patches within one month of
release.

Note: An organization may consider


applying a risk-based approac to
6.1
prioritize t eir patc installations. ]or
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 critical
facing devices and systems, databases) new security patches within one month.
ig er t an less-critical internal
devices, to ensure ig -priority systems
and devices are addressed wit in one
mont , and addressing less critical
devices and systems wit in t ree
mont s.
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 Requirements
discovered security vulnerabilities. vulnerabilities, and that a risk ranking is assigned to such Create Quality Gates/Bug Bars
2.2
vulnerabilities. (At minimum, the most critical, highest
Notes: risk vulnerabilities should be ranked as ´High.µ)
ôc Risk rankings s ould be based on
industry best practices. ]or
example, criteria for ranking
´Hig µ risk vulnerabilities may
6.2
include a SS base score of 4.0 or
above, and/or a vendor-supplied 6.2.b Verify that processes to identify new security Requirements
patc classified by t e vendor as vulnerabilities include using outside sources for security Create Quality Gates/Bug Bars
2.2
´critical,µ and/or a vulnerability vulnerability information.
affecting a critical system
component.
ôc 6 e ranking of vulnerabilities as
defined in 6.2.a is considered a
best practice until June 30, 2012,

c SDL and PCIc 34c


c

after w ic it becomes a
requirement.

6 e ranking of vulnerabilities as
defined in 6.2.a is considered a best
practice until June 30, 2012, after
w ic it becomes a requirement.
6.3.a Obtain and examine written software development
processes to verify that the processes are based on
Develop software applications
industry standards and/or best practices.
(internal and external, and including
6.3.b Examine written software development processes
web-based administrative access to
to verify that information security is included throughout
applications) in accordance with PCI Adoption of the entire Microsoft SDL Process will
the life cycle.
DSS (for example, secure enable a development organization to meet this
6.3 authentication and logging), and 6.3.c Examine written software development processes PCI DSS requirement.
based on industry best practices. to verify that software applications are developed in
Incorporate information security accordance with PCI DSS.
throughout the software development
life cycle. These processes must 6.3.d ]rom an examination of written software
include the following: development processes, and interviews of software
developers, verify that:

Removal of custom application


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

c SDL and PCIc 35c


c

Review of custom code prior to 6.3.2.a Obtain and review policies to confirm that all
release to production or customers in custom application code changes must be reviewed
order to identify any potential coding (using either manual or automated processes) as follows:
vulnerability. ôc Code changes are reviewed by individuals other
than the originating code author, and by individuals
Note: 6 is requirement for code reviews who are knowledgeable in code review techniques
applies to all custom code (bot and secure coding practices.
internal and public-facing), as part of ôc Code reviews ensure code is developed according
6.3.2 t e system development life cycle. ode to secure coding guidelines (see PCI DSS
reviews can be conducted by Requirement 6.5).
knowledgeable internal personnel or ôc Appropriate corrections are implemented prior to
t ird parties. Web applications are also release.
subject to additional controls, if t ey ôc Code review results are reviewed and approved by
are public facing, to address ongoing management prior to release.
t reats and vulnerabilities after 6.3.2.b Select a sample of recent custom application
implementation, as defined at I DSS changes and verify that custom application code is
Requirement 6.6. reviewed according to 6.3.2.a, above.
]rom an examination of change control processes,
]ollow change control processes and
interviews with system and network administrators, and
procedures for all changes to system
6.4 examination of relevant data (network configuration
components. The processes must
documentation, production and test data, etc.), verify
include the following:
the following:
The development/test environments are separate from
Separate development/test and
6.4.1 the production environment, with access control in place
production environments.
to enforce the separation.
Separation of duties between
There is a separation of duties between personnel
6.4.2 development/test and production
assigned to the development/test environments and
environments.
those assigned to the production environment.

Production data (live PANs) are not Production data (live PANs) are not used for testing and
6.4.3
used for testing or development. development.

Removal of test data and accounts


Test data and accounts are removed before a
6.4.4 before production systems become
production system becomes active.
active.
Management sign-off by appropriate Verify that management sign-off by appropriate parties
6.4.2
parties is present for each sampled change.

c SDL and PCIc 36c


c

Verify that operational functionality testing is performed


6.4.3 Testing of operational functionality Release 6.2 Perform a ]inal Security Review
for each sampled change.
Verify that back-out procedures are prepared for each
6.4.4 Back-out procedures
sampled change
6.4.5.a Verify that change-control procedures related to
implementing security patches and software
Change control procedures for the
modifications are documented and require items 6.4.5.1
implementation of security patches
² 6.4.5.4 below.
6.4.5 and software modifications.
6.4.5.b ]or a sample of system components and recent
Procedures must include the
changes/security patches, trace those changes back to
following:
related change control documentation. ]or each change
examined, perform the following:
Verify that documentation of impact is included in the
6.4.5.1 Documentation of impact. change control documentation for each sampled
change.
6.4.5.2 Documented change approval by Verify that documented approval by authorized parties
authorized parties. is present for each sampled change.
]or each sampled change, verify that functionality
testing is performed to verify that the change does not Verification 5.1 Perform Dynamic Code Analysis
]unctionality testing to verify that the
6.4.5.3 adversely impact the security of the system.
change does not adversely impact the
]or custom code changes, verify that all updates are
security of the system.
tested for compliance with PCI DSS Requirement 6.5
before being deployed into production.
Verify that back-out procedures are prepared for each
6.4.5.4 Back-out procedures.
sampled change.
Develop applications based on secure 6.5.a Obtain and review software development
coding guidelines. Prevent processes. Verify that processes require training in
common coding vulnerabilities in secure coding techniques for developers, based on
software development processes, to industry best practices and guidance.
include the following: 6.5.b Interview a sample of developers and obtain
#6 e vulnerabilities listed at 6.5.1 evidence that they are knowledgeable in secure coding Verification 5.1 Perform Dynamic Code Analysis
6.5 t roug 6.5.9 were current wit techniques.
industry best practices w en t is
version of I DSS was publis ed.
However, as industry best practices for 6.5.c Verify that processes are in place to verify that web
Verification 5.2 Perform ]uzz Testing
vulnerability management are updated applications are not vulnerable to the following:
(for example, t e OWAS Guide, SANS
W¦ 6op 25, ¦R6 Secure oding, etc.),

c SDL and PCIc 37c


c

t e current best practices must be used


for t ese requirements.
Injection flaws, particularly SQL
Injection flaws, particularly SQL injection. (Validate input
injection. Also consider OS Command
6.5.1 to verify user data cannot modify meaning of commands
Injection, LDAP and Xpath injection
and queries, utilize parameterized queries, etc.)
flaws as well as other injection flaws.
Buffer overflow (Validate buffer boundaries and truncate
6.5.2 Buffer overflow
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
All ´Highµ vulnerabilities as identified in PCI DSS
6.5.6 Requirement 6.2).
Requirement 6.2.
#6 is requirement is considered a
best practice until June 30, 2012, after
w ic it becomes a requirement.
#Requirements 6.5.7 t roug 6.5.9, below, apply to web applications and application interfaces (internal or
external):
Cross-site scripting (XSS) (Validate all parameters before
6.5.7 Cross-site scripting (XSS).
inclusion, utilize context-sensitive escaping, etc.)
Improper Access Control (such as Improper Access Control, such as insecure direct object
insecure direct object references, references, failure to restrict URL access, and directory
6.5.8
failure to restrict URL access, and traversal (Properly authenticate users and sanitize input.
directory traversal) Do not expose internal object references to users.)
Cross-site request forgery (CSR]). (Do not reply on
6.5.9 Cross-site request forgery (CSR]) authorization credentials and tokens automatically
submitted by browsers.)
]or public-facing web applications, ]or public-facing web applications, verify that either one Verification 5.1 Perform Dynamic Code Analysis
address new threats and of the following methods are in place as follows: Verification 5.1 Perform Dynamic Code Analysis
vulnerabilities on an ongoing basis ôc Verify that public-facing web applications are
6.6
and verify these applications are reviewed (using either manual or automated
protected against known attacks by vulnerability security assessment tools or methods),
either of the following methods: as follows:

c SDL and PCIc 38c


c

ôc Reviewing public-facing web - At least annually.


applications via manual or - After any changes. Verification 5.2 Perform ]uzz Testing
automated application - By an organization that specializes in application
vulnerability security assessment security.
tools or methods, at least - That all vulnerabilities are corrected.
annually and after any changes. - That the application is re-evaluated after the
ôc Installing a web-application corrections.
firewall in front of public-facing ôc Verify that a web-application firewall is in place in
web applications. front of public-facing web applications to detect
and prevent web-based attacks.

Note: ´An organization t at specializes in application


securityµ can be eit er a t ird-party company or an
internal organization, as long as t e reviewers specialize
in application security and can demonstrate
independence from t e development team.
%&  8% 

# 

" "7
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, and
7.1 individuals whose job requires such
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.
Assignment of privileges is based on Confirm that privileges are assigned to individuals based
Requirements
7.1.2 individual personnel·s job classification on job classification and function (also called ´role- Establish Security Requirements
2.1
and function. based access controlµ or RBAC).
Requirement for a documented Confirm that documented approval by authorized
7.1.3 approval by authorized parties parties is required (in writing or electronically) for all
specifying required privileges. access, and that it must specify required privileges.
Implementation of an automated Confirm that access controls are implemented via an
7.1.4
access control system. automated access control system.

c SDL and PCIc 39c


c

Establish an access control system for


systems components with
multiple users that restricts access Examine system settings and vendor documentation to
7.2 based on a user·s need to know, and is verify that an access control system is implemented as
set to ´deny allµ unless specifically follows:
allowed. This access control system
must include the following:
Confirm that access control systems are in place on all
7.2.1 Coverage of all system components.
system components.
Assignment of privileges to individuals Confirm that access control systems are configured to
7.2.2 based on job classification and enforce privileges assigned to individuals based on job
function. classification and function.
Default ´deny-allµ setting.

Note: Some access control systems are Confirm that the access control systems have a default Requirements
7.2.3 Establish Security Requirements
set by default to ´allow-all,µ t ereby ´deny-allµ setting. 2.1
permitting access unless/until a rule is
written to specifically deny it.
The Microsoft SDL focuses on application
%&  9d
&
# #  
 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

%&  :% # 




# 

The Microsoft SDL focuses on application
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to development security. Physical security is not
access devices or data and to remove systems or hardcopies, and should be appropriately restricted. addressed in SDL practices.

%&  ',
7
  

 7  

# 


The Microsoft SDL focuses on application


Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing
development security. Tracking and monitoring of
the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting,
deployed systems is not addressed in SDL
and analysis when something does go wrong. Determining the cause of a compromise is very difficult without
practices.
system activity logs.
%&  %
     
 
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.

c SDL and PCIc 40c


c

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 detect
Test for the presence of wireless
and identify any unauthorized wireless access points,
access points and detect unauthorized
including at least the following:
wireless access points on a quarterly
ôc WLAN cards inserted into system components
basis.
ôc Portable wireless devices connected to system
#Met ods t at may be used in t e
components (for example, by USB, etc.)
process include but are not limited to
ôc Wireless devices attached to a network port or
11.1 wireless network scans, p ysical/logical
network device
inspections of system components and
11.1.c Verify that the documented process to identify
infrastructure, network access control
unauthorized wireless access points is performed at least
(NA), or wireless IDS/IS. W ic ever
quarterly for all system components and facilities.
met ods are used, t ey must be
11.1.d If automated monitoring is utilized (for example,
sufficient to detect and identify any
wireless IDS/IPS, NAC, etc.), verify the configuration will
unaut orized devices.
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.
Run internal and external network
vulnerability scans at least quarterly
and after any significant change in the
network (such as new system
component installations, changes in
network topology, firewall rule
modifications, product upgrades).
#It is not required t at four
Verify that internal and external vulnerability scans are
11.2 passing quarterly scans must be
performed as follows:
completed for initial I DSS
compliance if t e assessor verifies 1)
t e most recent scan result was a
passing scan, 2) t e entity as
documented policies and procedures
requiring quarterly scanning, and 3)
vulnerabilities noted in t e scan results
ave been corrected as s own in a

c SDL and PCIc 41c


c

rescan. ]or subsequent years after t e


initial I DSS review, four passing
quarterly scans must ave occurred.

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
11.2.1 Perform quarterly internal vulnerability
obtained, or all ´Highµ vulnerabilities as defined in PCI
scans.
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
Perform quarterly external quarters of external vulnerability scans and verify that
vulnerability scans via an Approved four quarterly scans occurred in the most recent 12-
Scanning Vendor (ASV), approved by month period.
the Payment Card Industry Security
Standards Council (PCI SSC).
#Quarterly external vulnerability
11.2.2.b Review the results of each quarterly scan to
11.2.2 scans must be performed by an Requirements
ensure that they satisfy the ASV Program Guide Create Quality Gates/Bug Bars
Approved Scanning endor (AS), 2.2
requirements (for example, no vulnerabilities rated
approved by t e ayment ard
higher than a 4.0 by the CVSS and no automatic failures).
Industry Security Standards ouncil
(I SS). Scans conducted after
network c anges may be performed by
internal staff. 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
Perform internal and external scans
reports to verify that system components subject to any
11.2.3 after any significant change.
significant change were scanned.
Note: Scans conducted after c anges
11.2.3.b Review scan reports and verify that the scan
may be performed by internal staff.
process includes rescans until:

c SDL and PCIc 42c


c

ôc ]or external scans, no vulnerabilities exist that are


scored greater than a 4.0 by the CVSS,
ôc ]or 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).
Perform external and internal 11.3.a Obtain and examine the results from the most
penetration testing at least once a recent penetration test to verify that penetration testing
year and after any significant is performed at least annually and after any significant
infrastructure or application upgrade changes to the environment.
or modification (such as an operating 11.3.b Verify that noted exploitable vulnerabilities were
11.3
system upgrade, a sub-network added corrected and testing repeated.
to the environment, or a web server 11.3.c Verify that the test was performed by a qualified
added to the environment). These internal resource or qualified external third party, and if
penetration tests must include the applicable, organizational independence of the tester
following: exists (not required to be a QSA or ASV).
Verify that the penetration test includes network layer
penetration tests. These tests should include
11.3.1 Network-layer penetration tests
components that support network functions as well as
operating systems.
Verify that the penetration test includes application-
11.3.2 Application-layer penetration tests layer penetration tests. The tests should include, at a Verification 5.1 Perform Dynamic Code Analysis
minimum, the vulnerabilities listed in Requirement 6.5. Verification 5.2 Perform ]uzz Testing
Use intrusion-detection systems, 11.4.a Verify the use of intrusion-detection systems
and/or intrusion-prevention systems and/or intrusion-prevention systems and that all traffic
to monitor all traffic at the perimeter at the perimeter of the cardholder data environment as
of the cardholder data environment as well as at critical points in the cardholder data
well as at critical points inside of the environment is monitored.
11.4
cardholder data environment, and 11.4.b Confirm IDS and/or IPS are configured to alert
alert personnel to suspected personnel of suspected compromises.
compromises. Keep all intrusion- 11.4.c Examine IDS/IPS configurations and confirm
detection and prevention engines, IDS/IPS devices are configured, maintained, and updated
baselines, and signatures up-to-date. per vendor instructions to verify optimal protection.

c SDL and PCIc 43c


c

11.5.a Verify the use of file-integrity monitoring tools


Deploy file-integrity monitoring tools
within the cardholder data environment by observing
to alert personnel to
system settings and monitored files, as well as reviewing
unauthorized modification of critical
results from monitoring activities. Examples of files that
system files, configuration files, or
should be monitored:
content files; and configure the tools
to perform critical file comparisons at
a) System executables
least weekly.
b) Application executables
c) Configuration and parameter files
Note: ]or file-integrity monitoring
d) Centrally stored, historical or archived, log and audit
purposes, critical files are usually those
files
11.5 that do not regularly change, but the
modification of which could indicate a
system compromise or risk of
compromise. ]ile-integrity monitoring
products usually come pre-configured
 0 "Verify the tools are configured to alert personnel
with critical files for the related
to unauthorized modification of critical files, and to
operating system. Other critical files,
perform critical file comparisons at least weekly.
such as those for custom applications,
must be evaluated and defined by the
entity (that is, the merchant or service
provider).
%&  +


 #

 
   
 
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. ]or 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.
Examine the information security policy and verify that
Establish, publish, maintain, and
the policy is published and disseminated to all relevant
12.1 disseminate a security policy that
personnel (including vendors, contractors, and business
accomplishes the following:
partners).
Verify that the policy addresses all PCI DSS
12.1.1 Addresses all PCI DSS requirements.
requirements.
Includes an annual process that 12.1.2.a Verify that an annual risk assessment process is
identifies threats, and vulnerabilities, documented that identifies threats, vulnerabilities, and
and results in a formal risk assessment. results in a formal risk assessment.
12.1.2 (Examples of risk assessment Requirements Perform Security and Risk
12.1.2.b Review risk assessment documentation to verify
methodologies include but are not 2.3 Assessment
that the risk assessment process is performed at least
limited to OCTAVE, ISO 27005 and
annually.
NIST SP 800-30.)

c SDL and PCIc 44c


c

Includes a review at least annually and Verify that the information security policy is reviewed at
12.1.3 updates when the environment least annually and updated as needed to reflect Design 3.3 Complete Threat Models
changes. changes to business objectives or the risk environment.
Develop daily operational security
procedures that are consistent Examine the daily operational security procedures.
with requirements in this specification Verify that they are consistent with this specification,
12.2
(for example, user account and include administrative and technical procedures for
maintenance procedures, and log each of the requirements.
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:
Verify that the usage policies require explicit approval
12.3.1 Explicit approval by authorized parties
from authorized parties to use the technologies.
Verify that the usage policies require that all technology
Authentication for use of the
12.3.2 use be authenticated with user ID and password or
technology.
other authentication item (for example, token).
A list of all such devices and personnel Verify that the usage policies require a list of all devices
12.3.3
with access. and personnel authorized to use the devices.
Labeling of devices to determine Verify that the usage policies require labeling of devices
12.3.4 owner, contact information and with information that can be correlated to owner,
purpose 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.
Verify that the usage policies require a list of company-
12.3.7 List of company-approved products.
approved products.
Automatic disconnect of sessions for Verify that the usage policies require automatic
12.3.8 remote-access technologies after a disconnect of sessions for remote-access technologies
specific period of inactivity. after a specific period of inactivity.

c SDL and PCIc 45c


c

Activation of remote-access Verify that the usage policies require activation of


technologies for vendors and business remote-access technologies used by vendors and
12.3.9 partners only when needed by vendors business partners only when needed by vendors and
and business partners, with immediate business partners, with immediate deactivation after
deactivation after use use.
]or personnel accessing cardholder 12.3.10.a Verify that the usage policies prohibit copying,
data via remote-access technologies, moving, or storing of cardholder data onto local hard
prohibit copy, move, and storage of drives and removable electronic media when accessing
12.3.10 cardholder data onto local hard drives such data via remote-access technologies.
and removable electronic media, unless 12.3.10.b ]or personnel with proper authorization, verify
explicitly authorized for a defined that usage policies require the protection of cardholder
business need. data in accordance with PCI DSS Requirements.
Verify that the security policy and
procedures clearly define information Verify that information security policies clearly define
12.4
security responsibilities for all information security responsibilities for all personnel.
personnel.
Verify the formal assignment of information security to
a Chief Security Officer or other security-knowledgeable
Assign to an individual or team the
member of management. Obtain and examine
12.5 following information security
information security policies and procedures to verify
management responsibilities:
that the following information security responsibilities
are specifically and formally assigned:
Establish, document, and distribute Verify that responsibility for creating and distributing Requirements
12.5.1 Assign Security Experts
security policies and procedures. security policies and procedures is formally assigned. 2.1.1
Verify that responsibility for monitoring and analyzing
Monitor and analyze security alerts and
security alerts and distributing information to Requirements
12.5.2 information, and distribute to Assign Security Experts
appropriate information security and business unit 2.1.1
appropriate personnel.
management personnel is formally assigned.
Establish, document, and distribute
Verify that responsibility for creating and distributing
security incident response and Requirements
12.5.3 security incident response and escalation procedures is Assign Security Experts
escalation procedures to verify timely 2.1.1
formally assigned.
and effective handling of all situations.
Administer user accounts, including Verify that responsibility for administering user account Create an Incident Response
12.5.4 Release 6.1
additions, deletions, and modifications and authentication management is formally assigned. Plan
Verify that responsibility for monitoring and controlling
12.5.5 Monitor and control all access to data.
all access to data is formally assigned.

c SDL and PCIc 46c


c

12.6.a Verify the existence of a formal security


Implement a formal security awareness
awareness program for all personnel.
program to make all personnel aware
12.6 12.6.b Obtain and examine security awareness program
of the importance of cardholder data
procedures and documentation and perform the Training 1.1 Complete Core Security Training
security.
following:
12.6.1.a Verify that the security awareness program
Educate personnel upon hire and at provides multiple methods of communicating
least annually. awareness and educating personnel (for example,
12.6.1 Note: Met ods can vary depending on posters, letters, memos, web based training, meetings,
t e role of t e personnel and t eir level and promotions).
of access to t e card older data. 12.6.1.b Verify that personnel attend awareness training
upon hire and at least annually.
Require personnel to acknowledge at Verify that the security awareness program requires
least annually that they have read and personnel to acknowledge, in writing or electronically,
12.6.2
understood the security policy and at least annually that they have read and understand
procedures. the information security policy.
Screen potential personnel prior to hire
to minimize the risk of attacks from
internal sources. (Examples of
background checks include previous
Inquire with Human Resource department management
employment history, criminal record,
and verify that background checks are conducted
credit history, and reference checks.)
12.7 (within the constraints of local laws) on potential
#]or t ose potential personnel to
personnel prior to hire who will have access to
be ired for certain positions suc as
cardholder data or the cardholder data environment.
store cas iers w o only ave access to
one card number at a time w en
facilitating a transaction, t is
requirement is a recommendation only.
If the entity being assessed shares cardholder data with
service providers (for example, back-up tape storage
If cardholder data is shared with
facilities, managed service providers such as Web
service providers, maintain and
hosting companies or security service providers, or
12.8 implement policies and procedures to
those that receive data for fraud modeling purposes),
manage service providers, to include
through observation, review of policies and procedures,
the following:
and review of supporting documentation, perform the
following:
12.8.1 Maintain a list of service providers. Verify that a list of service providers is maintained.

c SDL and PCIc 47c


c

Maintain a written agreement that


includes an acknowledgement that the Verify that the written agreement includes an
12.8.2 service providers are responsible for acknowledgement by the service providers of their
the security of cardholder data the responsibility for securing cardholder data.
service providers possess.
Verify there is an established process
Verify that policies and procedures are documented
for engaging service providers
12.8.3 and were followed including proper due diligence prior
including proper due diligence prior to
to engaging any service provider.
engagement.
Maintain a program to monitor service Verify that the entity maintains a program to monitor its
12.8.4 providers· PCI DSS compliance status service providers· PCI DSS compliance status at least
at least annually. annually.
Implement an incident response plan.
Obtain and examine the Incident Response Plan and
12.9 Be prepared to respond immediately to Create an Incident Response
related procedures and perform the following: Release 6.1
a system breach. Plan
Create the incident response plan to be 12.9.1.a Verify that the incident response plan includes:
implemented in the event of system ôc Roles, responsibilities, and communication
breach. Ensure the plan addresses the strategies in the event of a compromise including
following, at a minimum: notification of the payment brands, at a minimum:
ôc Roles, responsibilities, and ôc Specific incident response procedures
communication and contact ôc Business recovery and continuity procedures
strategies in the event of a ôc Data back-up processes
compromise including notification ôc Analysis of legal requirements for reporting
of the payment brands, at a compromises (for example, California Bill 1386
minimum which requires notification of affected consumers
ôc Specific incident response in the event of an actual or suspected compromise Create an Incident Response
12.9.1 Release 6.1
procedures for any business with California residents in their Plan
ôc Business recovery and continuity database)
procedures ôc Coverage and responses for all critical system
ôc Data back-up processes components
ôc Analysis of legal requirements for ôc Reference or inclusion of incident response
reporting compromises procedures from the payment brands
ôc Coverage and responses of all
critical system components  :  "Review documentation from a previously
ôc Reference or inclusion of incident reported incident or alert to verify that the documented
response procedures from the incident response plan and procedures were followed.
payment brands

c SDL and PCIc 48c


c

Create an Incident Response


12.9.2 Test the plan at least annually. 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
Designate specific personnel to be
response and monitoring coverage for any evidence of
12.9.3 available on a 24/7 basis to respond to
unauthorized activity, detection of unauthorized
alerts.
wireless access points, critical IDS alerts, and/or reports
of unauthorized critical system or content file changes.
Provide appropriate training to staff Verify through observation and review of policies that
Create an Incident Response
12.9.4 with security breach response staff with security breach responsibilities are Release 6.1
Plan
responsibilities. periodically trained.
Verify through observation and review of processes that
Include alerts from intrusion detection,
monitoring and responding to alerts from security
12.9.5 intrusion-prevention, and file-integrity Training 1.1 Complete Core Security Training
systems including detection of unauthorized wireless
monitoring systems.
access points are covered in the Incident Response Plan.
Develop a process to modify and Verify through observation and review of policies that
evolve the incident response plan there is a process to modify and evolve the incident
12.9.6
according to lessons learned and to response plan according to lessons learned and to
incorporate industry developments. incorporate industry developments.

c SDL and PCIc 49c


c

d$$¦($d %¦)*%¦+¦,+d$$¦, ,-¦$%d,¦.$* *,/


$d %&   ,$   $
 $

  

 6


 
.d2662622/6 $"7


Do not store sensitive authentication data
after authorization (even if encrypted):
Sensitive authentication data includes the
If sensitive authentication data (see 1.1.1²1.1.3
data as cited in the following Establish Security Requirements
below) is stored prior to authorization and
Requirements 1.1.1 through 1.1.3. Perform Security & Privacy Risk
then deleted, obtain and review methodology
Note: By prohibiting storage of sensitive Requirements 2.1 Assessment
for deleting the data to determine that the
authentication data after authorization, Requirements 2.3 Perform Periodic Static Code
data is unrecoverable. ]or each item of
1.1 the assumption is that the transaction has Implementation 4.3 Analysis
sensitive authentication data below, perform
completed the authorization process and Verification 5.0- Verification Practices
the following steps after completing numerous
the customer has received the final Verification 5.3 -Perform Dynamic Code Analysis
test transactions that simulate all functions of
transaction approval. After authorization -Perform ]uzz Testing
the payment application, to include generation
has completed, this sensitive -Conduct Attack Surface Review
of error conditions and log entries.
authentication data cannot be stored.
d#$

  


%&  ! 
Use forensic tools and/or methods
After authorization, do not store the full (commercial tools, scripts, etc.)4 to examine all
contents of any track from the magnetic output created by the payment application
stripe (located on the back of a card, and verify that the full contents of any track
contained in a chip, or elsewhere). This from the magnetic stripe on the back of the Establish Security Requirements
data is alternatively called full track, track, card are not stored after authorization. Include Perform Security & Privacy Risk
track 1, track 2, and magnetic-stripe data. the following types of files (as well as any other Requirements 2.1 Assessment
In the normal course of business, the output generated by the payment application): Requirements 2.3 Perform Periodic Static Code
1.1.1 following data elements from the - Incoming transaction data Implementation 4.3 Analysis
magnetic stripe may need to be retained: - All logs (for example, transaction, history, Verification 5.0- Verification Practices
The accountholder·s name, primary debugging, error) Verification 5.3 -Perform Dynamic Code Analysis
account number (PAN), Expiration date, - History files -Perform ]uzz Testing
and Service code. To minimize risk, store - Trace files -Conduct Attack Surface Review
only those data elements needed for - Non-volatile memory, including non-volatile
business. d#$

   cache


%&  !   - Database schemas
- Database contents

c SDL and PCIc 50c


c

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
After authorization, do not store the card CID, CAV2 data) is not stored after Perform Security & Privacy Risk
validation value or code (three-digit or authorization. Include the following types of Requirements 2.1 Assessment
four-digit number printed on the front or files (as well as any other output generated by Requirements 2.3 Perform Periodic Static Code
1.1.2 back of a payment card) used to verify the payment application): Implementation 4.3 Analysis
card-not-present transactions. d - Incoming transaction data Verification 5.0- Verification Practices
#$

  

 - All logs (for example, transaction, history, Verification 5.3 -Perform Dynamic Code Analysis
%&  !   debugging, error) -Perform ]uzz 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
Establish Security Requirements
are not stored after authorization. Include the
Perform Security & Privacy Risk
following types of files (as well as any other
After authorization, do not store the Requirements 2.1 Assessment
output generated by the payment application):
personal identification number (PIN) or Requirements 2.3 Perform Periodic Static Code
- Incoming transaction data
1.1.3 the encrypted PIN block. d#$ 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 ]uzz Testing
- Trace files
-Conduct Attack Surface Review
- Non-volatile memory, including non-volatile
cache
- Database schemas
- Database contents

c SDL and PCIc 51c


c

1.1.4.a Review the PA-DSS Implementation


Guide prepared by the vendor and verify the
documentation includes the following
Securely delete any magnetic stripe data,
instructions for customers and
card validation values or codes, and PINs
resellers/integrators:
or PIN block data stored by previous Establish Security Requirements
- That historical data must be removed Requirements 2.1
versions of the payment application, in Perform Security & Privacy Risk
(magnetic stripe data, card validation codes, Requirements 2.3
accordance with industry accepted Assessment
PINs, or PIN blocks stored by previous versions
standards for secure deletion, as defined,
of the payment application)
for example by the list of approved
- How to remove historical data
1.1.4 products maintained by the National
- That such removal is absolutely necessary for
Security Agency, or by other State or
PCI DSS compliance
National standards or regulations. d
Establish Security Requirements
#$

  

 1.1.4.b Verify the vendor provides a secure Requirements 2.1
Perform Security & Privacy Risk
%&  ! Note: This requirement wipe tool or procedure to remove the data. Requirements 2.3
Assessment
only applies if previous versions of the
1.1.4.c Verify, through the use of forensic tools
payment application stored sensitive
and/or methods, that the secure wipe tool or Establish Security Requirements
authentication data. Requirements 2.1
procedure provided by vendor securely Perform Security & Privacy Risk
Requirements 2.3
removes the data, in accordance with industry- Assessment
accepted standards for secure deletion of data.
1.1.5.a Examine the software vendor·s
Securely delete any sensitive
procedures for troubleshooting customers·
authentication data (pre-authorization
problems and verify the procedures include:
data) used for debugging
- Collection of sensitive authentication data
or troubleshooting purposes from log
only when needed to solve a specific problem.
files, debugging files, and other data
- Storage of such data in a specific, known Establish Security Requirements
sources received from customers, to Requirements 2.1
location with limited access. Perform Security & Privacy Risk
verify that magnetic stripe data, card Requirements 2.3
- Collection of only a limited amount of data Assessment
validation codes or values, and PINs or
1.1.5 needed to solve a specific problem.
PIN block data are not stored on software
- Encryption of sensitive authentication data
vendor systems. These data sources must
while stored.
be collected in limited amounts and only
- Secure deletion of such data immediately
when necessary to resolve a problem,
after use.
encrypted while stored, and deleted
1.1.5.b Select a sample of recent
immediately after use. d#$
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.

c SDL and PCIc 52c


c

1.1.5.c Review the PA-DSS Implementation


Guide prepared by the vendor and verify the
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
Software vendor must provide guidance guidance for customers and
to customers regarding purging of resellers/integrators:
cardholder data after expiration of - That cardholder data exceeding the
2.1
customer-defined retention period. customer-defined retention period must be
d#$

  

 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).
Mask PAN when displayed (the first six
and last four digits are the maximum
Review displays of credit card data, including
number of digits to be displayed). - This
but not limited to POS devices, screens, logs,
requirement does not apply to those
and receipts, to determine that credit card
employees and other parties with a
2.2 numbers are masked when displaying
legitimate business need to see full PAN.
cardholder data, except for those with a
- This requirement does not supersede
legitimate business need to see full credit card
stricter requirements in place for displays
numbers.
of cardholder data³for example, for
point-of-sale (POS) receipts. d#

c SDL and PCIc 53c


c

$

  


%&  ! !
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
Satisfy Minimum Cryptographic
key management processes and received from customers for debugging or Design 3.1.3
Design Requirements
procedures. troubleshooting purposes), verify that the PAN
The MINIMUM account information that is rendered unreadable in accordance with PCI
must be rendered unreadable is the PAN. DSS Requirement 3.4.
d#$

  


%&  ! ë
6 e AN must be rendered unreadable
anyw ere it is stored, even outside t e
payment application.
If disk encryption is used (rather than file-
or column-level database encryption),
logical access must be managed
independently of native operating system
If disk encryption is used, verify that it is
access control mechanisms (for example, Satisfy Minimum Cryptographic
2.4 implemented in accordance with PCI DSS Design 3.1.3
by not using local user account Design Requirements
Requirements 3.4.1.a through 3.4.1.c.
databases). Decryption keys must not be
tied to user accounts. d#$


  

%&  
! ë 
Payment application must protect
cryptographic keys used for encryption of Verify the payment application protects keys
Satisfy Minimum Cryptographic
2.5 cardholder data against disclosure and against disclosure and misuse, per PCI DSS Design 3.1.3
Design Requirements
misuse.d#$

   requirement 3.5.1 and 3.5.2.


%&  ! 0

c SDL and PCIc 54c


c

Payment application must implement key


management processes and procedures
Verify the payment application implements key
for cryptographic keys used for Satisfy Minimum Cryptographic
2.6 management techniques for keys, per PCI DSS Design 3.1.3
encryption of cardholder data. d Design Requirements
Requirements 3.6.1 through 3.6.8.
#$

  


%&  ! 1
2.7.a Review the PA-DSS Implementation
Securely delete any cryptographic key Guide prepared by the vendor and verify the
material or cryptogram stored by documentation includes the following
previous versions of the payment instructions for customers and
application, in accordance with industry- resellers/integrators:
accepted standards for secure deletion, - That cryptographic material must be Satisfy Minimum Cryptographic
Design 3.1.3
as defined, for example the list of removed Design Requirements
approved products maintained by the - How to remove cryptographic material
National Security Agency, or by other - That such removal is absolutely necessary for
State or National standards or PCI DSS compliance
2.7
regulations. These are cryptographic keys - How to re-encrypt historic data with new
used to encrypt or verify cardholder data. keys
d#$

  

 2.7.b Verify vendor provides a secure wipe tool
Satisfy Minimum Cryptographic
%&  ! 1 or procedure to remove cryptographic Design 3.1.3
Design Requirements
Note: 6 is requirement only applies if material.
previous versions of t e payment 2.7.c Verify, through use of forensic tools
application used cryptograp ic key and/or methods, that the secure wipe tool or
Satisfy Minimum Cryptographic
materials or cryptograms to encrypt procedure securely removes the cryptographic Design 3.1.3
Design Requirements
card older data. material, in accordance with 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

c SDL and PCIc 55c


c

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.
The ´out-of-the-boxµ installation of the
3.1.b Test the payment application to verify the
payment application in place at the
payment application does not use (or require the
completion of the installation process,
use of) default administrative accounts for other Establish Security Design
must facilitate use of unique user IDs Design 3.1
necessary software (for example, the payment Requirements
and secure authentication (defined at
application must not use the administrative
PCI DSS Requirements 8.1, 8.2, and
account for database software).
8.5.8²8.5.15) for all administrative
3.1.c Examine PA-DSS Implementation Guide
access and for all access to cardholder
created by vendor to verify the following:
data. d#$

  
- Customers and resellers/integrators are advised


%&  9 69 6

against using default administrative accounts for
9 0 9;9 0 0
payment application logins (for example, don·t
use the ´saµ account for payment application
3.1 Note: 6 ese password controls are not
access to the database).
intended to apply to employees w o
- Customers and resellers/integrators are advised
only ave access to one card number at
to assign secure authentication to these default
a time to facilitate a single transaction.
accounts (even if they won·t be used), and then
6 ese controls are applicable for access
disable or do not use the accounts.
by employees wit administrative
- Customers and resellers/integrators are advised
capabilities, for access to servers wit
to assign secure authentication for payment
card older data, and for access
applications and systems whenever possible.
controlled by t e payment application.
- Customers and resellers/integrators are advised
6 is requirement applies to t e
how to create PCI DSS-compliant secure
payment application and all associated
authentication to access the payment application,
tools used to view or access card older
per PCI DSS Requirements 8.5.8 through 8.5.15
data.
- 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.

c SDL and PCIc 56c


c

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. d#$


compliant secure authentication, to any PCs,
  

%&  9 
servers, and databases with payment applications

9 
and cardholder data.
Render payment application
passwords unreadable during
transmission and storage, using strong
cryptography based on approved
Examine payment application password files
standards Note: ´Strong cryptographyµ
3.3 during storage and transmission to verify that
is defined in PCI DSS
passwords are unreadable at all times.
and PA-DSS Glossary of Terms,
Abbreviations, and Acronyms. d
# $

  


%&  9 ë
The Microsoft SDL focuses on application development
ë $



  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. d#$


  

%&  ' 
Payment application must implement 4.2.a Examine payment application log
an automated audit trail to track and parameters and verify that logs contain the data
4.2 Requirements 2.0 Establish Security Requirements
monitor access. PCI Data Security required in PCI DSS Requirements 10.2.1 through
Standard Requirements 10.2 and 10.2.7 and 10.3.1 through 10.3.6.

c SDL and PCIc 57c


c

10.3Payment application must 4.2.b If payment application log settings are


implement an automated audit trail to configurable by the customer and
track and monitor access. d# resellers/integrators, or customers or
$

  

 resellers/integrators are responsible for
%&  ' 
' ! implementing logging, examine PA-DSS
Implementation Guide prepared by the vendor 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
0  



Develop all payment applications in Obtain and examine written software development
accordance with PCI DSS (for example, processes to verify that they are based on industry
secure authentication and logging) standards, that security is included throughout the
and based on industry best practices lifecycle, and that software applications are Verification Practices
and incorporate information security developed in accordance with PCI DSS. ]rom an Verification 5.0- -Perform Dynamic Code Analysis
5.1
throughout the software development examination of written software development Verification 5.3 -Perform ]uzz Testing
lifecycle. These processes must include processes, interviews of software developers, and -Conduct Attack Surface Review
the following: examination of relevant data (network
d#$

   configuration documentation, production and test


%&  1 ! data, etc.), verify that:
Testing of all security patches and
All security patches and system and software Verification Practices
system and software configuration
changes are tested before being deployed, Verification 5.0- -Perform Dynamic Code Analysis
5.1.1 changes before deployment, including
including but not limited to testing for the Verification 5.3 -Perform ]uzz Testing
but not limited to testing for the
following: -Conduct Attack Surface Review
following:
Validation of all input (to prevent Validation of all input (to prevent cross-site
5.1.1.1 cross-site scripting, injection flaws, scripting, injection flaws, malicious file execution, Verification 5.1 Perform Dynamic Code Analysis
malicious file execution, etc.). etc.).
5.1.1.2 Validation of proper error handling. Validation of proper error handling. Verification 5.1 Perform Dynamic Code Analysis
Validation of secure cryptographic
5.1.1.3 Validation of secure cryptographic storage. Verification 5.1 Perform Dynamic Code Analysis
storage.
5.1.1.4 Validation of secure communications. Validation of secure communications. Verification 5.1 Perform Dynamic Code Analysis
Validation of proper role-based access Validation of proper role-based access control
5.1.1.5 Verification 5.1 Perform Dynamic Code Analysis
control (RBAC). (RBAC).

c SDL and PCIc 58c


c

The test/development environments are separate


Separate development/test, and
5.1.2 from the production environment, with access
product environments.
control in place to enforce the separation.
Separation of duties between There is a separation of duties between personnel
5.1.3 development/test, and production assigned to the development/test environments
environments. and those assigned to the production environment.
Live PANs are not used for testing or Live PANs are not used for testing or development,
5.1.4
development. or are sanitized before use.
Removal of test data and accounts
Test data and accounts are removed before
5.1.5 before production systems become
production systems become active.
active.
Removal of custom payment
Custom payment application accounts, user IDs,
application accounts, user IDs, and
5.1.6 and passwords are removed before payment
passwords before payment
application is released to customers.
applications are 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
Review of payment application code than the originating code author, and by Design 3.1 Establish Design Requirements
prior to release to customers after any individuals who are knowledgeable in code review Verification 5.3 Conduct Attack Surface Review
significant change, to identify any techniques and secure coding practices.
potential coding vulnerability. - Appropriate corrections are implemented prior to
Note: 6 is requirement for code reviews release.
applies to all payment application - Code review results are reviewed and approved
5.1.7 components (bot internal and public- by management prior to release.
facing web applications), as part of t e 5.1.7.b Confirm the vendor performs code reviews
system development lifecycle required for all application code changes for web
by A-DSS Requirement 5.1 and I applications (using either manual or automated
DSS Requirement 6.3. ode reviews can processes) as follows:
be conducted by knowledgeable - Code changes are reviewed by individuals other
Design 3.1 Establish Design Requirements
internal personnel or t ird parties. than the originating code author, and by
Verification 5.3 Conduct Attack Surface Review
individuals who are knowledgeable in code review
techniques and secure coding practices.
- Code reviews verify code is developed according
to secure coding guidelines such as the Open Web
Security Project Guide. (See PA-DSS Requirement

c SDL and PCIc 59c


c

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.

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: 6 e vulnerabilities listed in A-DSS Requirements 5.2.1 t roug 5.2.10 and in I DSS at
5.2
6.5.1 t roug 6.5.10 were current in t e OWAS guide w en I DSS v1.2 was publis ed.
However, if and w en t e OWAS guide is updated, t e current version must be used for t ese
requirements.
d#$

  

%&  1 0

5.2.1 Cross-site scripting (XSS) (Validate all


5.2.1 Cross Site Scripting (XSS)
parameters before inclusion.)
Injection ]laws, 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
]ull SDL applies ]ull SDL applies
Xpath injection meaning of commands and queries.)
Design 3.1 Establish Design Requirements
5.2.3 Malicious file execution (Validate input to
Verification 5.3 Conduct Attack Surface Review
5.2.3 Malicious file execution verify application does not accept filenames or files
from users.)
5.2.4 Insecure direct object references (Do not
5.2.4 Insecure direct object references
expose internal object references to users.)
5.2.5 Cross-site request forgery (CSR]) (Do not rely
5.2.5 Cross site request forgery (CSR]) 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.)

c SDL and PCIc 60c


c

5.2.9 Insecure communications (Properly encrypt all


5.2.9 Insecure communications
authenticated and sensitive communications.)
5.2.10 ]ailure to restrict URL access (Consistently
5.2.10 ]ailure to restrict URL access enforce access control in presentation layer and
business logic for all URLs.)
5.3.a Obtain and examine the vendor·s change-
Software vendor must follow change control procedures for software modifications, and Establish Security Design
Design 3.1
control procedures for all product verify that the procedures require items 5.3.1²5.3.4 Requirements
software configuration changes. The below.
5.3
procedures must include the following: 5.3.b Examine recent payment application changes,
d#$

   and trace those changes back to related change


%&  1 ë control documentation. Verify that, for each change Release 6.1 Create an Incident Response Plan
examined, the following was \documented
according to the change control procedures:
Verify that documentation of customer impact is
5.3.1 Documentation of impact included in the change control documentation for Release 6.2 Perform a ]inal Security Review
each change.
Management sign-off by appropriate Verify that management sign-off by appropriate
5.3.2 Release 6.2 Perform a ]inal Security Review
parties parties is present for each change.
Verify that operational functionality testing was
5.3.3 Testing of operational functionality Release 6.2 Perform a ]inal Security Review
performed for each change.
Back-out or product de-installation Verify that back-out or product de-installation
5.3.4
procedures procedures are prepared for each change.
The payment application must not use Examine system services, daemons, and protocols
or require use of unnecessary and enabled or required by the payment application.
insecure services and protocols (for Verify that unnecessary and insecure services or
5.4 example, NetBIOS, file-sharing, Telnet, protocols are not enabled by default or required by
unencrypted ]TP, etc.). d# the payment application (for example, ]TP 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
1 $  
  security can be included in design requirements,
protection of deployed wireless systems is not
addressed.

c SDL and PCIc 61c


c

8 ,



 
"
Software vendors must establish a 7.1.a Obtain and examine processes to identify new
process to identify newly discovered vulnerabilities and to test payment applications for
Verification Practices
security vulnerabilities (for example, new vulnerabilities. Verify the processes include:
Verification 5.0- -Perform Dynamic Code Analysis
subscribe to alert services freely - Using outside sources for security vulnerability
Verification 5.3 -Perform ]uzz Testing
available on the Internet) and to test information
-Conduct Attack Surface Review
their payment applications for - Testing of payment applications for new
vulnerabilities. Any underlying software vulnerabilities
7.1
or systems that are provided with or
7.1.b Verify that processes to identify new
required by the payment application
vulnerabilities and implement corrections into
(for example, web servers, 3rd-party
payment application apply to all software provided
libraries and programs) must be Release 6.1 Create an Incident Response Plan
with or required by the payment application (for
included in this process. d#
example, web servers, third-party libraries and
$

  


programs).
%&  1 
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 delivery target system prior to installation.
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,
9 ]

  7  

security of a deployed network is not specifically
addressed

c SDL and PCIc 62c


c

The Microsoft SDL focuses on application


development. Privacy of cardholder data can be
: 
# 

  " 
  #  included in the Privacy Risk assessment, but security &
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

 ¦ 
 " 7
If the payment application sends, or 12.1.a If the payment application sends, or
facilitates sending, cardholder data facilitates sending, cardholder data over public
Design 3.1.3 Satisfy Minimum Cryptographic
over public networks, the payment networks, verify that secure encryption
Design Requirements
application must support use of strong transmission technology (for example, IPSEC, VPN
Verification 5.3 Conduct Attack Surface Review
cryptography and security protocols or SSL/TLS) is provided, or that use thereof is
such as SSL/TLS and Internet protocol specified.
security (IPSEC) to safeguard sensitive
cardholder data during transmission
over open, public networks. Examples
12.1 12.1.b If the payment application allows data
of open, public networks that are in
transmission over public networks, examine PA-DSS
scope of the PCI DSS are:
Implementation Guide prepared by the vendor, and Design 3.1.3 Satisfy Minimum Cryptographic
- The Internet.
verify the vendor includes directions for customers Design Requirements
- Wireless technologies.
and resellers/integrators to use secure encryption Verification 5.3 Conduct Attack Surface Review
- Global System for Mobile
transmission technology (for example, IPSEC, VPN
Communications (GSM).
or SSL/TLS).
- General Packet Radio Service (GPRS).
d#$

  


%&  ë 
The payment application must never 12.2.a If the payment application allows and/or
Design 3.1.3 Satisfy Minimum Cryptographic
send unencrypted PANs by end-user facilitates sending of PANs by end-user messaging
12.2 Design Requirements
messaging technologies (for example, technologies, verify that a strong cryptography
Verification 5.3 Conduct Attack Surface Review
email, instant messaging, chat). d solution is provided, or that use thereof is specified.

c SDL and PCIc 63c


c

#$

  

 12.2.b If the payment application allows and/or
%&  ë  facilitates the sending of PANs by end-user
messaging technologies, examine PA-DSS Design 3.1.3 Satisfy Minimum Cryptographic
Implementation Guide prepared by the vendor, and Design Requirements
verify the vendor includes directions for customers Verification 5.3 Conduct Attack Surface Review
and resellers/integrators to use a solution that
implements strong cryptography.
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
ë +

 
 


 
   6  6
 development. Although training is covered in the SDL

  Practices, details on training specific to PA-DSS
requirements is not addressed

c SDL and PCIc 64c


c

d$$¦(+%  ],$%d,¦.$* *,/


6 c  c c c c c  c S   c   c c c S c c ! " "# $ %&'()*+,"c  c c
c-cc  cc cS c cc-c c !" " ,c

$
 $

   

 d


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:
-   , including the following topics: Attack surface
reduction, Defense in depth, rinciple of least privilege, Secure defaults
- ,# 
 , including the following topics: Overview of threat
modeling, Design implications of a threat model, Coding constraints
based on a threat model
-   , 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
-   , including the following topics: Differences between
security testing and functional testing, Risk assessment, Security
testing methods
- $ 
 , including the following topics: Types of privacy-sensitive
data, Privacy design best practices, Risk assessment, Privacy
development best practices, Privacy testing best practices

c SDL and PCIc 65c


c

Requirements Requirements Practices Setting a designated time for defining project requirements allows
2.0 development teams to consider how to best integrate security and
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   , 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.

c SDL and PCIc 66c


c

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

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 ]inal Security Review (]SR).

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

c SDL and PCIc 67c


c

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.

c SDL and PCIc 68c


c

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
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?
‡ (rivacy) What is the Privacy Impact Rating? The answer to this
question is based on the following guidelines:

$ -# $ 
  %7 The feature, product, or service stores or
transfers PII, changes settings or file type associations, or installs
software.
$ +
 $ 
  %7 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).
$!  $ 
 %7 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.

c SDL and PCIc 69c


c

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

c SDL and PCIc 70c


c

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

]or additional details on this requirement,


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

c SDL and PCIc 71c


c

Design 3.2 Analyze Attack Surface 1. Use Code Access Secuirty (CAS) correctly 1. Use Code Access Secuirty (CAS) correctly:
2. Manage firewall exceptions carefully When developing with managed code, use
3. Ensure your application runs correctly as a non-administrator 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 ]irewall 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.

c SDL and PCIc 72c


c

Design 3.3 Complete Threat Models   # 


  

  # ]or more information on Threat Modeling:


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

 ¦ #

# 
   
# 
 &
 
&   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.

! -

# 
 
   
 


 " 

 6 6
 



 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.

ë ,# 
 




 
.
<
/#" #    " #
 

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.

c SDL and PCIc 73c


c

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 /SA]ESEH 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.

c SDL and PCIc 74c


c

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 New native C and C++ code must not use
4.2 ]unctions conjunction with a software development project and prohibit those that are banned versions of string buffer handling
determined to be unsafe. Once the banned list is determined, project teams functions. Based on analysis of previous
should use header files (such as banned.h and strsafe.h), newer compilers, or Microsoft Security Response Center (MSRC)
code scanning tools to check code (including legacy code where appropriate) cases, avoiding use of banned APIs is one
for the existence of banned functions, and replace those banned functions actionable way to remove many vulnerabilities.
with safer alternatives. The "SDL Banned APIs" check-in policy
provided with this template helps you enforce
this in your project. Check the "Setup check-in
policies" task for information on how to ensure
this.

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 ]orgery
attacks.

c SDL and PCIc 75c


c

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


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

c SDL and PCIc 76c


c

Note that there are slight differences in the


security rules for ]XCop 1.35 (from Visual
Studio 2005) and ]XCop 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 ]ramework version 3.5 requires ]XCop


1.36

Security rules for ]XCop 1.35 can be found


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

c SDL and PCIc 77c


c

Verification 5.2 Perform fuzz testing ]uzz testing is a specialized form of dynamic analysis used to induce A list of Microsoft's SDL-related
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 It is common for an application to deviate significantly from the functional
Review and design specifications created during the requirements and design phases
of a software development project. Therefore, it is critical to re-review threat
models and attack surface measurement of a given application when it is
code complete. This review ensures that any design or implementation
changes to the system have been accounted for, and that any new attack
vectors created as a result of the changes have been reviewed and mitigated.

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 ]inal Security Review and archive all pertinent
data for post-release servicing of the software.

c SDL and PCIc 78c


c

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
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 ]inal Security The ]inal Security Review (]SR) is a deliberate examination of all the security
Review activities performed on a software application prior to release. The ]SR is
performed by the security advisor with assistance from the regular
development staff and the security and privacy team leads. The ]SR is not a
´penetrate and patchµ exercise, nor is it a chance to perform security
activities that were previously ignored or forgotten. The ]SR usually includes
an examination of threat models, exception requests, tool output, and
performance against the previously determined quality gates or bug bars.
The ]SR results in one of three different outcomes:

‡ Passed ]SR. All security and privacy issues identified by the ]SR process are
fixed or mitigated.
‡ Passed ]SR with exceptions. All security and privacy issues identified by the
]SR 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.

c SDL and PCIc 79c


c

‡ ]SR 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
conditional on completion of the SDL process. The security advisor assigned
to the release must certify (using the ]SR 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.

c SDL and PCIc 80c