PCI DSS 1.1
Buy a PCI Compliant IT Information Security Policy
Compliancefast.com Blog
Payment Card Industry (PCI) Data Security
Standard
Security Audit Procedures
Version 1.1
Release: September 2006
Table of Contents
.......................................................................................................................................
50
Appendix C: Compensating Controls Worksheet/Completed
Example
Security Audit Procedures v 1.1
2
Introduction
The PCI Security Audit Procedures are designed for use by
assessors conducting onsite reviews for merchants and service
providers required to validate compliance with Payment Card
Industry (PCI) Data Security Standard (DSS) requirements.
The requirements and audit procedures presented in this document
are based on the PCI DSS.
This document contains the following:
·
Introduction
·
PCI DSS Applicability Information
·
Scope of Assessment for Compliance with PCI DSS
Requirements
Instructions and Content for Report On
Compliance
·
Revalidation of Open Items
·
Security Audit Procedures
·
A
PPENDICES
·
Appendix A: PCI DSS Applicability for Hosting Providers
(with Testing Procedures)
·
·
Appendix B: Compensating Controls
Appendix C: Compensating Controls Worksheet/Completed
Example
Security Audit Procedures v 1.1
3
PCI DSS Applicability Information
The following table illustrates commonly used elements of
cardholder and sensitive authentication data; whether
storage of
each data element is permitted or prohibited; and if each data
element must be protected. This table is not
exhaustive,
but is presented to illustrate the different types of requirements
that apply to each data element.
*
These data elements must be protected if stored in
conjunction with the PAN. This protection must be consistent with
PCI DSS requirements for general protection of
the
cardholder environment. Additionally, other legislation (for
example, related to consumer personal data protection, privacy,
identity theft, or data security) may require
specific protection of this data, or proper disclosure of a
company's practices if consumer-related personal data is being
collected during the course of business. PCI DSS,
however, does not apply if PANs are not stored, processed, or
transmitted.
** Sensitive authentication data must not be stored
subsequent to authorization (even if
encrypted).
Data Element
Storage
Permitted
Protection
Required
PCI DSS
REQ. 3.4
Cardholder Data
Primary Account
Number (PAN)
YES
YES
YES
Cardholder Name*
YES
YES*
NO
Service Code*
YES
YES*
NO
Expiration Date*
YES
YES*
NO
Sensitive Authentication Data**
Full Magnetic Stripe
NO
N/A
N/A
CVC2/CVV2/CID
NO
N/A
N/A
PIN / PIN Block
NO
N/A
N/A
Security Audit Procedures v 1.1
4
Scope of Assessment for Compliance with PCI DSS
Requirements
The PCI DSS security requirements apply to all "system
components." A system component is defined as any network
component, server, or application that is included in or connected
to the cardholder data environment. The cardholder data
environment is that part of the network that possesses cardholder
data or sensitive authentication data. Network
components include but are not limited to firewalls, switches,
routers, wireless access points, network appliances, and other
security appliances. Server types include, but are not limited to
the following: web, database, authentication, mail, proxy,
network time protocol (NTP), and domain name server (DNS).
Applications include all purchased and custom applications,
including internal and external (internet)
applications.
Adequate network segmentation, which isolates systems that
store, process, or transmit cardholder data from the rest of
the network, may reduce the scope of the cardholder data
environment. The assessor must verify that the segmentation is
adequate to reduce the scope of the audit.
A service provider or merchant may use a third party
provider to manage components such as routers, firewalls,
databases,
physical security, and/or servers. If so, there may be an impact
on the security of the cardholder data environment. The
relevant services of the third party provider must be scrutinized
either in 1) each of the third party provider's clients' PCI
audits; or 2) the third party provider's own PCI
audit.
For service providers required to undergo an annual onsite
review, compliance validation must be performed on all system
components where cardholder data is stored, processed, or
transmitted, unless otherwise specified.
For merchants required to undergo an annual onsite review,
the scope of compliance validation is focused on any
system(s) or system component(s) related to authorization and
settlement where cardholder data is stored, processed, or
transmitted, including the following:
·
All external connections into the merchant network (for
example; employee remote access, payment card
company,
third party access for processing, and
maintenance)
·
All connections to and from the authorization and settlement
environment (for example, connections for
employee
access or for devices such as firewalls and
routers)
·
Any data repositories outside of the authorization and
settlement environment where more than 500 thousand
account
numbers are stored. Note: Even if some data repositories or
systems are excluded from the audit, the merchant is still
responsible for ensuring that all systems that store, process, or
transmit cardholder data are compliant with the PCI
DSS
·
A point-of-sale (POS) environment the place where a
transaction is accepted at a merchant location (that is,
retail
store, restaurant, hotel property, gas station, supermarket,
or other POS location)
·
If there is no external access to the merchant location (by
Internet, wireless, virtual private network (VPN),
dial-in,
broadband, or publicly accessible machines such as kiosks),
the POS environment may be excluded
Security Audit Procedures v 1.1
5
Wireless
If wireless technology is used to store, process, or
transmit cardholder data (for example, point-of-sale transactions,
"line-
busting"), or if a wireless local area network (LAN) is connected
to or part of the cardholder environment (for example, not
clearly separated by a firewall), the Requirements and Testing
Procedures for wireless environments apply and must be
performed as well. Wireless security is not mature yet, but these
requirements specify that basic wireless security features
be implemented to provide minimal protection. Since wireless
technologies cannot yet be secured well, before wireless
technology is put in place, a company should carefully evaluate
the need for the technology against the risk. Consider
deploying wireless technology only for non-sensitive data
transmission or waiting to deploy more secure
technology.
Outsourcing
For those entities that outsource storage, processing, or
transmission of cardholder data to third party service providers,
the
Report on Compliance must document the role of each service
provider. Additionally, the service providers are responsible
for validating their own compliance with the PCI DSS requirements,
independent of their customers' audits. Additionally,
merchants and service providers must contractually require all
associated third parties with access to cardholder data to
adhere to the PCI DSS. Refer to Requirement 12.8 in this
document for details.
Sampling
The assessor may select a representative sample of system
components to test. The sample must be a representative
selection of all of the types of system components, and include a
variety of operating systems, functions, and applications
that are applicable to the area being reviewed. For example, the
reviewer could choose Sun servers running Apache
WWW, NT servers running Oracle, mainframe systems running legacy
card processing applications, data transfer servers
running HP-UX, and Linux Servers running MYSQL. If all
applications run from a single OS (for example, NT, Sun), then
the sample should still include a variety of applications (for
example, database servers, web servers, data transfer
servers).
When selecting samples of merchants' stores or for
franchised merchants, assessors should consider the
following:
·
If there are standard, required PCI DSS processes in place
that each store must follow, the sample can be smaller
than
is necessary if there are no standard processes, to provide
reasonable assurance that each store is configured per the
standard process.
·
If there is more than one type of standard process in place
(for example, for different types of stores), then the
sample
must be large enough to include stores secured with each type
of process.
·
If there are no standard PCI DSS processes in place and each
store is responsible for their processes, then
sample
size must be larger to be assured that each store understands
and implements PCI DSS requirements
appropriately.
Compensating Controls
Compensating controls must be documented by the assessor and
included with the Report on Compliance submission, as
shown in Appendix C Compensating Controls Worksheet /
Completed Example.
Security Audit Procedures v 1.1
6
See PCI DSS Glossary, Abbreviation, and Acronyms for the
definitions of "compensating controls."
Instructions and Content for Report on
Compliance
This document is to be used by assessors as the template for
creating the Report on Compliance. The audited entity
should
follow each payment card company's respective reporting
requirements to ensure each payment card company
acknowledges the entity's compliance status. Contact each payment
card company to determine each company's reporting
requirements and instructions. All assessors must follow the
instructions for report content and format when completing a
Report on Compliance:
1.
Conta
2. Exec
3. Desc
ct Information and Report Date
·
Include contact information for merchant or service provider
and assessor
·
Date of report
utive Summary
Include the following:
·
Business
description
·
List service providers and other entities with which the
company shares cardholder data
·
List processor relationships
·
Describe whether entity is directly connected to payment card
company
·
For merchants, POS products used
·
Any wholly-owned entities that require compliance with the
PCI DSS
·
Any international entities that require compliance with the
PCI DSS
·
Any wireless LANs and/or wireless POS terminals connected to
the cardholder environment
ription of Scope of Work and Approach
Taken
·
Version of the Security Audit Procedures document used to
conduct the assessment
·
Timeframe of assessment
·
Environment on which assessment focused (for example,
client's Internet access points, internal corporate network,
processing
points for the payment card company)
·
Any areas excluded from the review
·
Brief description or high-level drawing of network topology
and controls
·
List of individuals interviewed
·
List of documentation reviewed
Security Audit Procedures v 1.1
7
·
List of hardware and critical (for example, database or
encryption) software in use
·
For Managed Service Provider (MSP) reviews, clearly delineate
which requirements in this document apply to the MSP (and
are
included in the review), and which are not included in the
review and are the responsibility of the MSP's customers to include
in
their reviews. Include information about which of the MSP's IP
addresses are scanned as part of the MSP's quarterly
vulnerability
scans, and which IP addresses are the responsibility of the MSP's
customers to include in their own quarterly scans
4. Quart
5. Findi
erly Scan Results
·
Summarize the four most recent quarterly scan results in
comments at Requirement 11.2
·
Scan must cover all externally accessible (Internet-facing)
IP addresses in existence at the
entity
ngs and Observations
·
All assessors must use the following template to provide
detailed report descriptions and findings on each requirement
and sub-requirement
·
Where applicable, document any compensating controls
considered to conclude that a control is in place
See
for the definitions of "compensating
controls."
·
PCI DSS Glossary, Abbreviation, and
Acronyms
Revalidation of Open Items
A "controls in place" report is required to verify
compliance. If the initial report by the auditor/assessor contains
"open
items," the merchant/service provider must address these items
before validation is completed. The assessor/auditor will
then reassess to validate that the remediation occurred and that
all requirements are satisfied. After revalidation, the
assessor will issue a new Report on Compliance, verifying
that the system is fully compliant and submit it consistent
with
instructions (See above.).
Build and Maintain a Secure
Network
Requirement 1: Install and maintain a firewall
configuration to protect cardholder data
Firewalls are computer devices that control computer traffic
allowed into and out of a company's network, as well as traffic
into more sensitive areas within a company's internal network. A
firewall examines all network traffic and blocks those
transmissions that do not meet the specified security
criteria.
All systems must be protected from unauthorized access from
the Internet, whether entering the system as e-commerce,
employees' Internet-based access through desktop browsers, or
employees' e-mail access. Often, seemingly insignificant
paths to and from the Internet can provide unprotected pathways
into key systems. Firewalls are a key protection
mechanism for any computer network.
Security Audit Procedures v 1.1
8
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
TARGET DATE/
PLACE
COMMENTS
1.1
ion
da
1.1 Obtain and insp
standards
Establish firewall configurat
stan rds that include the following:
ect the firewall configuration
and other documentation specified below to verify
that
standards are complete. Complete each item in this
section
1.1.1 A formal process for
approving an
ernal
to
d testing all ext
network connections and changes
the firewall configuration
1.1.1 Verify that firewall configuration standards
include a
formal process for all firewall changes, including testing
and
management approval of all changes to
external
connections and firewall configuration
1.1.2.a Verify that a current network diagram exists
and
a,
verify that it documents all connections to cardholder
dat
including any wireless networks
1.1.2 A current network diagram
with all connections to cardholder
data, including any wireless networks
kept current
1.1.2.b. Verify that the diagram
is
1.1.3 Requirements for a firewall
at
one
dards include
each Internet connection and
between any demilitarized zone
(DMZ) and the internal network z
1.1.3 Verify that firewall configuration
stan
requirements for a firewall at each Internet connection
and
between any DMZ and the Intranet. Verify that the
current
network diagram is consistent with the firewall
configuration
standards.
1.1.4 Description of groups,
roles,
y that firewall configuration standards include
a
p
and responsibilities for logical
management of network components
1.1.4 Verif
descri tion of groups, roles, and responsibilities for
logical
management of network components
1.1.5 Documented list of services
and ports necessary for business
1.1.5 Verify that firewall configuration standards
include a
documented list of services/ports necessary for business
1.1.6 Justification
and
documentation for any ava
protocols besides hypertext trans
protocol (HTTP), and secure sockets
layer (SSL), secure shell (SSH), and
virtual private network (VPN)
ilable
fer
e
1.1.6 Verify that firewall configuration standards
includ
justification and documentation for any available
protocols
besides HTTP and SSL, SSH, and VPN
1.1.7.a Verify that firewall configuration standards
include
justification and documentation for any risky
protocols
allowed (for example, FTP), which includes reason for
use
of protocol, and security features implemented
1.1.7 Justification and
documentation for any ri
allowed (for example, file transfer
protocol (FTP), which includes reason
for use of protocol and security
features implemented
sky protocols
r each
service in use to obtain evidence that the service
is
necessary and secured
1.1.7.b Examine documentation and settings
fo
Security Audit Procedures v 1.1
9
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
1.1.8.a Verify that firewall configuration standards
req
quarterly review of firewall and router rule sets
uire
1.1.8 Quarterly review of firew
and router rule sets
all
e rule sets are reviewed each quarter
1.1.8.b Verify that th
1.1.9 Configuration standards for
routers
ds exist for
1.1.9 Verify that firewall configuration
standar
both firewalls and routers
1.2
Build a firewall configuration that
d
n
p
necessary for the cardholder
data enviro
1.2
Int
an
int
at
r and firewall, the DMZ
ho
enies all traffic from "untrusted"
etworks and hosts, except for
rotocols
nment.
Select a sample of firewalls/routers 1) between
the
ernet d the DMZ and 2) between the DMZ and
the
ernal network. The sample should include the choke
router
the Internet, the DMZ route
card lder segment, the perimeter router, and the
internal
cardholder network segment. Examine firewall and
router
configurations to verify that inbound and outbound traffic
is
limited to only protocols that are necessary for the
cardholder
data environment
1.3
Build a firewall configuration that
restricts connections between publicly
accessible servers and any system
component storing cardholder data,
di
inclu ng any connections from
wireless networks. This firewall
configuration should include:
1.3 Examine
firewall/router
configurations to verify that
connections are restricted between publicly
accessible
servers and components storing cardholder data, as
follows:
1.3.1 Restricting inbound
Internet
traffic to internet protocol (IP)
addresses within the DMZ (ing
filters)
ress
1.3.1 Verify that inbound Internet traffic is limited
to IP
addresses within the DMZ
1.3.2 Not allowing internal
addresses to pass from the Int
into the DMZ
ernet
1.3.2 Verify that internal addresses cannot pass from
the
Internet into the DMZ
1.3.3 Implementing statefu
inspection, also known as dynamic
packet filtering (that is, only
"established"
l
connections are allowed
and only if they are associated with a
previously established session (run NMAP on all TCP
ports
into the network)
1.3.3 Verify that the firewall performs stateful
inspection
(dynamic packet filtering). [Only established
connections
should be allowed in,
with "syn reset" or "syn ack" bits set a response
means
packets are allowed through even if they are not part of
a
previously established session)]
1.3.4 Placing the database in an
1.3.4 Verify that the database is on an internal
network
Security Audit Procedures v 1.1
10
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
internal network z
from the DMZ
one, segregated
zone, segregated from the DMZ
1.3.5 Restricting inbound and
tbound traffic is limited to
that which is
nd
outbound traffic to that which is
necessary for the cardholder data
environment
1.3.5 Verify that inbound and ou
necessary for the cardholder environment,
a
that the restrictions are documented
1.3.6 Securing and synchroniz
router configuration files. For
example, running configuration file
(for normal functioning of the route
and start-up
ing
s
rs),
configuration files (when
e
ooted), have the same,
secure configurations]
machines are re-booted) should hav
the same secure configuration
1.3.6 Verify that router configuration files are
secure and
synchronized [for example, running configuration files
(used
for normal running of the routers) and start-up
configuration
files (used when machines are re-b
1.3.7 Denying all other inbound
and
outbound traffic not specifically
allowed
1.3.7 Verify that all other inbound and outbound
traffic not
covered in 1.2 and 1.3 above is specifically denied
1.3.8 Installing perimeter
firewalls
e
from the wireless
1.3.8 Verify that there are perimeter firewalls
installed
e
from the wireless environment into systems
storing
betwe n any wireless networks and
the cardholder data environment, and
configuring these firewalls to deny
any traffic
environment or from controlling any
traffic (if such traffic is necessary for
business purposes)
betwe n any wireless networks and systems that
store
cardholder data, and that these firewalls deny or control
(if
such traffic is necessary for business purposes) any
traffic
cardholder data
1.3.9 Installing personal
firewall
software on any mobile and
employee-owned computers with
direct connectivity to the Internet (for
example, laptops used by
work.
r
sed by employees), and which are used
to access the organization's network, have personal
firewall
software installed and active, which is configured by
the
y the
employees), which are used to
access the organization's net
1.3.9 Verify that mobile and/or
employee-owned
computers with direct connectivity to the Internet
(fo
example, laptops u
organization to specific standards and not alterable
b
employee
1
b
s
c
d
1
p
d
fi
al network:
.4
Prohibit direct public access
etween external networks and any
ystem component that stores
ardholder data (for example,
atabases, logs, trace files).
.4
To determine that direct access between
external
ublic networks and system components storing
cardholder
ata are prohibited, perform the following,
specifically for the
rewall/router configuration implemented between the
DMZ
and the intern
1.4.1 Implement a DMZ to filter a
screen all traffic and to prohibit dire
nd
ct
1.4.1 Examine firewall/router configurations and
verify
there is no direct route inbound or outbound for
Internet
Security Audit Procedures v 1.1
11
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
routes for inbound and outbo
Internet traffic
und
traffic
1.4.2 Restrict outbound traffic
from
payment card applications to IP
addresses within the DMZ.
1.4.2 Examine firewall/router configurations and
verify t
internal outbound traffic from cardholder applications
can
only access IP addresses within the DMZ
hat
1
g to
p
tr
U
FC
1.5
For the sample of firewall/router components
above,
v
s
in
.5
Implement IP masqueradin
i
revent nternal addresses from being
anslated and revealed on the Internet.
se technologies that implement R
918 address space, such
1
as port
address translation (PAT) or network
address translation (NAT).
erify that NAT or other technology using RFC 1918
address
pace is used to restrict broadcast of IP addresses from
the
ternal network to the Internet (IP
masquerading)
endor-supplied defaults for system passwords and other
security parameters.
Hackers (external and internal to a company) often use
vendor default passwords and other vendor default settings to
compromise systems. These passwords and settings are well known in
hacker communities and easily determined via
Requirement 2: Do not use v
public information.
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
2.1 Always chang
defaults before
the network (for example, include
pass
2.1
Choose a sample of system components,
critical
servers, and wireless access points, and attempt to log
on
(with system administrator help) to the devices using
default
vendor-supplied a
verify that
default accounts and passwords have been changed.
(Use
vendor m
or-
e vendor-supplied
installing a system on
words, simple network
management protocol (SNMP)
community strings, and elimination of
unnecessary accounts).
ccounts and passwords, to
anuals and sources on the Internet to find
vend
supplied accounts/passwords.)
2.1.1 For
wireless
environ
change wireless vendor defaults,
including but not limited to, wireless
equivalent privacy (WEP)
ments,
keys,
default service set identifier (SSID),
s
changed anytime any one with
passwords, and SNMP community
2.1.1 Verify the following regarding vendor default
setting
for wireless environments:
·
WEP keys were changed from default at
installation, and are
knowledge of the keys leaves the company
or
changes positions
Security Audit Procedures v 1.1
12
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
strings. Disable SSID broadcasts.
Enable WiFi protected access (WPA
and WPA2) technology for encryptio
and authentication when WPA-
capable.
n
·
ints
s points were changed
if the
·
elated wireless vendor defaults, if
·
Default SSID was changed
·
Broadcast of the SSID was disabled
Default SNMP community strings on access
po
were changed
·
Default passwords on acces
·
WPA or WPA2 technology is enabled
wireless system is WPA-capable
Other security-r
applicable
2.2.a
n
standards
rvers, and
wirele
c
standards
r
IS
Examine the organization's system
configuratio
for network components, critical se
ss a cess points, and verify the system
configuration
are consistent with industry-accepted
hardening
standa ds as defined, for example, by SANS, NIST, and
C
2.2.b Verify that system configuration standards
include
each item below (at 2.2.1 2.2.4)
2.2
Develop configuration standards
for all system components. Assure that
these standards address all known
security vulnerabilities and are
is
ards
cons tent with industry-accepted
system hardening standards as
defined, for example, by SysAdmin
Audit Network Security Network
(SANS), National Institute of Stand
Technology (NIST), and Center for
Internet Security (CIS).
2.2.c Verify that system configuration standards are
applied
when new systems are configured
2.2.1 Implement only one primary
function per server (for example, w
servers, database serv
eb
ers, and DNS
should be implemented on separate
2.2.1 For a sample of system components, critical
servers,
servers)
and wireless access points, verify that only one
primary
function is implemented per server
2.2.2 Disable all unnecessary and
insecure services and protocols
(services and protocols not directly
needed to perform the devices'
specified function)
2.2.2 For a sample of system components, critical
servers,
and wireless access points, inspect enabled
system
services, daemons, and protocols. Verify that
unnecessary
or insecure services or protocols are not enabled, or
are
justified and documented as to appropriate use of
the
service (for example, FTP is not used, or is encrypted
via
SSH or other technology)
2.2.3 Configure
system
security
parameters to prevent misuse
2.2.3.a Interview system administrators and/or
security
managers to verify that they have knowledge of
common
security parameter settings for their operating
systems,
database servers, Web servers, and wireless
systems
Security Audit Procedures v 1.1
13
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
2.2.3.b Verify that common security parameter
settings
included in the system configuration standards
are
2.2.3.c For a sample of system components,
critical
servers, and wireless access points, verify that
common
security parameters are set appropriately
2.2.4 Remove all unnecessary
functionality, such as scripts, drivers,
features, subsystems, file systems,
and unnecessary web servers.
nts, critical
s
Verify
ort secure
uratio
2.2.4
For a sample of system compone
server , and wireless access points,, verify that
all
unnecessary functionality (for example, scripts,
drivers,
features, subsystems, file systems, etc.) is
removed.
enabled functions are documented, supp
config
n, and that only documented functionality
is
present on the sampled machines
2
technologies such as SSH, VPN, or
SSL/TLS (transport layer security) for
web-based management and other
ss.
2.3
an
ad
m
ireless
management of wireless
.3
Encrypt all non-console
administrative access. Use
non-console administrative acce
For a sample of system components, critical
servers,
d wireless access points,, verify that
non-console
ministrative access is encrypted by:
·
Observing an administrator log on to each
syste
to verify that SSH (or other encryption method)
is
invoked before the administrator's password
is
requested
·
Reviewing services and parameter files on
systems to determine that Telnet and other
remote
log-in commands are not available for use
internally
Verifying that admini
·
strator access to the w
management interface is encrypted with
SSL/TLS.
Alternatively, verify that administrators
cannot
connect remotely to the wireless
management
interface (all
environments is only from the console)
2.4
Hosting providers must protect
each entity's hosted environment and
data. These providers must meet
specific requirements as detailed in
Appendix A: "PCI DSS Applicability for
2.4
Per
detailed in
Providers (
Hosting P
Providers
protect the
ers)
Hosting Providers."
form testing procedures A.1.1 through
A.1.4
Appendix A, "PCI DSS Applicability for
Hosting
with Testing Procedures)" for PCI audits of
Shared
roviders, to verify that Shared
Hosting
ir entities' (merchants and service
provid
hosted environment and data.
Security Audit Procedures v 1.1
14
Protect Cardholder Data
otect stored
Encryption is a critical component of cardholder data
protection. If an intruder circumvents other network security
controls
and gains access to encrypted data, without the proper
cryptographic keys, the data is unreadable and unusable to that
person. Other effective methods of protecting stored data should
be considered as potential risk mitigation opportunities.
For example, methods for minimizing risk include not storing
cardholder data unless absolutely necessary, truncating
cardholder data if full PAN is not needed, and not sending PAN in
unencrypted e-mails.
Requirement 3: Pr
cardholder data
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
3.1
Keep cardholder data storage
to a minimum. Develop a data
retention and disposal policy. Limit
storage amount and retention time to
that which is required for business,
legal, and/or regulatory purposes, as
documented in the data retention
policy.
3.1
Obtain and examine the company policies
and
procedures for data retention and disposal, and perform
the
following
·
Verify that policies and procedures include
legal,
regulatory, and business requirements for
data
retention, including specific requirements
for
retention of cardholder data (for
example,
cardholder data needs to be held for X period for
Y
business reasons)
·
Verify that policies and procedures
include
provisions for disposal of data when no
longer
needed for legal, regulatory, or business
reasons,
including disposal of cardholder data
·
Verify that policies and procedures
include
coverage for all storage of cardholder
data,
including database servers, mainframes,
transfer
directories, and bulk data copy directories used
to
transfer data between servers, and
directories
used to normalize data between server
transfers
·
Verify that policies and procedures include
A
programmatic (automatic) process to remove,
at
least on a quarterly basis, stored cardholder
data
that exceeds business retention requirements,
or,
alternatively, requirements for an audit,
conducted
at least on a quarterly basis, to verify that
stored
cardholder data does not exceed business
retention requirements
Security Audit Procedures v 1.1
15
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
3.2
Do not store sensitive
Sensitive authentic
the data as cited in
Requirements 3.2.
3.2
If sensitive authentication data is received and
deleted,
rocesses for deleting the data to verify
ble
authentication data subsequent to
authorization (even if encrypted).
obtain and review the p
that the data is unrecovera
ation data includes
the following
1 through 3.2.3:
For each item of sensitive authentication data below,
perform
the following steps:
3.2.1 Do not sto
of any track fro
stripe (that is on the back of a card,
in a chip or elsewhere). This data is
track 1, track 2, and magnetic stripe
e
,
,
ration date, and service code.
To minimize risk, store only those
data elements needed for business.
NEVER store the card verification
code or value or PIN verification
value data elements.
Note: See "Glossary" for additional
information.
that the full contents of any track from the magnetic stripe
on
the back of card are not stored under any
circumstance:
·
Incom
·
·
re the full contents
m the magnetic
3.2.1 For a sample of system components, critical
servers,
and wireless access points, examine the following and
verify
alternatively called full track, track,
data
In the normal course of business,
the following data elements from th
magnetic stripe may need to be
retained: the accountholder's name
primary account number (PAN)
expi
ing transaction data
·
Transaction
logs
·
History
files
·
Trace
files
·
Debugging
logs
Several database schemas
Database
contents
3.2.2 Do not store the card-
validation value or code (three-digit
or four-digit number printed on the
front or back of a payment card) used
to verify card-not-present
transactions
Note: See "Glossary" for
additional
information.
3.2.2 F
and wirel
rify
that the t
on th ro
VC2,
CID, CAV
·
·
·
·
·
or a sample of system components, critical
servers,
ess access points, examine the following and
ve
hree-digit or four-digit card-validation code
printed
e f nt of the card or the signature panel (CVV2,
C
2 data) is not stored under any
circumstance:
Incoming transaction data
Transaction
logs
History
files
Trace
files
Debugging
logs
Security Audit Procedures v 1.1
16
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
·
Several database schemas
·
Database
contents
3.2.3 Do not store the personal
m components, critical servers,
·
hemas
nts
identification number (PIN) or the
encrypted PIN block.
3.2.3 For a sample of syste
and wireless access points, examine the following and
verify
that PINs and encrypted PIN blocks are not stored under
any
circumstance:
Incoming transaction data
·
Transaction
logs
·
History
files
·
Trace
files
·
Debugging
logs
·
Several database sc
·
Database
conte
3.
e
fir
m
di
N
ply
to
sp
do
st
di
ex
[POS]
re
3.3
e written policies and examine
online
ata to verify that credit card
numbe
ardholder data, except
for tho
credit card numbers
3
Mask PAN when displayed (th
st six and last four digits are the
aximum number of digits to be
splayed).
ote: This requirement does not ap
employees and other parties with
a
ecific need to see the full PAN;
nor
es the requirement supersede
ricter requirements in place for
splays of cardholder data (for
ample, for point of sale
ceipts).
Obtain and examin
displays of credit card d
rs are masked when displaying c
se ith a specific need to see full
w
Security Audit Procedures v 1.1
17
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
3.4.a
ion about the system
used t
the vendor, type of
system/p
n algorithms (if applicable).
V
f
·
th the PADs being securely
·
hy, such as Triple-DES 128-bit or
ciated key management
Obtain and examine documentat
luding
o protect stored data, inc
rocess, and the encryptio
erify that data is rendered unreadable using one of
the
ollowing methods:
·
One-way hashes (hashed indexes) such as
SHA-1
·
Truncation or masking
s, wi
Index tokens and PAD
stored
p
Strong cryptogra
AES 256-bit, with asso
processes and procedures
3.4.b
a sample of database
server
red unreadable (that is, not
d
Examine several tables
s to verify the data is rende
from
store in plain text)
3.4.c Examine a sample of removable media (for
example,
backup tapes) to confirm that cardholder data is
rendered
unreadable
3.4.d Examine a sample of audit logs to confirm
that
cardholder data is sanitized or removed from the logs
3.4
Render PAN, at minimum,
unreadable anywhere it is stored
(including data on portable digital
m
b
d
w
ing any of the
following approaches:
·
Strong one-way hash
functions (hashed indexes)
·
Truncation
·
Index tokens and pads (pads
must be securely stored)
·
Strong cryptography with
associated key management
e is
3.4.e Verify that cardholder data received from
wireless
networks is rendered unreadable wherever stored
edia, ackup media, in logs, and
ata received from or stored by
ireless networks) by us
processes and procedures
The MINIMUM account information
that must be rendered unreadabl
the PAN.
If for some reason, a company is
unable to encrypt cardholder data,
refer to Appendix B: "Compensating
Controls."
3.4.1.a If disk encryption is used, verify that
logical access
to encrypted file systems is implemented via a
mechanism
that is separate from the native operating
systems
mechanism (for example, not using local or Active
Directory
accounts)
3.4.1 If disk encryption is used
(rather than file- or column-level
database encryption), logical
access must be managed
independently of native operating
system access control mechanisms
(for example, by not using local
system or Active Directory
accounts). Decryption keys must
3.4.1.b Verify that decryption keys are not stored on
the
local system (for example, store keys on floppy disk,
CD-
ROM, etc. that can be secured and retrieved only
when
needed)
Security Audit Procedures v 1.1
18
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
not be tied to user accounts.
3.4.1.c Verify that cardholder data on removable
media is
encrypted wherever stored (disk encryption often
cannot
encrypt removable media)
3.5
Protect encryption keys used
for encryption of cardholder data
against both disclosure and misuse:
older data against disclosure and misuse
by
fo
3.5 Verify processes to protect encryption keys used
for
encryption of cardh
per rming the following:
3.5.1 Restrict access to key
fewe t number of custodians
sary
s to the
s
neces
s to verify that access to
cr
o
3.5.1 Examine user access list
ypt graphic keys is restricted to very few
custodians
3.5.2 Store keys securely in the
we possible locations and forms
fe
st
crypto
that
key-e
parately from data-
3.5.2 Examine system configuration files to verify
that
graphic keys are stored in encrypted format
and
ncrypting keys are stored se
encrypting keys
3.6.a Verify the existence of key management
procedures fo
keys used for encryp
r
tion of cardholder data
3.6.b For Service Providers only: If the
Service Provider
shares keys with their customers for transmission
of
cardholder data, verify that the Service Provider
provides
how to
(used
to transmit data between customer and service provider)
documentation to customers that includes guidance
on
securely store and change customer's encryption
keys
3.6
t
all key mana
following:
Fully document and implemen
gement processes and
procedures for keys used for
encryption of cardholder data,
including the
3.6.c Examine the key management procedures and
perform the following:
3.6.1 Generation of strong keys
3.6.1 Verify that key management procedures require
the
generation of strong keys
3.6.2 Secure key distribution
3.6.2 Verify that key management procedures
require
secure key distribution
3.6.3 Secure key storage
3.6.3 Verify that key management procedures
require
secure key storage
Security Audit Procedures v 1.1
19
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
3.6.4 Periodic key changes
·
As deemed necessary and
recommended by the
associated application (for
V
example, re-keying);
preferably automatically
·
At least annually
3.6.4
erify that key management procedures
require
periodic key changes. Verify that key change procedures
are
carried out at least annually
3.6.5 Destruction of old keys.
3.6.5 Verify that key management procedures require
th
destruction of old keys
e
3.6.6 Split knowledge and
ys
people, each knowing only their part
of the key, to reconstruct the whole
y
3.6.6 Verify that key management procedures require
split
o or
establishment of dual control of ke
(so that it requires two or three
ke
knowledge and dual control of keys (so that it requires
tw
three people, each knowing only their part of the key,
to
reconstruct the whole key)
3.6.7 Prevention of unauthorized
substitution of keys
3.6.7 Verify that key management procedures require
the
prevention of unauthorized substitution of keys
3.6.8 Replacement of know
suspected compromise
n or
d keys
3.6.8 Verify that key management procedures require
the
replacement of known or suspected compromised keys
3.6.9 Revocation of old or
invalid
keys
3.6.9 Verify that key management procedures require
the
revocation of old or invalid keys (mainly for RSA keys)
3.6.10 Requirement for key
custodians to sign a form stating that
they understand and accept their
re key
stodia
nd
key-custodian responsibilities
3.6.10 Verify that key management procedures
requi
cu
ns to sign a form specifying that they
understa
and accept their key-custodian responsibilities
Security Audit Procedures v 1.1
20
Req
ansmission of car
open, public
ormation
ks that
sy an
on f
cker to
and
uirement 4: Encrypt tr
dholder data across
networks
Sensitive inf
must be encrypted during transmission over networ
divert data while in transit.
are ea
d comm
or a ha
intercept, modify,
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
4.1
e
hy and
s
ckets layer
security (TLS) and internet protocol
s
s
tr
n
that are in scope of the PCI DSS are
t
ile
al
4.1.a Verify the use of encryption (for example,
SSL/TLS or
I
o
rdholder data is required when
HTTPS does not appear in the URL
Us strong cryptograp
ecurity protocols such as secure
so
(SSL) / transport layer
ecurity (IPSEC) to safeguard
ensitive cardholder data during
ansmission over open, public
etworks.
Examples of open, public networks
he Internet, WiFi (IEEE 802.11x),
global system for mob
communications (GSM), and gener
packet radio service (GPRS).
PSEC) wherever cardholder data is transmitted or
received
ver open, public networks
·
Verify that strong encryption is used during
data
transmission
·
For SSL implementations, verify that HTTPS
appears
as a part of the browser Universal Record Locator
(URL), and that no ca
·
Select a sample of transactions as they are
received
and observe transactions as they occur to verify that
cardholder data is encrypted during transit
·
Verify that only trusted SSL/TLS keys/certificates
are
accepted
·
Verify that the proper encryption strength
is
implemented for the encryption methodology in use
(Check vendor recommendations/best practices)
4.1.1 For
wireless
networks
ransmitting cardholder data,
encrypt the transmissions by using
t
WiFi protected access (WPA or
WPA2) technology, IPSEC VPN, or
SSL/TLS. Never rely exclusively on
wired equivalent privacy (WEP) to
protect confidentiality and access to a
wireless LAN.
ardholder
data or connected to cardholder environments, verify
that
appropriate encryption methodologies are used for
any
wireless transmissions, such as: Wi-Fi Protected
Access
(WPA or WPA2), IPSEC VPN, or SSL/TLS
4.1.1.a For wireless networks transmitting
c
Security Audit Procedures v 1.1
21
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
If WEP is used, do the following:
4.1.1.b If WEP is used, verify
·
Use with a mi
encryption ke
initialization value
·
W
es in
nel with access to keys
ey and 24 bit-initialization
value
·
it is used only in conjunction with Wi-Fi
WPA2)
e)
r
there are changes in personnel with
access
ess
nimum 104-bit
y and 24 bit-
·
it is used with a minimum 104-bit
encryption k
Use ONLY in conjunction with
WiFi protected access (WPA or
PA2) technology, VPN, or
SSL/TLS
·
Rotate shared WEP keys
quarterly (or automatically if the
technology permits)
·
Rotate shared WEP keys
whenever there are chang
person
·
Restrict access based on media
access code (MAC) address
Protected Access (WPA or
technology, VPN, or SSL/TLS
·
shared WEP keys are rotated at least
quarterly (or automatically if the
technology
is capabl
·
shared WEP keys are rotated wheneve
to keys
·
access is restricted based on MAC addr
4.2.a
whenev
Verify that an email encryption solution is
used
er cardholder data is sent via email
4.2.
unencry
is not to be sent via email
b Verify the existence of a policy stating
that
pted PAN
4.2
Never send unencrypted P
by e-mail.
ANs
4.2.c
encrypt
Interview 3-5 employees to verify that
email
ion software is required for emails containing PANs
Security Audit Procedures v 1.1
22
Maintain a Vulnerability Management
Program
q
egularly updat an
s
vulnerabilities and malicious vir
s' e-mail activities. Anti-virus software must
be
ems commonly ect
malicious software.
Re uirement 5: Use and r
Many
e
ti-virus software or program
uses enter the network via employee
aff
ed by viruses to protect systems from
used on all syst
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
5.1
syst
ted by
viruse
c m
Not
y
bas
nfr
5.1
For a
mp
and wirele
installed
Deploy anti-virus software on all
ems commonly affec
s (particularly personal
o puters and servers)
e: Systems commonly affected b
viruses typically do not include
UNIX-
ed operating systems or
mai
ames.
sa
le of system components, critical
servers,
ss access points, verify that anti-virus software
is
5.1.1 Ensure that anti-virus
programs are capable of detecting,
removing, and protecting against
other forms of malicious software,
including spyware and adware.
critical servers,
i
ograms
s software,
5.1.1 For a sample of system
components,
and w reless access points, verify that anti-virus
pr
detect, remove, and protect against other
maliciou
including spyware and adware
5.2 Ensure that all anti-virus
mechanisms are current, actively
running, and capable of generating
audit logs.
running, and capable of generating logs
·
Obtain and examine the policy and verify that
is
contains requirements for updating anti-virus software
and definitions
·
Verify that the master installation of the software
is
enabled for automatic updates and periodic scans,
and that a sample of system components, critical
servers, and wireless access points servers have
these features enabled
·
Verify that log generation is enabled and that logs
are
retained in accordance with company retention
policy
5.2
Verify that anti-virus software is current,
actively
Security Audit Procedures v 1.1
23
Requirement 6: Develop and maintain secure systems and
applications
privileged access to systems. Many of these vulnerabilities
are
t have the most recently released, appropriate software
patches
Note: Appropriate software patches are
those
s do not conflict with existing security
Unscrupulous individuals use security vulnerabilities to
gain
fixed by vendor-provided security patches. All systems mus
to protect against exploitation by employees, external hackers, and
viruses.
patches that have been evaluated and tested sufficiently to
determine that the patche
configurations. For in-house developed applications, numerous
vulnerabilities can be avoided by using standard system
development processes and secure coding
techniques.
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
TARGET DATE/
PLACE
COMMENTS
6.1.a For a sample of system components, critical
servers,
e
ndor security patch list, to verify that current
vendor
patches are installed
and wireless access points and related software, compare
th
list of security patches installed on each system to the
most
recent ve
6.1
Ensure that all system
atches
ty
of release.
6.1.b Examine policies related to security patch
installation to
verify they require installation of all relevant new
security
patches within 30 days
components and software have the
latest vendor-supplied security p
installed. Install relevant securi
patches within one month
6.2.a Interview responsible personnel to verify
that
processes are implemented to identify new
security
vulnerabilities
6.2
Establish a process to identify
ne
vu
to
e
In
s
ne
outside sources for security
vulnerability information and updating the system
configuration
ty
wly discovered security
lnerabilities (for example, subscribe
alert services freely available on th
ternet). Update standards to addres
w vulnerability issues.
6.2.b Verify that processes to identify new
security
vulnerabilities include use of
standards reviewed in Requirement 2 as new
vulnerabili
issues are found
6.3
Develop software applications
based on industry best practices and
corporate information security
throughout the software development
life cycle.
6.3
process
and tha
ded throughout the life cycle
process
examin
docume
in
Obtain and examine written software
development
es to verify that they are based on industry
standards
t security is inclu
From an examination of written software
development
es, interviews of software developers,
and
ation of relevant data (network
configuration
ntation, production and test data, etc.), verify
that:
6.3.1 Testing of all security
patches
and system and software
configuration changes before
deployment
6.3.1
atches) are tested before
be g
All changes (including p
in deployed into production
Security Audit Procedures v 1.1
24
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
6.3.2 Separate
and production e
development, test,
nvironments
6.3.2 The test/development environments are
separate
from the production environment, with access control
in
place to enforce the separation
6.3.3 Separatio
development, tes
environments
n of duties between
t, and production
6.3.3 There is a separation of duties between
personnel
assigned to the development/test environments and
those
assigned to the production environment
6.3.4 Production data (live PANs)
are not used for testing or
dev
6.3.4 Production data (live PANs) are not used for
testing
and development, or are sanitized before use
elopment
6.3.5
and
s
Removal of test data
accounts before production system
become active
6.3.5 Test data and accounts are removed before
a
production system becomes active
6.3.6 Removal of custom
application accounts, usernames,
and passwords before applications
become active or are released to
customers
ved before system goes into production
6.3.6 Custom application accounts, usernames
and/or
passwords are remo
or is released to customers
6.3.7.a Obtain and review any written or other
po
confirm that code reviews are required and must
be
performed by individuals other then originating code
a
licies to
uthor
6.3.7
s
de
ent
C) these reviews can be conducted
by
internal p
s
Review of custom code prior
to release to production or customer
in order to identify any potential
coding vulnerability.
6.3.7.b Verify code reviews are conducted for new
co
and after code changes
Note: This requirement applies to code reviews for
custom
software development, as part of the System
Developm
Life Cycle (SDL
ersonnel. Custom code for web-facing
application
will be subject to additional controls as of June 30,
2008
see PCI DSS requirement 6.6 for details.
6.4 Follow
change
control
procedures for all system and software
configuration changes. The procedures
must include the following:
and
ire
6.4.a Obtain and examine company
change-control
procedures related to implementing security
patches
software modifications, and verify that the procedures
requ
items 6.4.1 6.4.4 below
Security Audit Procedures v 1.1
25
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
6
s,
a
c
tr
nge control
d
f
p
.4.b For a sample of system components, critical
server
nd wireless access points, examine the three most
recent
hanges/security patches for each system component,
and
ace those changes back to related cha
ocumentation. Verify that, for each change examined,
the
ollowing was documented according to the change
control
rocedures:
6.4.1 Documentation of impact
6.4.1 Verify that documentation of customer impact
is
included in the change control documentation for
each
sampled change
6.4.2 Management sign-off by
appropriate parties
6.4.2 Verify that management sign-off by
appropriate
parties is present for each sampled
change
6.4.3 Testing of operational
6.4.3 Verify that operational functionality testing
was
functionality
performed for each sampled change
6.4.4 Back-out procedures
6.4.4 Verify that back-out procedures are prepared
for
each sampled change
6.5.a Obtain and review software development
processes for
a
b
tr
b
ny web- ased applications. Verify that processes
require
aining in secure coding techniques for developers, and
are
ased on guidance such as the OWASP
Guidelines
(http://www.owasp.org)
6
op all web applications
b
s
S
c
prevention of common coding
vulnerabilities in software development
processes, to include the following:
6
s
a
v
.5
Devel
ased on secure coding guidelines.
uch as the Open Web Application
ecurity Project Guidelines.
Review
ustom application code to identify
coding vulnerabilities. Cover
.5.b For any web-based applications, verify that
processe
re in place to confirm that web applications are
not
ulnerable to the following
6.5.1 Unvalidated input
6.5.1
Unvalidated input
6.5.2 Broken access control (for
example, malicious use of user IDs)
6.5.2 Malicious use of User IDs
6.5.3 Broken authentication and
unt
s and session
ie
session management (use of acco
credentials and session cookies)
6.5.3 Malicious use of account
credential
cook s
6.5.4 Cross-site scripting (XSS)
attacks
6.5.4 Cross-site scripting
6.5.5 Buffer overflows
6.5.5 Buffer overflows due to unvalidated input and
other
causes
6.5.6 Injection flaws (for
example,
6.5.6 SQL injection and other command injection flaws
Security Audit Procedures v 1.1
26
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
structured query language (SQL)
injection)
6.5.7 Improper error handling
6.5.7
Error handling flaws
6.5.8 Insecure storage
6.5.8
Insecure storage
6.5.9 Denial of service
6.5.9
Denial of service
6.5.10 Insecure configuration
cure configuration management
management
6.5.10 Inse
6.6
Ensure that all web-facing
applications are protected against
k
n atta
f
cation
n
abilities by an
ializes in
application security
·
r
st
t.
6
e
f
re in place as follows:
s were
ated
g applications to detect and prevent
now
cks by either of the
ollowing methods:
·
Having all custom appli
code reviewed for commo
vulner
organization that spec
Installing an application-laye
firewall in front of web-facing
applications
Note: This method is considered a be
practice until June 30, 2008, after
which it becomes a requiremen
.6
For web-based applications, ensure that one of
th
ollowing methods a
·
Verify that custom application code is
periodically
reviewed by an organization that specializes in
application security; that all coding vulnerabilitie
corrected; and that the application was re-evalu
after the corrections
·
Verify that an application-layer firewall is in place
in
front of web-facin
web-based attacks
Security Audit Procedures v 1.1
27
Implement Strong Access Control
Measures
holder data by business
need-to-know
ent ens
r
e accessed by authorized personnel.
Requirement 7: Restrict access to
card
This requirem
ures c itical data can only b
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
C
OMMENTS
7.
ss to computing
r
r
i
.
7.1
Obtain and examine written policy for data control, and
verify that
the
i
ricted to least
·
Ass
job
clas
·
Req
nt
·
p
1
Limit acce
esou ces and cardholder
nformation only to those individuals
whose job requires such access
policy ncorporates the following:
·
Access rights to privileged User IDs are
rest
privileges necessary to perform job
responsibilities
ignment of privileges is based on individual
personnel's
sification and function
uirement for an authorization form signed by
manageme
that specifies required privileges
Im lementation of an automated access control
system
7.2
systems
restricts
.2
Exam
an access co
emented and that it includes the
following
·
Coverage of all system components
·
Assignment of privileges to individuals based on
job
classification and function
·
Default "deny-all" setting (some access control systems are
set
by default to "allow-all" thereby permitting access
unless/until a
rule is written to specifically deny it)
Establish a mechanism for
with multiple users that
access based on a user's
7
need to know, and is set to "deny
all" unless specifically allowed.
ine system settings and vendor documentation to verify
that
ntrol system is impl
Security Audit Procedures v 1.1
28
Requirement 8: Assign a unique ID to each person with
computer access.
son with access ensures that actions taken on critical data
and systems
Assigning a unique identification (ID) to each per
are performed by, and can be traced to, known and authorized
users.
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
8.1
Identify all users with a
un
ng
t
mp
8.1
For a sample of user IDs, review user ID listings and verify
that
all users have a uniqu
stem components or
cardholder data
ique user name before allowi
hem to access system
co
onents or cardholder data.
e username for access to sy
8.2
In addition to assigni
unique ID, employ at least one of
the following methods to
ng a
authenticate all users:
·
Password
·
Token devices (for
example, SecureID,
certificates, or public key)
·
thenticated using unique ID and
he
cardhol
sed
ve an authentication to verify
Biometrics
8.2
To verify that users are au
additional authentication (for example, a password) for
access to t
der environment, perform the following:
·
Obtain and examine documentation describing
the
authentication method(s) u
·
For each type of authentication method used and for
each
type of system component, obser
authentication is functioning consistent with documented
authentication method(s)
8.3
Implement two-factor
authentication for remote access t
the network by employees,
administrators, and third parties.
Use technologies such as remot
o
e
authentication and dial-in service
(RADIUS) or terminal access
controller access control system
(TACACS) with tokens; or VPN
(based on SSL/TLS or IPSEC) with
individual certificates.
work and verify that both
a p s
d, token
PIN
r
8.3
To verify that two-factor authentication is implemented for
all
remote network access, observe an employee (for example,
an
administrator) connecting remotely to the
net
as word and an additional authentication item (Smart
car
) a e required.
8.4.a For a sample of system components, critical
servers, and
wireless access points, examine password files to verify
that
passwords are unreadable
8.4
Encrypt all passwords
during transmission and storage
on all system components.
8.4.b For Service Providers only, observe
password files to verify
that customer passwords are encrypted
Security Audit Procedures v 1.1
29
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
8.5
Ensure pro
authentication and
management for non
users and administrators on all
sys
ssword
per user
password
-consumer
8.5
Review procedures and interview personnel to verify
that
procedures are implemented for user authentication and
pa
management, by performing the following:
tem components as follows:
8.5.1.a
d examine an authorization form for each
ID
ation form to the
Select a sample of user IDs, including both
administrators
and general users. Verify that each user is authorized to use
the
system according to company policy by performing the
following:
·
Obtain an
·
Verify that the sampled User IDs are implemented
in
accordance with the authorization form (including
with
privileges as specified and all signatures obtained,.),
by
tracing information from the authoriz
system
8.5.1
on,
8.5.1.
ave access to management
co ol
Control addition, deleti
and modification of user IDs,
credentials, and other identifier
objects
b Verify that only administrators
h
ns es for wireless networks
8
entity before
perfo
ts
8.5.2
cedures and observe security
person
.5.2 Verify user id
rming password rese
Examine password pro
nel to verify that, if a user requests a password reset
by
phone, email, web, or other non-face-to-face method, the
user's
identity is verified before the password is reset
8.5.3 Set first-time passwords
to a unique value for each user
and change immediately after
the first use
8.5.3
Examine password procedures and observe
security
personnel to verify that first-time passwords for new users
are set to
a unique value for each user and changed after first
use
8.5.4 Immediately revoke
access for any terminated users
8.5.4
Select a sample of employees terminated in the past
six
months, and review current user access lists to verify
that their IDs
have been inactivated or removed
8.5
Remove inactive user
accounts at least every 90 days
.5
8.5.5 For a sample of user IDs, verify that there are
no inactive
accounts over 90 days old
8.5.6 Enable accounts used by
vendors for remote maintenance
only during the time period
needed
ounts used by vendors to support and
8.5.6 Verify that any acc
maintain system components are inactive, enabled only
when
needed by the vendor, and monitored while being
used
8.5.7 Communicate
password
procedures and policies to all
8.5.7 Interview the users from a sample of user IDs,
to verify that
they are familiar with password procedures and
policies
Security Audit Procedures v 1.1
30
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
us
who have access to
cardholder data
ers
8.5.8.a For a sample of system components, critical
servers, and
wireless access points, examine user ID lists to verify the
following
·
Generic User IDs and accounts are disabled or
removed
Share
re
·
d User IDs for system administration activities and
other
critical functions do not exist
·
Shared and generic User IDs are not used to
administer
wi less LANs and devices
8.5.8
roup
and shar
.b Examine password policies/procedures to verify
that g
ed passwords are explicitly prohibited
8.5.8 Do not use group, share
or generic accounts and
passwords
d,
8.5.8.c
nd
Interview system administrators to verify that group
a
shared passwords are not distributed, even if requested
8.5.9 Change user passwords
at least every 90 days
8.5.9 For a sample of system components, critical
servers, and
wireless access points, obtain and inspect system
configuration
ire
omer passwords are
ed
settings to verify that user password parameters are set to
requ
users to change passwords at least every 90 days
For Service Providers only, review internal processes
and
customer/user documentation to verify that
cust
requir
to change periodically and that customers are
given
guidance as to when, and under what circumstances,
passwords
must change
8.5.10 Require a minimum
seven
8.5.10 For a sample of system components, critical
servers, and
ss a
Serv
re
length requirements
password length of at least
characters
wirele
ccess points, obtain and inspect system
configuration
settings to verify that password parameters are set to
require
passwords to be at least seven characters long
For
ice Providers only, review internal processes
and
customer/user documentation to verify that customer passwords
a
required to meet minimum
8.5.11 Use passwords
containing both numeric and
alphabetic characters
8.5.11 For a sample of system components, critical
servers, and
wireless access points, obtain and inspect system
configuratio
settings to verify that password parameters are set to
requi
n
re
passwords to contain both numeric and alphabetic
characters
For Service Providers only, review internal processes
and
Security Audit Procedures v 1.1
31
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
customer/user documentation to verify that customer passwords
are
required to contain both numeric and alphabetic
characters
8.5.12 Do not allow an individual
to submit a new password that is
the same as any of the last four
passwords h
e or she has used
n
p s
For S
rocesses and
words
cann
us four passwords
8.5.12 For a sample of system components, critical
servers, and
wireless access points, obtain and inspect system
configuration
settings to verify that password parameters are set to
require that
ew passwords cannot be the same as the four previously
used
as words
ervice Providers only, review internal
p
customer/user documentation to verify that new customer
pass
ot be the same as the previo
8.5.13 Limit repeated access
attempts by locking out the user
ID after not more than six
attempts
configuration
settings to verify that password parameters are set to
require that a
cc
customer/user documentation to verify that customer accounts
are
8.5.13 For a sample of system components, critical
servers, and
wireless access points, obtain and inspect
system
user's a ount is locked out after not more than six invalid
logon
attempts
For Service Providers only, review internal processes
and
temporarily locked-out after not more than six invalid
access
attempts
8.5.14 Set the lockout duration
to thirty minutes or until
administrator enables the user ID
onfiguration
that
8.5.14 For a sample of system components, critical
servers, and
wireless access points, obtain and inspect system
c
settings to verify that password parameters are set to
require
once a user account is locked out, it remains locked for
thirty minutes
or until a system administrator resets the
account
8.5.15 If a session has been
idle for more than 15 minutes,
r the
ss points, obtain and inspect system
configuration
require the user to re-ente
password to re-activate the
terminal
8.5.15 For a sample of system components, critical
servers, and
wireless acce
settings to verify that system/session idle time out features
have
been set to 15 minutes or less
8.5.16.a Review database configuration settings for a
sample of
databases to verify that access is authenticated, including
for
individual users, applications, and
administrators
8.5.16 Authenticate all access
to any database containing
cardholder data. This includes
access by applications,
other
n
administrators, and all
users
8.5.16.b Review database configuration settings and
database
accounts to verify that direct SQL queries to the database
are
prohibited (there should be very few individual database
logi
accounts. Direct SQL queries should be limited to
database
administrators)
Security Audit Procedures v 1.1
32
Requirement 9: Restrict physical access to cardholder
data.
Any physical acce
opp
devices or data a
ly restricted.
ss to data or systems that house cardholder data provides
the
nd to remove systems or hardcopies, and should be
appropriate
ortunity for individuals to access
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
9.1
Use appropriate facility
entry controls to limit and monitor
physical access to systems that
store, process, or transmit
cardholder data.
9
c
tems
t
es
.1
Verify the existence of physical security controls for
each
omputer room, data center, and other physical areas with
sys
hat contain cardholder data
·
Verify that access is controlled with badge readers and
other
devices including authorized badges and lock and
key
·
Observe a system administrator's attempt to log into
consol
for three randomly selected systems in the cardholder
environment and verify that they are "locked" to prevent
unauthorized use
9.1.1 Use cameras to monitor
sensitive areas. Audit collected
data and correlate with other
entries. Store for at least three
s of data
d that
months, unless otherwise
restricted by law.
9.1.1 Verify that video cameras monitor the
entry/exit point
centers where cardholder data is stored or present. Video
cameras
should be internal to the data center or otherwise protected
from
tampering or disabling. Verify that cameras are monitored
an
data from cameras is stored for at least three months
9.1.2 Restrict physical access
to publicly accessible network
jacks
A
h
a
9.1.2 Verify by interviewing network administrators
and by
observation that network jacks are enabled only when needed
by
authorized employees. For example, conference rooms used to
host
vi
sho
sitors
uld not have network ports enabled with
DHCP.
lternatively, verify that visitors are escorted at all times
in areas wit
ctive network jacks
9
t
g
9
s is appropriately restricted
.1.3 Restrict physical access
o wireless access points,
ateways, and handheld devices
.1.3 Verify that physical access to wireless access
points,
gateways, and handheld device
9.2
all
be
esp
ca
"Employee" refers to full-time and
part-time employees, temporary
9.2
em
inclu
d
Develop procedures to help
personnel easily distinguish
tween employees and visitors,
ecially in areas where
rdholder data is accessible.
.a Review processes and procedures for assigning
badges to
ployees, contractors, and visitors, and verify these
processes
de the following:
·
Procedures in place for granting new badges,
changing
access requirements, and revoking terminated employee an
expired visitor badges
·
Limited access to badge system
Security Audit Procedures v 1.1
33
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
employees and pe
consultants who ar
the entity's site. A "visito
defined as a vendor, guest of an
em
facility for a
ally
rsonnel, and
e "resident" on
r" is
9.2.b Observe people within the facility to verify
that it is easy to
distinguish between employees and visitors
ployee, service personnel, or
anyone who needs to enter the
short duration, usu
not more than one day.
9.3
Make sure all visitors are
handled as follows:
9.3
Verify that employee/visitor controls are in place as
follows:
9.3.1 Authorized
before
entering areas where cardholder
data is processed or maintained
9.3.1
pt
to
doe
cardh
Observe visitors to verify the use of visitor ID badges.
Attem
gain access to the data center to verify that a visitor ID
badge
s not permit unescorted access to physical areas that
store
older data
9.3.2 Given a physical token
9.3.2
(for example, a badge or access
device) that expires and that
identifies the visitors as non-
employees
Examine employee and visitor badges to verify that
ID
badges clearly distinguish employees from visitors/outsiders
and that
visitor badges expire
9.3.3 Asked to surrender the
physical token before le
aving the
d
on
facility or at the date of expiration
9.3.3 Observe visitors leaving the facility to verify
visitors are aske
to surrender their ID badge upon departure or
expirati
9
he
f
c
.4.a Verify that a visitor log is in use to record
physical access to t
acility as well as for computer rooms and data centers
where
ardholder data is stored or transmitted
9
in
a
cal audit trail of visitor
activity. Retain this log for a
minimum of three months, unless
otherwise restricted by law.
9
r
oyee authorizing physical access, and is
r
.4
Use a visitor log to mainta
physi
.4.b Verify that the log contains the visitor's name,
the firm
epresented, and the empl
etained for at least three months
9
cure.
Verify that offsite storage is visited periodically to
determine that
.5
Store media back-ups in a
secure location, preferably an off-
site facility, such as an alternate or
backup site, or a commercial
storage facility.
9.5
Verify that the storage location for media backups is
se
backup media storage is physically secure and fireproof
9.6
Physically secure all pa
and electronic media (including
per
9.6
de
controls
comput
rs (including paper receipts, paper
rep
e desks and open
computers, electronic media,
networking and communications
Verify that procedures for protecting cardholder data
inclu
for physically securing paper and electronic media
in
er rooms and data cente
orts, faxes, CDs, and disks in employe
Security Audit Procedures v 1.1
34
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
hardware, telecommunication
lines, paper receipts, paper
reports, and faxes) that contain
cardholder data
workspaces, and PC hard drives)
9.7
Maintain strict control over
the internal or external distributio
of any kind of media that contains
cardholder data: including the
following
n
9.7
Verify that a policy exists to control distribution of
media
containing cardholder data, that the policy covers all
distributed media
including that distributed to individuals
9.7.1 Classify the media so it
can be identified as confidential
9.7.1
Verify that all media is classified so that it can be
identified as
"confidential"
9.7.2 Send the media by
secured courier or other delivery
method that can be accurately
tracked
9.7.2 Verify that all media sent outside the facility
is logged and
authorized by management and sent via secured courier or
othe
delivery mechanism that can be tracked
r
9
a
m
(
di
9
l
ation
.8 Ensure
management
pproves any and all media that is
oved from a secured area
especially when media is
stributed to individuals).
.8
Select a recent sample of several days of offsite media
tracking
ogs, and verify the presence in the logs of tracking details
and proper
management authoriz
9
t
9
.9
Maintain strict control over
he storage and accessibility of
media that contains cardholder
data.
.9
Obtain and examine the policy for controlling storage
and
maintenance of hardcopy and electronic media and verify that
the
policy requires periodic media
inventories.
9.9.1 Properly inventory all
media and make sure it is
securely stored.
9.9.1.a Obtain and review the media inventory log to
verify that periodi
media inventories are performed
c
9.9.1.b Review processes to verify that media is
securely stored
9.10 Destroy media containing
riodic media destruction policy and
cardholder data when it is no
longer needed for business or
legal reasons as follows
9.10 Obtain and examine the pe
verify that it covers all media containing cardholder data
and confirm
the following:
9.10.1.a Verify that hard-copy materials are
cross-cut shredded,
incinerated, or pulped, in accordance with ISO 9564-1 or ISO
11568-
3e
9.10.1 Cross-cut shred,
incinerate, or pulp hardcopy
material
ng access
s
9.10.1.b Examine storage containers used for
information to be
destroyed to verify that the containers are secured. For
example,
verify that a "to-be-shredded" container has a lock
preventi
Security Audit Procedures v 1.1
35
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
to its contents
9.10.2 Purge, degauss, sh
otherwise destroy electronic
media so that c
red, or
ardholder data
nn
9.10.2 Verify that electronic media is destroyed
beyond recovery by
using a military wipe program to delete files, or via
degaussing or
otherwise physically destroying the media
ca ot be reconstructed
Regularly Monitor and Test
Networks
R
d m
a
.
mechanis
senc
s in
ng
he cause of a compromise is very
difficult
equirement 10: Track an
onitor all access to network resources and cardholder
dat
Logging
thorough tracki
without system activity l
ms and the ability to track user activities are critical. The
pre
and analysis when something does go wrong. Determining
t
ogs.
e of log
all environments allows
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
10.1 Establish a process
access to system compone
for linking all
nts (especially
s
ivil
s
er.
10.1 Verify through observation and interviewing
the
system administrator, that audit trails are enabled
and
acce s done with administrative pr
such as root) to each individual us
ege
active, including for any connected wireless
networks.
10.2 Implement automated au
all sys
dit tra
tem components to reconstruct the
fo
xamination of audit
logs, and examination of audit log settings, that
the
ils for
10.2 Verify though interviews, e
llowing events:
following events are logged into system activity
logs:
10.2.1 All individual access
cardholder data
es to
ss to cardholder data
10.2.1 All individual acce
10.2.2 All actions taken by any i
with root or administrative pr
n
ivileges
dividual
10.2.2 Actions taken by any individual with root
or
administrative privileges
10.2.3 Access to all audit trails
10.2.3 Access to all audit trails
10.2.4 Invalid logical access
attempts
10.2.4 Invalid logical access
attempts
10.2 5 Use of identification a
authentication mechanisms
nd
10.2.5 Use of identification and
authentication
mechanisms
10.2.6 Initialization of the audit
logs
10.2.6 Initialization of audit
logs
10.2.7 Creation and deletion of
syste
m-
10.2.7 Creation and deletion of system level
objects
Security Audit Procedures v 1.1
36
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLA
NOT IN
PLACE
TARGET DATE/
CE
COMMENTS
level objects
1
au
e
r e
e
0.3 Record at least the following
ntries for all system components fo
vent:
dit trail
ach
10.3 Verify through interviews and observation,
for
each auditable event (from 10.2), that the audit
trail
captures the following:
10.3.1 User identification
10.3.1 User identification
10.3.2 Type of event
10.3.2 Type of event
10.3.3 Date and time
10.3.3 Date and time stamp
10.3.4 Success or failure
indication
10.3.4 Success or failure indication, including
those
for wireless connections
10.3.5 Origination of event
10.3.5 Origination of event
10.3.6 Identity or
system compone
name of affected data,
nt, or resource
10.3.6 Identity or name of affected data,
system
component, or resources
10.4 Obtain and review the process for acquiring
and
distrib
uting the correct time within the organization,
as
well as the time-related system-parameter settings for
a
sample of syst
ers, and
wireless acces
included in
o
em components, critical serv
s points. Verify the following is
the pr cess and implemented:
10.4.a Verify that NTP or similar technology is used
for
time synchronization
10.4.b Verify that internal servers are not all
receivin
time signals from external sources. [Two or
three
central time servers within the organization
receive
g
o, GPS
I
i
,
are
t
servers.]
external time signals [directly from a special
radi
satellites, or other external sources based
on
nternat onal Atomic Time and UTC (formerly
GMT)]
peer with each other to keep accurate time, and
sh
he time with other internal
10.4 Synchroniz
and times
e Protocol (NTP) is
r
e all critical system clocks
10.4.c Verify that the Network
Tim
unning the most recent version
Security Audit Procedures v 1.1
37
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
10.4.d Verify that specific external hosts
are
gn
TP
he
h
ccess control lists can be
ddresses of client
ded with the NTP service (to
se of internal time servers).
information
desi ated from which the time servers will accept
N
time updates (to prevent an attacker from changing
t
clock). Optionally, those updates can be encrypted
wit
a symmetric key, and a
created that specify the IP a
e
rovi
machin s that will be p
prevent unauthorized u
See www.ntp.org for more
10.5 Secure audit trails so they cannot
be
altered
1
re secured so that
t
ws:
0.5 Interview system administrator and
examine
permissions to verify that audit trails a
hey cannot be altered as follo
10.5.1 Limit viewing of audit trails to
thos
with a job-related need
e
-
10.5.1 Verify that only individuals who have a
job
related need can view audit trail files
10.5.2 Protect audit trail files
from
unauthorized modifications
10.5.2 Verify that current audit trail files
are protected
from unauthorized modifications via access
control
mechanisms, physical segregation, and/or
network
segregation
10.5.3 Promptly back up audit trail files
to
a centralized log server or media that is
difficult to alter.
rver or media that is
difficult to alter
10.5.3 Verify that current audit trail files
are promptly
backed up to a centralized log se
10.5.4 Copy logs for wireless
networks
onto a log server on the internal LAN
nto a centralized internal log
10.5.4 Verify that logs for wireless networks
are
offloaded or copied o
server or media that is difficult to alter
10.5.5 Use file integrity monitoring
and
change detection software on logs to
ensure that existing log data cannot be
changed without generating alerts
(although new data being added should not
cause an alert)
10.5.5 Verify the use of file integrity monitoring
or
change detection software for logs by
examining
system settings and monitored files and results
from
monitoring activities
10.6 Review logs for all system
components at least daily. Log reviews
must
include those servers that perform
security
functions like intrusion detection system
(IDS) and authentication, authorization,
and
rity policies and
and that follow-up to
exceptions is required
10.6.a Obtain and examine secu
procedures to verify that they include procedures
to
review security logs at least daily
Security Audit Procedures v 1.1
38
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
accounting protocol (AAA) servers (for
example, RADIUS).
Note: Log harvesting, parsing, and
alerting
tools may be used to meet compliance
with
Requirement 10.6
rify that
10.6.b Through observation and interviews,
ve
regular log reviews are performed for all
system
components
10.7.a Obtain and examine security policies
an
procedures and verify that they include audit
log
retention policies and require audit log retention for
a
d
t
least one year
10.7 Retain audit trail history for at
least
one year, with a minimum of three months
available online.
b
n
10.7. Verify that audit logs are available online or
o
tape for at least one year
R
gularly test secu
lities are being di
s, and being introduced by new software.
Systems, processes, and c
ly to ensure security is maintained over time and
with
any changes in software.
equirement 11: Re
rity systems and processes.
Vulnerabi
scovered continually by hackers and
researcher
ustom software should be tested frequent
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
11.1.a Confirm by interviewing security personnel
a
examining relevant code, documentation,
and
processes that security testing of devices is in
pl
nd
ace to
t.
assure that controls identify and stop
unauthorized
access attempts within the cardholder
environmen
1
nually
to assure the ability to adequately identify
and
t
.
U
y to
id
ess devices.
1.1 Test security controls,
limitations,
network connections, and restrictions an
o stop any unauthorized access attempts
se a wireless analyzer at least quarterl
entify all wireless devices in use.
11.1.b Verify that a wireless analyzer is used at
least
quarterly to identify all wirel
1
al and external network
r
ly and after
s
11.2.a Inspect output from the most recent
four
ability
tained
1.2 Run intern
vulne ability scans at least quarter
any significant change in the network (such
as
new system component installations,
change
in network topology, firewall rule
modifications, product upgrades).
quarters of network, host, and application
vulner
scans to verify that periodic security testing of
the
devices within the cardholder environment
occurs.
Verify that the scan process includes rescans
until
"clean" results are ob
Security Audit Procedures v 1.1
39
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
Note: Quarterly external vulnerability
sc
must be performed by a scan vendor
qu
by the payment card in
ans
alified
nt quarters of external vulnerability scans
to
verify that
st
rform the PCI Security Scanning
Procedures
dustry. Scans
conducted after network changes may
be
performed by the company's internal staff.
11.2.b To verify that external scanning is occurring
on
a quarterly basis in accordance with the PCI
Security
Scanning Procedures, inspect output from the
four
most rece
·
Four quarterly scans occurred in the mo
recent 12-month period
·
The results of each scan satisfy the PCI
Security Scanning Procedures (for example, no
urgent, critical, or high vulnerabilities)
·
The scans were completed by a vendor
approved to pe
11.3 Perform penetration testing at
least
once a year and after any significant
infrastructure or application upgrade or
11.3 Obtain and examine the results
fro
recent penetration test to verify that
penet
is performed at least annually and after any
signifi
modification (such
upgrade, a sub-net
environment, or a
environment). These
include the following
m the most
ration testing
cant
as an operating system
work added to the
web server added to the
penetration tests must
changes to the environment. Verify that any
noted
vulnerabilities were corrected. Verify that
the
penetration tests include:
11.3.1
ts 11.3.1 Netw
Network-layer penetration tes
ork-layer penetration tests
11.3.2 Application-layer penetration tests
11.3.2
Application-layer penetration tests
11.4.a Observe the use of network intrusion
de
systems and/or intrusion prevention systems on
the
network. Verify that all critical network traffic in
the
cardholder data environment is monitored
tection
11.4.b Confirm IDS and/or IPS is in place to
monitor
and alert personnel of suspected compromises
11.4 Use network intrusion
detection
systems, host-based intrusion detection
systems, and intrusion prevention systems
monitor all network traffic and alert
personne
to suspected compromises. Keep a
to
l
ll intrusion
detection and prevention engines
up-to-date.
11.4.c Examine IDS/IPS configurations and
confirm
IDS/IPS devices are configured, maintained,
and
updated per vendor instructions to ensure
optimal
protection
Security Audit Procedures v 1.1
40
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
11.5 Deploy file integrity
monitoring
software to alert personnel to
unauthorized
modification of critical system or content
files;
and configure the software to perform
critic
file comparisons at least weekly.
Critical files are not necessarily only
those
al
containing cardholder data. For file
integrity
monitoring purposes, critical files are
usually
those that do not regularly change, but
the
modification of which could indicate a
system
compromise or risk of compromise.
File
integrity monitoring products usually
come
pre-configured with critical files for the
related
operating system. Other critical files, such
as
is the
those for custom applications, must
be
evaluated and defined by the entity
(that
merchant or service provider)
11.5 Verify the use of file integrity
monitoring
products within the cardholder data environment
by
observing system settings and monitored files, as
well
as reviewing results from monitoring activities
ecurity Policy
R
licy th
urity for em
e
co
tors.
olicy se
rm
hat is expected of them. All
a
es for protecting it.
Maintain an Information S
equirement 12: Maintain a po
at addresses information sec
ploye s and
ntrac
A strong security p
employees should be aw
ts the security tone for the whole company and
info
re of the sensitivity of data and their
responsibiliti
s employees w
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
12.1 Establish, publish,
maintain,
and disseminate a security policy that
accomplishes the following:
12.1
the poli
system
partner
Examine the information security policy and verify
that
cy is published and disseminated to all
relevant
users (including vendors, contractors, and
business
s)
12.1.1 Addresses all requirements
in this specification
12.1.1 Verify that the policy addresses all
requirements in
this specification.
12.1.2 Includes an annual process
12.1.2 Verify that the information security policy
includes
Security Audit Procedures v 1.1
41
PC
TES
I
I DSS REQUIREMENTS
TING PROCEDURES
N
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
that identifies threats, and
vulnerabilities, and results in a
formal risk assessment
v
an an
s
ats,
ulner
nual ri k assessment process that identifies
thre
abilities, and results in a formal risk
assessment
12.1.3 Includes a review at least
once a year and updates when the
12.1
environment changes
.3
d to reflect
changes to business objectives or the risk environment
Verify that the information security policy
is
reviewed at least annually and updated as
neede
12.2 Develop daily operational
security procedures that are
consistent with requirements in this
specification (for example, user
account maintenance procedures,
and log review procedures).
12.2
Verif
inclu
the re
.a Examine the daily operational security
procedures.
y that they are consistent with this specification,
and
de administrative and technical procedures for each
of
quirements
12.3 Develop usage policies for
critical employee-facing technologies
(such as modems and wireless) to
define proper use of these
technologies for all employees a
12.3
facing te
followi
nd
contractors. Ensure these usage
policies require the following:
Obtain and examine the policy for critical
employee-
chnologies and verify the policy contains
the
ng:
12.3.1 Explicit management
12.3.1 Verify that the usage policies require
explicit
the devices
approval
management approval to use
12.3.2 Authentication for use of
the
12.3.2 Verify that the usage poli
technology
use is authenticated with username and password or
other
authentication item (for example, token)
cies require that all device
12.3.3 A list of al
personnel with a
l such devices and
ccess
12.3.3 Verify that the usage policies require a list
of all
devices and personnel authorized to use the devices
12.3.4 Labeling of d
owner, contact information, and
pur
devices with owner, contact information, and purpose
evices with
12.3.4 Verify that the usage policies require
labeling of
pose
12.3.5 Acceptable uses of the
technology
12.3.5 Verify that th
re acceptable
s
e usage policies requi
use for the technology
12.3.6 Acceptable network
locations
for the technologies
12.3.6 Verify that the usage policies require
acceptab
network locations for the technology
le
12.3.7 List of company-approved
Verify that the usage policies require a list
of
products
12.3.7
company-approved products
12.3.8 Automatic disconnect of
e usage policies require automatic
12.3.8 Verify that th
Security Audit Procedures v 1.1
42
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
modem sessions after a sp
period of inactivity
ecific
disconnect of modem sessions after a specific period
of
inactivity
12.3.9 Activation of modems for
12.3.9 Verify that the usage policies require
activation of
ndors,
vendors only when needed by
vendors, with immediate
deactivation after use
modems used by vendors only when needed by
ve
with immediate deactivation after use
12.3.10
When accessing
cardholder data remotely via
modem, prohibition of storage of
cardholder data onto local hard
drives, floppy disks, or other
external media. Prohibition of cut-
and-paste and print functions during
d print functions during remote access
remote access
12.3.10
Verify that the usage policies prohibit
the
storage of cardholder data onto local hard drives,
floppy
disks, or other external media when accessing such
data
remotely via modem. Verify that the policies prohibit
cut-
and-paste an
12.4 Ensure that the security
policy
and procedures clearly define
information security responsibilities
for all employees and contractors.
12.4 Verify that information security policies
clearly define
information security responsibilities for both employees
and
contractors
12.5 Assign to an individual or
team
t
y
m
12.5 Verify the formal assignment of information
security to
a
le
m
tion
s
that the following
i
f
he following information securit
anagement responsibilities:
Chief Security Officer or other
security-knowledgeab
ember of management. Obtain and examine
informa
ecurity policies and procedures to verify
nformation security responsibilities are specifically
and
ormally assigned:
12.5.1 Establish, document, and
ng and distributing
distribute security policies and
procedures
12.5.1 Verify that responsibility for
creati
security policies and procedures is formally
assigned
12.5.2 Monitor and analyze secu
alerts and information, and distri
to approp
rity
bute
riate personnel
appropriate information security and business
unit
12.5.2 Verify that responsibility for monitoring
and
analyzing security alerts and distributing information
to
management personnel is formally assigned
12.5.3 Establish, document, and
sibility for creating and distributing
distribute security incident response
and escalation procedures to ensure
timely and effective handling of all
situations
12.5.3 Verify that respon
security incident response and escalation procedures
is
formally assigned
12.5.4 Administer user accounts,
12.5.4 Verify that responsibility for administering
user
Security Audit Procedures v 1.1
43
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
including additions, deletions, and
modifications
account and authentication management is
formally
assigned
12.5.5 Monitor and control all
access to data
12.5.5 Verify that responsibility for monitoring
and
controlling all access to data is formally
assigned
1
l security awareness
program for all employees
2.6.a
Verify the existence of a forma
1
security
a
ake all
e
s awa
ce
o
1
p
2.6 Implement a formal
wareness program to m
mployee
re of the importan
f cardholder data security:
2.6.b
Obtain and examine security awareness
program
rocedures and documentation and perform the following:
12.6.1.a Verify that the security awareness
program
provides multiple methods of communicating
awareness
and educating employees (for example, posters,
letters,
meetings)
12.6.1 Educate employees upon
hire and at least annually (for
example, by letters, posters,
memos, meetings, and promotions)
12.6.1.b Verify that employees attend awareness
training
upon hire and at least annually
12.6.2 Require employees to
acknowledge in writing that they
have read and understood the
company's security policy and
procedures
12.6.2 Verify that the security awareness program
requires
employees
to acknowledge in writing that they have
read
and understand the company's information security
policy
12.7 Screen potential employees
to
minimize the risk of attacks from
internal sources.
For those employees such as store
c
ne
c
facilitating a transaction, this
r
o
nt
ll
dholder data or the cardholder data
e
e
ashiers who only have access to o
ard number at a time when
equirement is a recommendation
nly.
12.7 Inquire of Human Resource department
manageme
and verify that background checks are conducted (within
the
constraints of local laws) on potential employees who
wi
have access to car
nvironment. (Examples of background checks include
pre-
mployment, criminal, credit history, and reference checks)
1
1
a
ween the
o
d
s
se that receive data for fraud
modeling purposes). Perform the
following:
2.8 If cardholder data is shared
with service providers, then
contractually the following is required:
2.8 If the audited entity shares cardholder data
with
nother company, obtain and examine contracts
bet
nization
rga
and any third parties that handle
cardholder
ata (for example, backup tape storage facilities,
managed
ervice providers such as Web hosting companies or
security
service providers, or tho
12.8.1 Service providers must
12.8.1 Verify that the contract contains provisions
requiring
Security Audit Procedures v 1.1
44
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
adhere to the PCI DSS
requirements
adherence to the PCI DSS requirements
12.8.2 Agreement that include
acknowledgement that the serv
provider is respo
s an
ice
nsible for the
or
sibility
security of cardholder data the
provider possesses
12.8.2 Verify that the contract contains provisions
f
acknowledgement by the third party of their
respon
for securing cardholder data
12.9 Implement an incident
response plan. Be prepared to
re
b
O
spond immediately to a system
reach.
12.9
btain and examine the Incident Response Plan
and
related procedures and perform the
following:
12.9.1 Create the incident res
plan to be implemented in the event
of system compromise. Ensure the
ponse
plan addresses, at a minimum,
specific incident response
and
p
ation
strategies (for example,
d
·
strategy for business continuity post
compromise
California residents in their database)
procedures, business recovery
continuity procedures, data backu
processes, roles and
responsibilities, and communic
and contact
informing the Acquirers and credit
card associations)
12.9.1 Verify that the Incident Response Plan and
relate
procedures include
·
roles, responsibilities, and
communication
strategies in the event of a compromise
·
coverage and responses for all critical
system
components
·
notification, at a minimum, of credit
card
associations and acquirers
·
reference or inclusion of incident
response
procedures from card associations
·
analysis of legal requirements for
reporting
compromises (for example, per California
bill
1386, notification of affected consumers is
a
requirement in the event of an actual or
suspected compromise, for any business
with
12.9.2 Test the plan at least
annu
12.9.2 Verify that the plan is tested at least
annually
ally
12.9.3 Designate specific person
to be available on a 24/7 basis to
respond to alerts
nel
12.9.3 Verify through observation and review of
policies,
that there is 24/7 incident response and
monitoring
coverage for any evidence of unauthorized activity,
critical
IDS alerts, and/or reports of unauthorized critical system
or
content file changes
12.9.4 Provide appropriate
training
ew of policies
to staff with security breach
12.9.4 Verify through observation and
revi
that staff with security breach responsibilities
are
Security Audit Procedures v 1.1
45
PCI DSS REQUIREMENTS
TESTING PROCEDURES
IN
PLACE
NOT IN
PLACE
TARGET DATE/
COMMENTS
response responsibilities
periodically trained
12.9.5 Include alerts from
intrusion
12.9.5 Verify through observation and review of
processes
detection, intrusion prevention, and
file integrity monitoring systems
that monitoring and responding to alerts from
security
systems are included in the Incident Response Plan
12.9.6 Develop process to mo
and evolve the incident respons
plan according to les
dify
e
sons learned
ation and review of policies
that there is a process to modify and evolve the
incident
response plan according to lessons learned and
to
r
and to incorporate industry
developments
12.9.6 Verify through observ
inco porate industry developments
12.10 All processors and service
providers must maintain and
i
m
t
12.10 Verify through observation, review of policies
and
procedures, and review of supporting documentation
that
t
p
mplement policies and procedures to
anage connected entities, to include
he following
here is a process to manage connected entities
by
erforming the following:
12.10.1 Maintain list of conne
entities
cted
12.10.1
main ne
Verify that a list of connected entities
is
tai d
12.10.2 Ensure proper due
diligence is conducted prior to
connecting an entity
12.10.2
ocedures ensure that proper due
dilige ce is
Verify that pr
n
conducted prior to connecting an entity
12.10.3 Ensure the entity is PCI
DSS compliant
12.10
PCI
S
.3 Verify that procedures ensure that the
entity is
DS compliant
12.10.4 Connect and disconnect
entities by following an established
process
12.10.4
cting entities
occu
o
Verify that connecting and
disconne
rs f llowing an established process
Security Audit Procedures v 1.1
46
Ap
S
ing Providers (with Testing
Procedures)
R
rov
in Req
cardholder data (including hosting providers)
must
CI D
providers must protect ea
hosted
d dat
nsideration to the following::
pendix A: PCI DS Applicability for
Host
equirement A.1: Hosting p
As referenced
iders protect cardholder data
environment
uirement 12.8, all service providers with access
to
adhere to the P
environment an
SS. In addition, Requirement 2.4 states that
hosting
a. Therefore, hosting providers must give special
co
ch entity's
Requirements
Testing Procedures
In Place
Not in Place
Target Date/
Comments
A.1
Protect each entity's (that is
merchant, service provider, or other
ntity) hosted environment and
data, as in A.1.1 throug
P
e
e
h A.1.4:
A
re
ts
.
No
pro
re
liance of the
en
eed. Each entity must
co
va
A.1
r
ect
nt
ice providers) hosted
environment and data, select a sample of servers
(Microsoft
in
le of
ost
thro
ow.
hosting provider must fulfill these
quiremen as well as all other
W
h
relevant sections of the PCI DSS
te: Even though a hosting
vider may meet these
quirements, the comp
tity that uses the hosting
provider
is not guarant
mply with the PCI DSS and
lidate compliance as applicable.
Specifically for a PCI audit of a Shared
hosting
ovider, to verify that Shared hosting
Providers prot
ities' (merchants and serv
dows and Unix/Linux) across a representative
samp
ed merchants and service providers, and verify
A.1.1
ugh A.1.4 bel
A.1.1 Ensure that each entity
only
as access to own cardholder data
environment
A.1.1 If a shared hosting provider allows entities
(for
example, merchants or service providers) to run their
own
applications, verify these application processes run using
the
unique ID of the entity. For example:
·
No entity on the system can use a shared web
server
user ID
·
All CGI scripts used by an entity must be created
and
run as the entity's unique user ID
h
A.1.2 Restrict each entity's
access
and privileges to own cardholder
d t
i
t
l
A.1.2.a Verify the user ID of any application process
is not a
privileged user (root/admin).
Security Audit Procedures v 1.1
47
Requirements
Testing Procedures
In Place
Not in Place
Target Date/
Comments
A.1.2.b Verify each entity (merchant, service
provider) has
read, write, or execute permissions only for files
and
directories it owns or for necessary system files
(restricted
via file system permissions, access control lists,
chroot,
jailshell, etc.). IMPORTANT: An entity's files may not
be
shared by group
A.1.2.c Verify an entity's users do not have write access
to
shared system binaries
A.1.2.d Verify that viewing of log entries is
restricted to the
owning entity
A.1.
To ensure each entity cannot monopolize
serve
resources to exploit vulnerabilities (error, race, and
restart
conditions, resulting in, for example, buffer overflows),
verify
restrictions are in place for the use of these
system
resources:
·
Disk
space
·
Bandwidth
2.e
r
·
Memory
·
CPU
A.1.3 Ensure logging and audit
trails are enabled and unique to
each entity's cardholder data
environment and consistent with
PCI DSS Requirement 10
A.1.3.a Verify the shared hosting provider has
enabled
logging as follows, for each merchant and service
provider
environment:
·
Logs are enabled for common third party
applications
Log
·
s are active by default
·
Logs are available for review by the owning
entity
·
Log locations are clearly communicated to the
owning
entity
A.1.4 Enable processes to provide
for timely forensic investigation in
the event of a compromise to any
hosted merchant or service
that pr
a timely forensics investigation of
related
r
provider.
A.1.4 Verify the shared hosting provider has written
policies
ovide for
serve s in the event of a compromise.
Security Audit Procedures v 1.1
48
Appendix B Compensating Controls
Compensating Controls
Compensating
ments when an entity cannot meet a
technical
specification of
ociated risk. See the PCI DSS Glossary for
the
full definition
vironment in which the control is
implemented, t
rity controls, and the configuration of the control.
Companies should be aware
all environments. Each compensating control must
be
thoroughly eva
plementation to ensure effectiveness. The following guidance
provides compensating
controls when
adab
requiremen
Compensating Controls fo
For companies
ender cardholder data unreadable (for example, by encryption)
due to technical
constraints or b
s, compensating controls may be considered. Only companies
that have
undertaken
legitimate technological or documented business
constraints can consider the
use of compen
to achieve compliance.
Companies tha
compensating controls for rendering cardholder data
unreadable must understand the risk
pos
y, th
ols must provide additional
to
ata. The controls considered
add
tisfy the "Compensating Controls" definition
in
SS G
s
evice or combination of devices,
applications, an c
following conditions:
1. Provide add
he network-layer)
2.
the following criteria:
·
Mac address
·
·
3. Restrict logical access to the
database
·
Control logical access to the database independent of Active
Directory or Lightweight Directory
Access Protocol (LDAP)
4. Prevent/detect common application or database attacks (for
example, SQL injection).
General
controls may be considered for most PCI DSS
require
a requirement, but has sufficiently mitigated the
ass
of compensating controls.
The effectiveness of a compensating control is dependent on
the specif
he surrounding secu
ics of the en
that a particular compensating control will not be effective
in
luated after im
companies are unable to render cardholder data
unre
r Requirement 3.4
unable to r
le per
t 3.4.
usiness limitation
a risk analysis and have
sating controls
t consider
to the data
protection
must be in
the PCI D
ed by maintaining readable cardholder data.
Generall
mitigate any additional risk posed by maintaining readable
cardholder d
ition to co
e contr
ntrols required in the PCI DSS, and must
sa
los ary. Compensating controls may consist of either a
d
d ontrols that meet all of the
itional segmentation/abstraction (for example, at
t
Provide ability to restrict access to cardholder data or
databases based on
IP address/
·
Application/service
User
accounts/groups
Data type (packet filtering)
Security Audit Procedures v 1.1
49