You are on page 1of 773

Table of content DSS V3 PCI DashBoard

Introduction and News


Glossary
Executive summary
Chart - % Compliance
Chart - Severity
Chart Priority
PCI Team
Scope definition
Required Documentation for audit
Crypto Keys inventory
Merchant types
Compensating Controls definition
Not Applicable - Rationals
Vulnerability scans form
Penetration tests form
Training & Knownledge Evidences
Requirement 1
Requirement 2
Requirement 3
Requirement 4
Requirement 5
Requirement 6
Requirement 7
Requirement 8
Requirement 9
Requirement 10
Requirement 11
Requirement 12
SANS-PCI Matrix
Return to Table of content
PCI Compliance Dashboard VERSION 14 - PCI DSS V3

Author, Owner and Contact
This dashboard is sponsored by:
Version history
What's new in this version
PCI 30 seconds newsletters
Table of content
Executive Summary
How to use this dashboard?
Feel free to use this compliance dashboard to sustain your PCI compliance journey, to support the discussion with your internal team, QSA
and acquiring banks. This dashboard is fully aligned with PCI DSS V3.
Appreciation, feedback and suggestions are WELCOME. Send them to Didier Godart (d@dgozone.com).
If you like this tool don't hesitate to let the community know about it.
Enjoy!
Didier Godart
Version History
V0.1 Requirements and testing procedures
V0.2 Add merchant type for each requirements
V0.3 Include Prioritized Approach milestones as defined by PCIco
Add a column Priority with PCIco Milestones (1 to 6)
Add a column Status of implementation
Add a column Estimated date to completion
Add sheet actors
V0.4 Add a sheet" What is my merchant Type?" with the full description of the merchant
types
Add Major observations from the 2011 Verizon PCI Compliance Report for each of
the twelve requirement
Add a column "Validation instructions for QSA/ISA" from the new released ROC-
QSA Reporting Instruction Manual
V0.5 Add Guidance for each requirements from the "Navigating PCI DSS V2.0"
Add a compensating control sheet for the definition and management of
compensating controls. Whenever a compensating control is present refer to it into
the column (in place) by the associated ID into the compensating controls sheet
Add Glossary
1.Select your Merchant type (Excutive Summary sheet)
2.Define your scope (Scope sheet)
3.Define your PCI Team (PCI team sheet)
4.For each requirement sheet:
5.Select the appropriate answer (In place, not in place, compensating control) and fill appropriate cells (Proof, Stage,remediation, estimated, Comments and select the owner responsible for actions)
6. Use the compensating controls page to document and justify them
7. Use the NA sheet to document and justify the NA requirements
8. Use the navigation links on the top of each sheet to navigate through the various sections and access the executive summary
9.Control your compliance status through the Excutive summary board (Executive sheet) and associated charts (% of compliance and Severity)
10.Use the vulnerability scans sheet to maintain a record of your scans
11.Use the penetration testing form to maintain record of your pen tests
12.Use the documentation sheet to get a detailed list on the required documentation and maintain your PCI library (Contact d@dgozone.com to get this supplement material).
13.Use the Crypto key sheet to make an inventory of your cryptographic keys
14.Use the Training and knowledge form to maintain records and evidence of trainings and knowledges required by DSS V3
V0.7
V0.8 Adapt SANS numerotation to new version (Version 3.1 October 3, 2011)
V0.9 Update the documentation sheet with the list of (required or optional) technical and
non-technical documents together with their associated PCI DSS requirements.
V10 Update Scope sheet with Criticality, Patch level, Scan date and Scan report location
Add a sheet "PCI Crypto Key list" to list all keys used within the scope: KeyId,
Purpose, Key custodians, status.
Add sheet Vulnerability scans (When, By who, results)
Add sheet Penetration Tests (When, By who, resulls)
V11 Integration PCI DSS V3
Updated list of documents (Contact me at d@dgozone.com) to obtain it.
Add a sheet "training& knowledge evidences"
Update list of PCI newsletters
WHAT'S NEW IN THIS VERSION
1.Navigation: Add Table of content and navigation links
2.Rename sheet "PCI Actor" to "PCI Team"
3.Associate column "Owner" in requirements sheets to the name of individuals
listed within sheet "PCI Team". A list box allows the selection of a name from this
sheet.
4. Add Documentation sheet listing all your documentation related to PCI.
5.Add row "SANS Top 20 Critical Security Controls" - Matching subcontrols for each
PCI requirement wherever possible.
6.Add Sheet " SANS-PCI" Listing all SANS Top 20 Critical Security Controls and Sub-
controls together with PCI requirements partially or fully matching the sub-controls.
Also % of match for each SANS Controls. For more details on the Matching matrix
read the associated Technical paper "PCI-SANS Top 20 Critical Security Controls"
7.Add "Scope" sheet allowing you to define the Card Data Environment (CDE)
8. Add two buttons within the Executive Summary Sheet allowing you to
hide/unhide non applicable requirements associated to the selected Merchant Type
(THANKS to Tony). Macros do not work on MAC.
Add an Executive Summary Tab Including # of requirements, % of compliance,
Severity (sum of all severities) depending on the selected merchant type.
Add Charts Tab including Severity per Requirement and % compliance per
requirement
Add Severity Column (= PCI defined priority for not in place requirements)
Add list boxes for the In place/not in place and Compensating control present.
All sheets are protected to avoid accidental deletion. (No password)
Instructions:
1.Select your merchant type within the sheet "Executive summary"
2.Select the appropriate answer for each requirements (Column L: Y/N/C)
V0.6
V12 Integration Testing procedure on New ROC
Alignment with SAQ V3 (A,B,C,C-VT,D)
Integration of the new merchant types: B-IP and S
Integration of major observations from Verizon 2014 PCI Compliance Report (see
individual requirement pages)
Review Severity rating = ABS (Priority - 7)
Add possible answer (Not Tested and Not Applicable)
V14 Integration SAQ A-EP
Integration SAQ P2EP
Add Section Progress based on Priority Approach (See executive summary)
Add New Chart "Progress by Priority"
Add New sheet -list of requirements marked as NA + rationals
Add Various navigation links
Add the selected merchant type on each requirement sheet.
Compliance Dashboard home page
PCI 30 Seconds Newsletters
PCI 30 Seconds newsletter #1 - PCI what are you talking about?
PCI 30 seconds newsletter #2 - Payment processing terminology and workflow
PCI 30 seconds newsletter #3 - Distributing roles
PCI 30 seconds newsletter #4 - Merchant levels
PCI 30 seconds newsletter #5 - What is your type?
PCI 30 seconds newsletter #6 - PCI DSS in a nutshel
PCI 30 seconds newsletter #7 - Define the scope of an assessment
PCI 30 seconds newsletter #8 - certification program, striving for quality
PCI 30 seconds newsletter #9 - The validation toolbox
PCI 30 seconds newsletter #10 - Prioritized Approach
PCI 30 seconds newsletter #11 - Tokenization
PCI 30 seconds newsletter #12 - the gap analysis process
PCI 30 seconds newsletter #3 - Compensating controls, magic trick or mirage?
PCI 30 seconds newsletter #14 - The world is not perfect!
PCI 30 seconds newsletter #15 - Nice Look!
PCI 30 seconds newsletter #16 Is your organization behaving like a fashion victim or a clown?
PCI 30 seconds newsletter #17 Why are my scan reports so thick? - Impact of "potential" vulnerabilities
PCI 30 seconds newsletter #18 What to do if compromised?
PCI 30 seconds newsletter #19 - Your PCI Logbook. What's required in terms of Log management?
PCI 30 seconds newsletter #20 PCI DSS and SANS Top 20 Critical Security Controls: The Sumo match.
PCI 30 seconds newsletter #21 - "Qualified" internal scanning staff using "appropriate" scanning tools - What does that mean?
PCI 30 seconds newsletter #22 - Don't get lost in translation with Executives. Get them listening.
PCI 30 seconds newsletter # 23 Introduction to Risk Assessment
PCI 30 second newsletter #24 - PCIco strengthens the scoping rules
PCI 30 seconds newsletter #25 - A New Standard is Born.
PCI 30 seconds newsletter #26 - PCIP is it worth it?
PCI 30 seconds newsletter #27 -Static versus Active Protection Systems. What Impact on Quarterly Scans?
PCI 30 Seconds newsletter #28 - The PCI Library - What docs are required for compliance?
PCI 30 seconds newsletter #29 - Do all PCI DSS requirements apply?
PCI 30 seconds newsletter #30 - Trainings your organization must deliver to comply with PCI DSS
PCI 30 Seconds Newsletter #31 - PCI DSS Crypto-framework
PCI 30 seconds newsletter #32 - Money for nothing
PCI 30 seconds newsletter #33 - Key take-away from the PCI Community meeting 2013
PCI 30 seconds newsletter #34 - PCI DSS Version 3 Changes and Impact - Should You Care?
PCI 30 seconds newsletter #35 - Patching within the context of PCI - All you need to know
Other articles
Ebook - Demystifying PCI DSS
Thoughts on the Verizon PCI Compliance Report
Can I use compensating control to resolve vulnerabilities found during a scan?
What to do if my organization can't demonstrate four passing Internal or external scans?
Verizon 2011 PCI Compliance Report
Business and IT security: two worlds that can't talk.
Cyber attack ranked within the top 5 risks in terms of probability
PCI Compliance Dashboard VERSION 14 - PCI DSS V3
Start Here
Didier Godart
Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com
RAPID7
Feel free to use this compliance dashboard to sustain your PCI compliance journey, to support the discussion with your internal team, QSA
and acquiring banks. This dashboard is fully aligned with PCI DSS V3.
Appreciation, feedback and suggestions are WELCOME. Send them to Didier Godart (d@dgozone.com).
If you like this tool don't hesitate to let the community know about it.
Enjoy!
Didier Godart
Contributors
Jan-11 Peter Hill
Feb 2011 Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
August 2011 Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
October 2011 Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
November 2011 Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
1.Select your Merchant type (Excutive Summary sheet)
2.Define your scope (Scope sheet)
3.Define your PCI Team (PCI team sheet)
4.For each requirement sheet:
5.Select the appropriate answer (In place, not in place, compensating control) and fill appropriate cells (Proof, Stage,remediation, estimated, Comments and select the owner responsible for actions)
6. Use the compensating controls page to document and justify them
7. Use the NA sheet to document and justify the NA requirements
8. Use the navigation links on the top of each sheet to navigate through the various sections and access the executive summary
9.Control your compliance status through the Excutive summary board (Executive sheet) and associated charts (% of compliance and Severity)
10.Use the vulnerability scans sheet to maintain a record of your scans
11.Use the penetration testing form to maintain record of your pen tests
12.Use the documentation sheet to get a detailed list on the required documentation and maintain your PCI library (Contact d@dgozone.com to get this supplement material).
13.Use the Crypto key sheet to make an inventory of your cryptographic keys
14.Use the Training and knowledge form to maintain records and evidence of trainings and knowledges required by DSS V3
Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
Swathy Anand
Vice President - Project Management
Fuze Network
swathyanand@gmail.com
Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
Tony Wilson
Managing Director
Indelible Data (a division of Indelible Designs
Limited)
tony@indelible-data.co.uk
July 2012 "Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone April 2013 "Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone June 2013 "Didier Godart
Risk Product Manager Rapid7
Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com
Dec 2013 "Didier Godart
Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com
May 2012
December 2011
March 2014 "Didier Godart
Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com
April 2014 Didier Godart
Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com
http://be.linkedin.com/in/didiergodart
The complete list of newsletters is now online
PCI 30 seconds newsletter #16 Is your organization behaving like a fashion victim or a clown?
PCI 30 seconds newsletter #17 Why are my scan reports so thick? - Impact of "potential" vulnerabilities
PCI 30 seconds newsletter #19 - Your PCI Logbook. What's required in terms of Log management?
PCI 30 seconds newsletter #20 PCI DSS and SANS Top 20 Critical Security Controls: The Sumo match.
PCI 30 seconds newsletter #21 - "Qualified" internal scanning staff using "appropriate" scanning tools - What does that mean?
PCI 30 seconds newsletter #22 - Don't get lost in translation with Executives. Get them listening.
PCI 30 seconds newsletter #27 -Static versus Active Protection Systems. What Impact on Quarterly Scans?
PCI 30 Seconds newsletter #28 - The PCI Library - What docs are required for compliance?
PCI 30 seconds newsletter #30 - Trainings your organization must deliver to comply with PCI DSS
PCI 30 seconds newsletter #33 - Key take-away from the PCI Community meeting 2013
PCI 30 seconds newsletter #34 - PCI DSS Version 3 Changes and Impact - Should You Care?
PCI 30 seconds newsletter #35 - Patching within the context of PCI - All you need to know
What to do if my organization can't demonstrate four passing Internal or external scans?
PCI Compliance Dashboard VERSION 14 - PCI DSS V3
About Didier
Feel free to use this compliance dashboard to sustain your PCI compliance journey, to support the discussion with your internal team, QSA
and acquiring banks. This dashboard is fully aligned with PCI DSS V3.
Appreciation, feedback and suggestions are WELCOME. Send them to Didier Godart (d@dgozone.com).
If you like this tool don't hesitate to let the community know about it.
Enjoy!
Didier Godart
1.Select your Merchant type (Excutive Summary sheet)
2.Define your scope (Scope sheet)
3.Define your PCI Team (PCI team sheet)
4.For each requirement sheet:
5.Select the appropriate answer (In place, not in place, compensating control) and fill appropriate cells (Proof, Stage,remediation, estimated, Comments and select the owner responsible for actions)
6. Use the compensating controls page to document and justify them
7. Use the NA sheet to document and justify the NA requirements
8. Use the navigation links on the top of each sheet to navigate through the various sections and access the executive summary
9.Control your compliance status through the Excutive summary board (Executive sheet) and associated charts (% of compliance and Severity)
10.Use the vulnerability scans sheet to maintain a record of your scans
11.Use the penetration testing form to maintain record of your pen tests
12.Use the documentation sheet to get a detailed list on the required documentation and maintain your PCI library (Contact d@dgozone.com to get this supplement material).
13.Use the Crypto key sheet to make an inventory of your cryptographic keys
14.Use the Training and knowledge form to maintain records and evidence of trainings and knowledges required by DSS V3
About Swathy About Fuze Network
About Tony About Indelible data
Contact
Contributors:
Jim Seaman
Principle Security Consultant
MSc, CCP, CISM, CRISC, QSA, A.Inst.IISP
Randomstorm.com
jim.seaman@randomstorm.com
--------
Paul McMillan | Consulting Manager
PCI QSA
Sysnet Global Solutions
paul.mcmillan@sysnetgs.com
The complete list of newsletters is now online
Return to Table of content
AAA Acronym for authentication, authorization, and accounting. Protocol for authenticating a user based on their
verifiable identity, authorizing a user based on their user rights, and accounting for a users consumption of
network resources.
Access Control Mechanisms that limit availability of information or information-processing resources only to authorized persons
or applications.
Account Data Account data consists of cardholder data plus sensitive authentication data. See Cardholder Data and Sensitive
Authentication Data
Account Number See Primary Account Number (PAN).
Acquirer Also referred to as acquiring bank or acquiring financial institution. Entity that initiates and maintains
relationships with merchants for the acceptance of payment cards.
Adware Type of malicious software that, when installed, forces a computer to automatically display or download
advertisements.
AES Abbreviation for Advanced Encryption Standard. Block cipher used in symmetric key cryptography adopted by
NIST in November 2001 as U.S. FIPS PUB 197 (or FIPS 197).
ANSI Acronym for American National Standards Institute. Private, non-profit organization that administers and
coordinates the U.S. voluntary standardization and conformity assessment system.
Anti-Virus Program or software capable of detecting, removing, and protecting against various forms of malicious software
(also called malware) including viruses, worms, Trojans or Trojan horses, spyware, adware, and rootkits.
Application Includes all purchased and custom software programs or groups of programs, including both internal and external
(for example, web) applications.
Audit Log Also referred to as audit trail. Chronological record of system activities. Provides an independently verifiable trail
sufficient to permit reconstruction, review, and examination of sequence of environments and activities
surrounding or leading to operation, procedure, or event in a transaction from inception to final results.
Audit Trail See Audit Log.
ASV Acronym for Approved Scanning Vendor. Company approved by the PCI
SSC to conduct external vulnerability scanning services.
Authentication Process of verifying identity of an individual, device, or process. Authentication typically occurs through the use of
one or more authentication factors such as:

Something you know, such as a password or passphrase
Something you have, such as a token device or smart card
Something you are, such as a biometric
Authentication Credentials Combination of the user ID or account ID plus the authentication factor(s) used to authenticate an individual,
device, or process,
Authorization Granting of access or other rights to a user, program, or process. For a network, authorization defines what an
individual or program can do after successful authentication.
For the purposes of a payment card transaction authorization occurs when a merchant receives transaction
approval after the acquirer validates the transaction with the issuer/processor.
Backup Duplicate copy of data made for archiving purposes or for protecting against damage or loss.
Bluetooth Wireless protocol using short-range communications technology to facilitate transmission of data over short
distances.
Cardholder Non-consumer or consumer customer to whom a payment card is issued to or any individual authorized to use the
payment card.
Cardholder Data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full
PAN plus any of the following: cardholder name, expiration date and/or service code
See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not
stored) as part of a payment transaction.
Cardholder Data Environment The people, processes and technology that store, process or transmit cardholder data or sensitive authentication
data, including any connected system components.
B
C
Card Verification Code or
Value
Also known as Card Validation Code or Value, or Card Security Code.
Refers to either: (1) magnetic-stripe data, or (2) printed security features.
(1) Data element on a card's magnetic stripe that uses secure cryptographic process to protect data integrity on
the stripe, and reveals any alteration or counterfeiting. Referred to as CAV, CVC, CVV, or CSC depending on
payment card brand. The following list provides the terms for each card brand:
CAV Card Authentication Value (JCB payment cards)
CVC Card Validation Code (MasterCard payment cards)
CVV Card Verification Value (Visa and Discover payment cards)
CSC Card Security Code (American Express)
(2) For Discover, JCB, MasterCard, and Visa payment cards, the second type of card verification value or code is the
rightmost three-digit value printed in the signature panel area on the back of the card. For American Express
payment cards, the code is a four-digit unembossed number printed above the PAN on the face of the payment
cards. The code is uniquely associated with each individual piece of plastic and ties the PAN to the plastic. The
following list provides the terms for each card brand:
CID Card Identification Number (American Express and Discover payment cards)
CAV2 Card Authentication Value 2 (JCB payment cards)
CVC2 Card Validation Code 2 (MasterCard payment cards)
CVV2 Card Verification Value 2 (Visa payment cards)
CERT Acronym for Carnegie Mellon University's Computer Emergency Response Team. The CERT Program develops
and promotes the use of appropriate technology and systems management practices to resist attacks on
networked systems, to limit damage, and to ensure continuity of critical services.
CIS Acronym for Center for Internet Security. Non-profit enterprise with mission to help organizations reduce the
risk of business and e-commerce disruptions resulting from inadequate technical security controls.
Column-Level Database
Encryption
Technique or technology (either software or hardware) for encrypting contents of a specific column in a database
versus the full contents of the entire database. Alternatively, see Disk Encryption or File-Level Encryption.
Compensating Controls Compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to
legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the
requirement through implementation of other controls. Compensating controls must:
(1) Meet the intent and rigor of the original PCI DSS requirement;
(2) Provide a similar level of defense as the original PCI DSS requirement;
(3) Be above and beyond other PCI DSS requirements (not simply in compliance with other PCI DSS
requirements); and
(4) Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
See Compensating Controls Appendices B and C in PCI DSS Requirements and Security Assessment Procedures
for guidance on the use of compensating controls.
Compromise Also referred to as data compromise, or data breach. Intrusion into a computer system where unauthorized
disclosure/theft, modification, or destruction of cardholder data is suspected.
Console Screen and keyboard which permits access and control of a server, mainframe computer or other system type in a
networked environment.
Consumer Individual purchasing goods, services, or both.
Cryptography Discipline of mathematics and computer science concerned with information security, particularly encryption and
authentication. In applications and network security, it is a tool for access control, information confidentiality, and
integrity.
Database Structured format for organizing and maintaining easily retrievable information. Simple database examples are
tables and spreadsheets.
Database Administrator Also referred to as DBA. Individual responsible for managing and administering databases.
Default Accounts Login account predefined in a system, application, or device to permit initial access when system is first put into
service. Additional default accounts may also be generated by the system as part of the installation process.
Default Password Password on system administration, user, or service accounts predefined in a system, application, or device;
usually associated with default account. Default accounts and passwords are published and well known, and
therefore easily guessed.
D
Degaussing Also called disk degaussing. Process or technique that demagnetizes the disk such that all data stored on the disk
is permanently destroyed.
Disk Encryption Technique or technology (either software or hardware) for encrypting all stored data on a device (for example, a
hard disk or flash drive). Alternatively, File- Level Encryption or Column-Level Database Encryption is used to
encrypt contents of specific files or columns.
DMZ Abbreviation for demilitarized zone. Physical or logical sub-network that provides an additional layer of security
to an organizations internal private network. The DMZ adds an additional layer of network security between the
Internet and an organizations internal network so that external parties only have direct connections to devices in
the DMZ rather than the entire internal network.
DNS Acronym for Domain Name System or domain name server. System that stores information associated with
domain names in a distributed database on networks such as the Internet.
DSS Acronym for Data Security Standard and also referred to as PCI DSS.
Dual Control Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions
or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable
transactions. No single person is permitted to access or use the materials (for example, the cryptographic key). For
manual key generation, conveyance, loading, storage, and retrieval, dual control requires dividing knowledge of
the key among the entities. (See also Split Knowledge.)
Dynamic Packet Filtering See Stateful Inspection.
ECC Acronym for Elliptic Curve Cryptography. Approach to public-key cryptography based on elliptic curves over
finite fields. See Strong Cryptography.
Egress Filtering Method of filtering outbound network traffic such that only explicitly allowed traffic is permitted to leave the
network.
Encryption Process of converting information into an unintelligible form except to holders of a specific cryptographic key. Use
of encryption protects information between the encryption process and the decryption process (the inverse of
encryption) against unauthorized disclosure. See Strong Cryptography.
Encryption Algorithm A sequence of mathematical instructions used for transforming unencrypted text or data to encrypted text or data,
and back again. See Strong Cryptography.
E
Entity Term used to represent the corporation, organization or business which is undergoing a PCI DSS review.
File Integrity Monitoring Technique or technology under which certain files or logs are monitored to detect if they are modified. When
critical files or logs are modified, alerts should be sent to appropriate security personnel.
File-Level Encryption Technique or technology (either software or hardware) for encrypting the full contents of specific files.
Alternatively, see Disk Encryption or Column-Level Database Encryption.
FIPS Acronym for Federal Information Processing Standards. Standards that are publicly recognized by the U.S.
Federal Government; also for use by non- government agencies and contractors.
Firewall Hardware and/or software technology that protects network resources from unauthorized access. A firewall
permits or denies computer traffic between networks with different security levels based upon a set of rules and
other criteria.
Forensics Also referred to as computer forensics. As it relates to information security, the application of investigative tools
and analysis techniques to gather evidence from computer resources to determine the cause of data compromises.
FTP Acronym for File Transfer Protocol. Network protocol used to transfer data from one computer to another
through a public network such as the Internet. FTP is widely viewed as an insecure protocol because passwords
and file contents are sent unprotected and in clear text. FTP can be implemented securely via SSH or other
technology.
GPRS
Acronym for General Packet Radio Service. Mobile data service available to users of GSM mobile phones.
Recognized for efficient use of limited bandwidth. Particularly suited for sending and receiving small bursts of data,
such as e-mail and web browsing.
GSM Acronym for Global System for Mobile Communications. Popular standard for mobile phones and networks.
Ubiquity of GSM standard makes international roaming very common between mobile phone operators, enabling
subscribers to use their phones in many parts of the world.
G
F
Hashing Process of rendering cardholder data unreadable by converting data into a fixed-length message digest via Strong
Cryptography. Hashing is a (mathematical) function in which a non-secret algorithm takes any arbitrary length
message as input and produces a fixed length output (usually called a hash code or message digest). A hash
function should have the following properties:
(1) It is computationally infeasible to determine the original input given only the hash code,
(2) It is computationally infeasible to find two inputs that give the same hash code.
In the context of PCI DSS, hashing must be applied to the entire PAN for the hash code to be considered rendered
unreadable. It is recommended that hashed cardholder data includes a salt value as input to the hashing function
(see Salt).
Host Main computer hardware on which computer software is resident.
Hosting Provider Offers various services to merchants and other service providers. Services range from simple to complex; from
shared space on a server to a whole range of shopping cart options; from payment applications to connections
to payment gateways and processors; and for hosting dedicated to just one customer per server. A hosting
provider may be a shared hosting provider, who hosts multiple entities on a single server.
HTTP Acronym for hypertext transfer protocol. Open internet protocol to transfer or convey information on the World
Wide Web.
HTTPS Acronym for hypertext transfer protocol over secure socket layer. Secure HTTP that provides authentication and
encrypted communication on the World Wide Web designed for security-sensitive communication such as web-
based logins.
Hypervisor Software or firmware responsible for hosting and managing virtual machines. For the purposes of PCI DSS, the
hypervisor system component also includes the virtual machine monitor (VMM).
ID Identifier for a particular user or application.
H
I
IDS Acronym for intrusion detection system. Software or hardware used to identify and alert on network or system
intrusion attempts. Composed of sensors that generate security events; a console to monitor events and alerts and
control the sensors; and a central engine that records events logged by the sensors in a database. Uses system of
rules to generate alerts in response to security events detected.
IETF Acronym for Internet Engineering Task Force. Large, open international community of network designers,
operators, vendors, and researchers concerned with evolution of Internet architecture and smooth operation of
Internet. The IETF has no formal membership and is open to any interested individual.
Index Token A cryptographic token that replaces the PAN, based on a given index for an unpredictable value.
Information Security Protection of information to insure confidentiality, integrity, and availability.
Information System Discrete set of structured data resources organized for collection, processing, maintenance, use, sharing,
dissemination, or disposition of information.
Ingress Filtering Method of filtering inbound network traffic such that only explicitly allowed traffic is permitted to enter the
network.
Insecure
Protocol/Service/Port
A protocol, service, or port that introduces security concerns due to the lack of controls over confidentiality and/or
integrity. These security concerns include services, protocols, or ports that transmit data and authentication
credentials (e.g., password/passphrase in clear-text over the Internet), or that easily allow for exploitation by
default or if misconfigured. Examples of insecure services, protocols, or ports include but are not limited to FTP,
Telnet, POP3, IMAP, and SNMP.
IP Acronym for internet protocol. Network-layer protocol containing address information and some control
information that enables packets to be routed. IP is the primary network-layer protocol in the Internet protocol
suite.
IP Address Also referred to as internet protocol address. Numeric code that uniquely identifies a particular computer on the
Internet.
IP Address Spoofing Attack technique used by a malicious individual to gain unauthorized access to computers. The malicious individual
sends deceptive messages to a computer with an IP address indicating that the message is coming from a trusted
host.
IPS Acronym for intrusion prevention system. Beyond an IDS, an IPS takes the additional step of blocking the
attempted intrusion.
IPSEC Abbreviation for Internet Protocol Security. Standard for securing IP communications by encrypting and/or
authenticating all IP packets. IPSEC provides security at the network layer.
ISO Better known as International Organization for Standardization. Non- governmental organization consisting of a
network of the national standards institutes of over 150 countries, with one member per country and a central
secretariat in Geneva, Switzerland, that coordinates the system.
Issuer Entity that issues payment cards or performs, facilitates, or supports issuing services including but not limited to
issuing banks and issuing processors. Also referred to as issuing bank or issuing financial institution.
Issuing services Examples of issuing services may include but are not limited to authorization and card personalization.
Key In cryptography, a key is a value that determines the output of an encryption algorithm when transforming plain
text to ciphertext. The length of the key generally determines how difficult it will be to decrypt the ciphertext in a
given message. See Strong Cryptography.
Key Management In cryptography, it is the set of processes and mechanisms which support key establishment and maintenance,
including replacing older keys with new keys as necessary.
LAN
Acronym for local area network. A group of computers and/or other devices that share a common
communications line, often in a building or group of buildings.
LDAP Acronym for Lightweight Directory Access Protocol. Authentication and authorization data repository utilized for
querying and modifying user permissions and granting access to protected resources.
Log See Audit Log.
LPAR Abbreviation for logical partition. A system of subdividing, or partitioning, a computer's total
resourcesprocessors, memory and storageinto smaller units that can run with their own, distinct copy of the
operating system and applications. Logical partitioning is typically used to allow the use of different operating
systems and applications on a single device. The partitions may or may not be configured to communicate with
each other or share some resources of the server, such as network interfaces.
L
K
MAC Acronym for message authentication code. In cryptography, it is a small piece of information used to
authenticate a message. See Strong Cryptography.
MAC Address Abbreviation for media access control address. Unique identifying value assigned by manufacturers to network
adapters and network interface cards.
Magnetic-Stripe Data Also referred to as track data. Data encoded in the magnetic stripe or chip used for authentication and/or
authorization during payment transactions. Can be the magnetic stripe image on a chip or the data on the track 1
and/or track 2 portion of the magnetic stripe.
Mainframe Computers that are designed to handle very large volumes of data input and output and emphasize throughput
computing. Mainframes are capable of running multiple operating systems, making it appear like it is operating as
multiple computers. Many legacy systems have a mainframe design.
Malicious Software /
Malware
Software designed to infiltrate or damage a computer system without the owner's knowledge or consent. Such
software typically enters a network during many business-approved activities, which results in the exploitation of
system vulnerabilities. Examples include viruses, worms, Trojans (or Trojan horses), spyware, adware, and rootkits.
Masking In the context of PCI DSS, it is a method of concealing a segment of data when displayed or printed. Masking is
used when there is no business requirement to view the entire PAN. Masking relates to protection of PAN when
displayed or printed. See Truncation for protection of PAN when stored in files, databases, etc.
Merchant For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos
of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods
and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also
be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of
other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly
billing, but also is a service provider if it hosts merchants as customers.
Monitoring Use of systems or processes that constantly oversee computer or network resources for the purpose of alerting
personnel in case of outages, alarms, or other predefined events.
MPLS Acronym for multi protocol label switching. Network or telecommunications mechanism designed for connecting
a group of packet-switched networks.
M
NAT Acronym for network address translation. Known as network masquerading or IP masquerading. Change of an IP
address used within one network to a different IP address known within another network.
Network Two or more computers connected together via physical or wireless means.
Network Administrator Personnel responsible for managing the network within an entity. Responsibilities typically include but are not
limited to network security, installations, upgrades, maintenance and activity monitoring.
Network Components Include, but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other
security appliances.
Network Security Scan Process by which an entitys systems are remotely checked for vulnerabilities through use of manual or automated
tools. Security scans that include probing internal and external systems and reporting on services exposed to the
network. Scans may identify vulnerabilities in operating systems, services, and devices that could be used by
malicious individuals.
Network Segmentation Network segmentation isolates system components that store, process, or transmit cardholder data from systems
that do not. Adequate network segmentation may reduce the scope of the cardholder data environment and thus
reduce the scope of the PCI DSS assessment. See the Network Segmentation section in the PCI DSS Requirements
and Security Assessment Procedures for guidance on using network segmentation. Network segmentation is not a
PCI DSS requirement. See System Components.
NIST Acronym for National Institute of Standards and Technology. Non-regulatory federal agency within U.S.
Commerce Department's Technology Administration. Their mission is to promote U.S. innovation and industrial
competitiveness by advancing measurement science, standards, and technology to enhance economic security and
improve quality of life.
NMAP Security-scanning software that maps networks and identifies open ports in network resources.
Non-Consumer Users Individuals, excluding cardholders, who access system components, including but not limited to employees,
administrators, and third parties.
NTP Acronym for Network Time Protocol. Protocol for synchronizing the clocks of computer systems, network
devices and other system components.
N
Off-the-Shelf Description of products that are stock items not specifically customized or designed for a specific customer or user
and are readily available for use.
Operating System / OS Software of a computer system that is responsible for the management and coordination of all activities and the
sharing of computer resources. Examples of operating systems include Microsoft Windows, Mac OS, Linux and
Unix.
OWASP Acronym for Open Web Application Security Project. A non-profit organization focused on improving the security
of application software. OWASP maintains a list of critical vulnerabilities for web applications. (See
http://www.owasp.org).
PA-QSA Acronym for Payment Application Qualified Security Assessor, company approved by the PCI SSC to conduct
assessments on payment applications against the PA-DSS.
PAN Acronym for primary account number and also referred to as account number. Unique payment card number
(typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
Password / Passphrase A string of characters that serve as an authenticator of the user.
Pad In cryptography, the one-time pad is an encryption algorithm with text combined with a random key or "pad" that
is as long as the plain-text and used only once. Additionally, if key is truly random, never reused, and, kept secret,
the one-time pad is unbreakable
Parameterized Queries A means of structuring SQL queries to limit escaping and thus prevent injection attacks.
PAT Acronym for port address translation and also referred to as network address port translation. Type of NAT
that also translates the port numbers.
Patch Update to existing software to add functionality or to correct a defect.
Payment Application Any application that stores, processes, or transmits cardholder data as part of authorization or settlement
O
P
Payment Cards For purposes of PCI DSS, any payment card/device that bears the logo of the founding members of PCI SSC, which
are American Express, Discover Financial Services, JCB International, MasterCard Worldwide, or Visa, Inc.
PCI Acronym for Payment Card Industry.
PDA
Acronym for personal data assistant or personal digital assistant. Handheld mobile devices with capabilities
such as mobile phones, e-mail, or web browser.
PED PIN entry device
Penetration Test Penetration tests attempt to exploit vulnerabilities to determine whether unauthorized access or other malicious
activity is possible. Penetration testing includes network and application testing as well as controls and processes
around the networks and applications, and occurs from both outside the network trying to come in (external testing)
and from inside the network.
Personnel Full-time and part-time employees, temporary employees, contractors, and consultants who are resident on the
entitys site or otherwise have access to the cardholder data environment.
Personally Identifiable
Information
Information that can be utilized to identify an individual including but not limited to name, address, social security
number, phone number, etc.
PIN Acronym for personal identification number. Secret numeric password known only to the user and a system to
authenticate the user to the system. The user is only granted access if the PIN the user provided matches the PIN
in the system. Typical PINs are used for automated teller machines for cash advance transactions. Another type of
PIN is one used in EMV chip cards where the PIN replaces the cardholders signature.
PIN Block A block of data used to encapsulate a PIN during processing. The PIN block format defines the content of the PIN
block and how it is processed to retrieve the PIN. The PIN block is composed of the PIN, the PIN length, and may
contain subset of the PAN.
POI Acronym for Point of Interaction, the initial point where data is read from a card. An electronic transaction-
acceptance product, a POI consists of hardware and software and is hosted in acceptance equipment to enable a
cardholder to perform a card transaction. The POI may be attended or unattended. POI transactions are typically
integrated circuit (chip) and/or magnetic-stripe card-based payment transactions.
Policy Organization-wide rules governing acceptable use of computing resources, security practices, and guiding
development of operational procedures
POS Acronym for point of sale. Hardware and/or software used to process payment card transactions at merchant
locations.
Private Network Network established by an organization that uses private IP address space. Private networks are commonly
designed as local area networks. Private network access from public networks should be properly protected with
the use of firewalls and routers.
Procedure Descriptive narrative for a policy. Procedure is the how to for a policy and describes how the policy is to be
implemented.
Protocol Agreed-upon method of communication used within networks. Specification describing rules and procedures that
computer products should follow to perform activities on a network.
PTS Acronym for PIN Transaction Security, PTS is a set of modular evaluation requirements managed by PCI Security
Standards Council, for PIN acceptance POI terminals. Please refer to www.pcisecuritystandards.org.
Public Network Network established and operated by a telecommunications provider, for specific purpose of providing data
transmission services for the public. Data over public networks can be intercepted, modified, and/or diverted while
in transit. Examples of public networks in scope of the PCI DSS include, but are not limited to, the Internet,
wireless, and mobile technologies.
PVV Acronym for PIN verification value. Discretionary value encoded in magnetic stripe of payment card.
QSA Acronym for Qualified Security Assessor, company approved by the PCI SSC to conduct PCI DSS on-site
assessments.
RADIUS Abbreviation for Remote Authentication Dial-In User Service. Authentication and accounting system. Checks if
information such as username and password that is passed to the RADIUS server is correct, and then authorizes
access to the system. This authentication method may be used with a token, smart card, etc., to provide two-
factor authentication.
RBAC
Acronym for role-based access control. Control used to restrict access by specific authorized users based on their
job responsibilities.
Q
R
Remote Access Access to computer networks from a remote location, typically originating from outside the network. An example
of technology for remote access is VPN.
Removable Electronic Media Media that store digitized data and which can be easily removed and/or transported from one computer system to
another. Examples of removable electronic media include CD-ROM, DVD-ROM, USB flash drives and removable
hard drives.
ROC Report on Compliance - Report containing details documenting an entitys compliance status with the PCI DSS.
Report on Validation Also referred to as ROV. Report containing details documenting a payment applications compliance with the PCI
PA-DSS.
Re-keying
Process of changing cryptographic keys. Periodic re-keying limits the amount of data encrypted by a single key.
Remote Lab Environment A lab that is not maintained by the PA-QSA.
Reseller / Integrator An entity that sells and/or integrates payment applications but does not develop them.
RFC 1918 The standard identified by the Internet Engineering Task Force (IETF) that defines the usage and appropriate
address ranges for private (non-internet routable) networks.
Risk Analysis / Risk
Assessment
Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential)
based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources
to countermeasures so as to minimize total exposure.
Rootkit Type of malicious software that when installed without authorization, is able to conceal its presence and gain
administrative control of a computer system.
Router Hardware or software that connects two or more networks. Functions as sorter and interpreter by looking at
addresses and passing bits of information to proper destinations. Software routers are sometimes referred to as
gateways.
RSA Algorithm for public-key encryption described in 1977 by Ron Rivest, Adi Shamir, and Len Adleman at
Massachusetts Institute of Technology (MIT); letters RSA are the initials of their surnames.
Salt Random string that is concatenated with other data prior to being operated on by a hash function. See also Hash.
S
Sampling The process of selecting a cross-section of a group that is representative of the entire group. Sampling may be
used by assessors to reduce overall testing efforts, when it is validated that an entity has standard, centralized PCI
DSS security and operational processes and controls in place. Sampling is not a PCI DSS requirement.
SANS Acronym for SysAdmin, Audit, Networking and Security, an institute that provides computer security training and
professional certification. (See www.sans.or
Scoping Process of identifying all system components, people, and processes to be included in a PCI DSS assessment. The
first step of a PCI DSS assessment is to accurately determine the scope of the review.
SDLC Acronym for system development life cycle. Phases of the development of a software or computer system that
includes planning, analysis, design, testing, and implementation.
Secure Coding The process of creating and implementing applications that are resistant to tampering and/or compromise.
Secure Wipe Also called secure delete, a program utility used to delete specific files permanently from a computer system.
Security Officer Also called secure delete, a program utility used to delete specific files permanently from a computer system.
Security Policy Set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive
information
Security Protocols Network communications protocols designed to secure the transmission of data. Examples of security protocols
include, but are not limited to SSL/TLS, IPSEC, SSH, etc.
SAQ Acronym for Self-Assessment Questionnaire. Tool used by any entity to validate its own compliance with the PCI
DSS.
Sensitive Area Any data center, server room or any area that houses systems that stores, processes, or transmits cardholder data.
This excludes the areas where only point-of-sale terminals are present such as the cashier areas in a retail store.
Sensitive Authentication Data Security-related information (including but not limited to card validation codes/values, full magnetic-stripe data,
PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.
Separation of Duties Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able
to subvert the process.
Server Computer that provides a service to other computers, such as processing communications, file storage, or
accessing a printing facility. Servers include, but are not limited to web, database, application, authentication, DNS,
mail, proxy, and NTP.
Service Code Three-digit or four-digit value in the magnetic-stripe that follows the expiration date of the payment card on the
track data. It is used for various things such as defining service attributes, differentiating between international
and national interchange, or identifying usage restrictions.
Service Provider Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of
cardholder data. This also includes companies that provide services that control or could impact the security of
cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other
services as well as hosting providers and other entities. Entities such as telecommunications companies that only
provide communication links without access to the application layer of the communication link are excluded.
SHA-1/SHA-2 Acronym for Secure Hash Algorithm. A family or set of related cryptographic hash functions including SHA-1 and
SHA-2. See Strong Cryptography.
Smart Card Also referred to as chip card or IC card (integrated circuit card). A type of payment card that has integrated
circuits embedded within. The circuits, also referred to as the chip, contain payment card data including but not
limited to data equivalent to the magnetic-stripe data.
SNMP Acronym for Simple Network Management Protocol. Supports monitoring of network attached devices for any
conditions that warrant administrative attention.
Spyware Type of malicious software that when installed, intercepts or takes partial control of the users computer without
the users consent.
SQL
Acronym for Structured Query Language. Computer language used to create, modify, and retrieve data from
relational database management systems.
SQL Injection Form of attack on database-driven web site. A malicious individual executes unauthorized SQL commands by
taking advantage of insecure code on a system connected to the Internet. SQL injection attacks are used to steal
information from a database from which the data would normally not be available and/or to gain access to an
organizations host computers through the computer that is hosting the database.
SSH Abbreviation for Secure Shell. Protocol suite providing encryption for network services like remote login or
remote file transfer.
SSL Acronym for Secure Sockets Layer. Established industry standard that encrypts the channel between a web
browser and web server to ensure the privacy and reliability of data transmitted over this channel.
Stateful Inspection Also called dynamic packet filtering, it is a firewall capability that provides enhanced security by keeping track of
communications packets. Only incoming packets with a proper response (established connections) are allowed
through the firewall.
Strong Cryptography Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-
management practices. Cryptography is a method to protect data and includes both encryption (which is
reversible) and hashing (which is not reversible, or one way). Examples of industry-tested and accepted
standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys),
RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).
See NIST Special Publication 800-57 (http://csrc.nist.gov/publications/) for more information.
SysAdmin Abbreviation for system administrator. Individual with elevated privileges who is responsible for managing a
computer system or network.
System Components Any network component, server, or application included in or connected to the cardholder data environment.
System-level object Anything on a system component that is required for its operation, including but not limited to application
executable and configuration files, system configuration files, static and shared libraries & DLL's, system
executables, device drivers and device configuration files, and added third-party components.
TACACS Acronym for Terminal Access Controller Access Control System. Remote authentication protocol commonly used
in networks that communicates between a remote access server and an authentication server to determine user
access rights to the network. This authentication method may be used with a token, smart card, etc., to provide
two-factor authentication.
TCP Acronym for Transmission Control Protocol. Basic communication language or protocol of the Internet.
TDES Acronym for Triple Data Encryption Standard and also known as 3DES or Triple DES. Block cipher formed
from the DES cipher by using it three times. See Strong Cryptography.
T
TELNET Abbreviation for telephone network protocol. Typically used to provide user- oriented command line login
sessions to devices on a network. User credentials are transmitted in clear text.
Threat Condition or activity that has the potential to cause information or information processing resources to be
intentionally or accidentally lost, modified, exposed, made inaccessible, or otherwise affected to the detriment of
the organization
TLS Acronym for Transport Layer Security. Designed with goal of providing data secrecy and data integrity between
two communicating applications. TLS is successor of SSL.
Token A value provided by hardware or software that usually works with an authentication server or VPN to perform
dynamic or two-factor authentication. See RADIUS, TACACS, and VPN.
Transaction Data Data related to electronic payment card transaction.
Trojan Also referred to as Trojan horse. A type of malicious software that when installed, allows a user to perform a
normal function while the Trojan performs malicious functions to the computer system without the users
knowledge.
Truncation Method of rendering the full PAN unreadable by permanently removing a segment of PAN data. Truncation relates
to protection of PAN when stored in files, databases, etc. See Masking for protection of PAN when displayed on
screens, paper receipts, etc.
Trusted Network Network of an organization that is within the organizations ability to control or manage.
Two-Factor Authentication Method of authenticating a user whereby two or more factors are verified. These factors include something the
user has (such as hardware or software token), something the user knows (such as a password, passphrase, or PIN)
or something the user is or does (such as fingerprints or other forms of biometrics).
Untrusted Network Network that is external to the networks belonging to an organization and which is out of the organizations ability
to control or manage.
V
U
Virtualization Virtualization refers to the logical abstraction of computing resources from physical constraints. One common
abstraction is referred to as virtual machines or VMs, which takes the content of a physical machine and allows it
to operate on different physical hardware and/or along with other virtual machines on the same physical
hardware. In addition to VMs, virtualization can be performed on many other computing resources, including
applications, desktops, networks, and storage.
Virtual Machine Monitor
(VMM)
The VMM is included with the hypervisor and is software that implements virtual machine hardware abstraction. It
manages the system's processor, memory, and other resources to allocate what each guest operating system
requires.
Virtual Machine A self-contained operating environment that behaves like a separate computer. It is also known as the Guest,
and runs on top of a hypervisor.
Virtual Appliance (VA) A VA takes the concept of a pre-configured device for performing a specific set of functions and run this device as a
workload. Often, an existing network device is virtualized to run as a virtual appliance, such as a router, switch, or
firewall.
Virtual Switch or Router A virtual switch or router is a logical entity that presents network infrastructure level data routing and switching
functionality. A virtual switch is an integral part of a virtualized server platform such as a hypervisor driver,
module, or plug-in.
Virtual Terminal A virtual terminal is web-browser-based access to an acquirer, processor or third party service provider website to
authorize payment card transactions, where the merchant manually enters payment card data via a securely
connected web browser. Unlike physical terminals, virtual terminals do not read data directly from a payment
card. Because payment card transactions are entered manually, virtual terminals are typically used instead of
physical terminals in merchant environments with low transaction volumes.
VLAN Abbreviation for virtual LAN or virtual local area network. Logical local area network that extends beyond a
single traditional physical local area network.
VPN Acronym for virtual private network. A computer network in which some of connections are virtual circuits
within some larger network, such as the Internet, instead of direct connections by physical wires. The end points of
the virtual network are said to be tunneled through the larger network when this is the case. While a common
application consists of secure communications through the public Internet, a VPN may or may not have strong
security features such as authentication or content encryption.
A VPN may be used with a token, smart card, etc., to provide two-factor authentication.
Vulnerability Flaw or weakness which, if exploited, may result in an intentional or unintentional compromise of a system.
WAN
Acronym for wide area network. Computer network covering a large area, often a regional or company wide
computer system.
Web Application An application that is generally accessed via a web browser or through web services. Web applications may be
available via the Internet or a private, internal network.
Web Server Computer that contains a program that accepts HTTP requests from web clients and serves the HTTP responses
(usually web pages).
WEP Acronym for Wired Equivalent Privacy. Weak algorithm used to encrypt wireless networks. Several serious
weaknesses have been identified by industry experts such that a WEP connection can be cracked with readily
available software within minutes. See WPA.
Wireless Access Point Network that connects computers without a physical connection to wires.
WLAN Acronym for wireless local area network. Local area network that links two or more computers or devices
without wires.
WPA/WPA2 Acronym for WiFi Protected Access. Security protocol created to secure wireless networks. WPA is the successor
to WEP.. WPA2 was also released as the next generation of WPA.
W
Scope Definition
Return to Table of content
Scope:
IP address/URL Name Type Purpose Owner
IP address/URL Name Type Purpose Owner
Area of computer system network that possesses cardholder data or sensitive authentication data and those
systems and segments that directly attach or support cardholder processing"
Perimeter
Internal
Define your Card Data Environment (CDE)
Scope Definition
System Admin Criticality Patch level Last Scan date Scan report location
System Admin Criticality Patch level last Scan date Last scan report
Table of content Intro Chart Compliance
Chart
Severity
Chart Priority
Merchant
Types
ORGANIZATION
NAME:
Merchant Type: D
PCI-DSS
REQUIREMENTS
% compliance # of Requirements # In Place
# Not in
Place
# Compensating
# Not
Applicable
# Not
Tested
Severity Max Severity
1 74% 38 26 10 2 0 0 32 163
2 10% 31 3 25 0 0 3 123 136
3 2% 45 1 43 0 0 1 122 128
4 18% 11 2 8 0 0 1 41 51
5 9% 11 1 8 0 0 2 46 51
6 2% 42 1 41 0 0 0 143 144
7 73% 11 1 2 7 0 1 7 31
8 5% 37 2 35 0 0 0 97 103
9 16% 45 6 36 1 0 2 102 115
10 7% 41 3 33 0 3 2 103 121
11 6% 32 1 29 1 0 1 130 134
12 9% 46 3 41 1 0 1 88 98
Total 16% 390 50 311 12 3 14 1034 1275
What's your company name?
Click on B3 to select your Merchant type (A, A-EP, PE2P,B,B-IP,C, C-VT, D,S)
SEVERITY Compliance Status
81%
.
#P1
in place
#P1
Total
#P2
in place
#P2
Total
#P3
in place
#P3
Total
#P4
in place
#P4
Total
#P5
in place
#P5
Total
#P6
in place
#P6
Total
3 3 22 26 0 0 0 0 0 0 3 8
0 0 1 15 2 15 0 0 0 0 0 1
1 10 0 1 0 0 0 0 0 29 0 5
0 0 2 10 0 0 0 0 0 0 0 1
0 0 1 10 0 0 0 0 0 0 0 1
0 0 0 0 0 34 0 0 0 0 1 8
0 0 0 0 0 0 8 10 0 0 0 1
0 0 0 0 0 0 2 36 0 0 0 1
0 2 0 6 0 0 0 0 6 36 1 1
0 0 0 0 0 0 3 40 0 0 0 1
0 0 0 20 0 0 1 11 0 0 1 1
0 2 1 6 0 0 1 9 0 0 2 29
4 17 27 94 2 49 15 106 6 65 8 58
PRIORITY BOARD based on PCI DSS APPROACH
4% 14% 24% 9% 14% 29%
Documentation required to be in compliance with DSS V3.
Return to table of content This sheet provides the detailed list of documentation that your organisation should
have ready for the auditor visit. Each document is detailed in terms of content and
associated PCI DSS V3 requirements. The rest of this sheet could be used to track various
parameter along the life of these documents such as version, owner, where to find it.
The content of this sheet will be sent for a contribution of $75. Just Contact
d@dgozone.com
ORDER
Ref Title/Topic Description PCI DSS Req Version
Ref Title Description PCI DSS Req Version
Techical documentation
Policies, Procedures and standards documentation
Documentation required to be in compliance with DSS V3.
Owner Approved by Location/link Published/DRAFT
Owner Location Published/DRAFT
Executive Summary Go to Chart Severity
74%
10%
2%
18%
9%
2%
73%
5%
16%
7%
6%
9%
0%
10%
20%
30%
40%
50%
60%
70%
80%
1 2 3 4 5 6 7 8 9 10 11 12
Compliance % per requirement


Return to Table of content Executive Summary Chart Compliance
32
123
122
41
46
143
7
97
102
103
130
88
163
136
128
51 51
144
31
103
115
121
134
98
0
20
40
60
80
100
120
140
160
180
1 2 3 4 5 6 7 8 9 10 11 12
Severity versus max severity per requirement
Table of content Chart Severity Chart Compliance
Priority % in place
1 24%
2 29%
3 4%
4 14%
5 9%
6 14%
0%
5%
10%
15%
20%
25%
30%
35%
1 2 3 4 5 6
Progress by Priority
Progress by Priority
Chart Compliance Executive Summary
Progress by Priority
Return to Table of content
Name Email Tel Function Areas of expertize
Name 1
Name 2
Name 3
Name 4
Return to Table of
content
Executive Summary
Merchant types
Types Description
A Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This
would never apply to face-to-face merchants.
B Imprint-only merchants with no electronic cardholder data storage, or standalone, dial- out terminal merchants with no
electronic cardholder data storage
B Merchants who process cardholder data only via standalone, PTS-approved point-of-interaction devices with an IP
connection to the payment processor.
C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage
D All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by
a payment brand as eligible to complete an SAQ.
S Service Providers
A-EP E-commerce merchants with a websites that do not themselves receive cardholder data but which do affect the security
of the payment transaction and/or the integrity of the page that accepts the consumers cardholder data.
PE2P Merchants using only hardware terminals as part of a validated P2PE solution listed by PCI SSC.
It's important to remember that SAQs are validation documents and whether a merchant is eligible or required to
validate to one of the SAQs, and which SAQ they should validate to, is determined by the payment brands and/or
acquirers. Also, please keep in mind that the v2.0 SAQs are still valid throughout 2014.
Return to Table of content
Compensating

Control Id
#Req Constraints Objective Identified Risk
# #requirement
s for which a
compensating
control is
defined
List constraints precluding
compliance with the original
requirement.
Define the objective of the
original control; identify the
objective met by the
compensating control.
Identify any additional risk
posed by the lack of the original
control.
1
2
3
4
5
6
7
8
9
10
11
Definition of Compensation Control Validation of Compensating Control Maintenance
Define the compensating controls and
explain how they address the objectives of
the original control and the increased risk,
if any.
Define how the compensating controls
were validated and tested.
Define process and controls
in place to maintain
compensating controls
Table of content Executive Summary
NOT
APPLICABLE
#Req Rationals
# # Requirements
that is defined as
NA
Rationals
1
2
3
4
5
6
7
8
9
10
11
Table of content
CRYPTOGRAPHIC KEY METADATA MODEL
Key Label Purpose Type of Key Key Class Key lenght Assets:Application
using the key
Protection
method
Key Owner Storage
location
CRYPTOGRAPHIC KEY METADATA MODEL
Cryptoperiod Comments / Key
Generation
Method
Key Manager
Return to Table of content
SANS Top 20 Critical Security Controls and Subcontrols (+-200) Matching

PCI Reqs
If Any
Matching
level
Score Notes
C1 Critical Control 1: Inventory of Authorized and
Unauthorized Devices
16.67% 1.5
C1.1 An accurate and up-to-date inventory, controlled by active
monitoring and configuration management, can reduce the chance
of attackers finding unauthorized and unprotected systems to
exploit.
Scoping P 0.5 While there is no specific inventory
requirement, the inventory process
is actually part of a scoping exercice.
C1.2 Deploy an automated asset inventory discovery tool and use it to
build a preliminary asset inventory of systems connected to the
enterprise network. Both active tools that scan through network
address ranges and passive tools that identify hosts based on
analyzing their traffic should be employed.
11.1
11.2
P 0.5 No specific inventory requirements
but target discovery is the first part
of the external scanning process.
C1.3 Maintain an asset inventory of all systems connected to the network
and the network devices themselves, recording at least the network
addresses, machine name(s), purpose of each system, an asset
owner responsible for each device, and the department associated
with each device. The inventory should include every system that
has an Internet protocol (IP) address on the network, including, but
not limited to desktops, laptops, servers, network equipment
(routers, switches, firewalls,
Scoping P 0.5 While there is no specific inventory
requirement, the inventory process
is actually part of a scoping exercice.
C1.4 The asset inventory created must also include data on whether the
device is a portable device. Devices such as mobile phones, tablets,
laptops, and other portable electronic devices that store or process
data must be identified, regardless of whether or not they are
attached to the organizations network.
- N 0
C1.5 Ensure that network inventory monitoring tools are operational and
continuously monitoring, keeping the asset inventory up to date on
a real-time basis, looking for deviations from the expected inventory
of assets on the network, and alerting security and/or operations
personnel when deviations are discovered.
- N 0
C1.6 Secure the asset inventory database and related systems, ensuring
that they are included in periodic vulnerability scans and that asset
information is encrypted. Limit access to these systems to
authorized personnel only, and carefully log all such access. For
additional security, a secure copy of the asset inventory may be kept
in an off-line system air-gapped from the production network.
- N 0
C1.7 In addition to an inventory of hardware, organizations should
develop an inventory of information assets that identifies their
critical information and maps critical information to the hardware
assets (including servers, workstations, and laptops) on which it is
located. A department and individual responsible for each
information asset should be identified, recorded, and tracked.
- N 0
C1.8 Deploy network level authentication via 802.1x to limit and control
which devices can be connected to the network. 802.1x must be
tied into the inventory data to determine authorized vs.
unauthorized systems.
- N 0
C1.9 Network access control can be used to monitor authorized systems
so if attacks occur, the impact can be remediated by moving the
untrusted system to a virtual local area network that has minimal
access.
- N 0
C2 Critical Control 2: Inventory of Authorized and
Unauthorized Software
0.00% 0
C2.1 Devise a list of authorized software that is required in the enterprise
for each type of system, including servers, workstations, and laptops
of various kinds and uses.
- N 0
C2.2 Deploy software inventory tools throughout the organization
covering each of the operating system types in use, including
servers, workstations, and laptops. The software inventory system
should track the version of the underlying operating system as well
as the applications installed on it. Furthermore, the tool should
record not only the type of software installed on each system, but
also its version number and patch level.
- N 0
C2.3 The software inventory tool should also monitor for unauthorized
software installed on each machine. This unauthorized software also
includes legitimate system administration software installed on
inappropriate systems where there is no business need for it.
- N 0
C2.4 Deploy application white listing technology that allows systems to
run only approved software and prevents execution of all other
software on the system. Such white listing tools must be based on
acceptable hashing algorithms for determining authorized binaries
to execute on a system.
- N 0
C2.5 Virtual machines and/or air-gapped systems should also be used to
isolate and run applications that are required but based on higher
risk and that should not be installed within a networked
environment.
- N 0
C3 Critical Control 3: Secure Configurations for
Hardware and Software on Laptops, Workstations,
and Servers
45.45% 5
C3.1 Strict configuration management should be followed, building a
secure image that is used to build all new systems that are deployed
to the enterprise. Any existing system that becomes compromised is
re-imaged with the secure build. Regular updates to this image are
integrated into the organizations change management processes.
2.2 F 1
C3.2 System images must have documented security settings that are
tested before deployment, approved by an organization change
control board, and registered with a central image library for the
organization or multiple organizations. These images should be
validated and refreshed on a regular basis (e.g., every six months) to
update their security configuration in light of recent vulnerabilities
and attack vectors.
2.2 F 1
C3.3 Standardized images should represent hardened versions of the
underlying operating system and the applications installed on the
system, such as those released by the NIST, NSA, Defense
Information Systems Agency (DISA), Center for Internet Security
(CIS), and others. This hardening would typically include removal of
unnecessary accounts, as well as the disabling or removal of
unnecessary services. Such hardening also involves, among other
measures, applying patches, closing open and unused network
ports, implementing intrusion detection systems and/or intrusion
prevention systems, and erecting host-based firewalls.
2.1
2.2
2.2.2
2.2.3
2.2.4
F 1
C3.4 Any deviations from the standard build or updates to the standard
build should be documented and approved in a change
management system.
- N 0
C3.5 Organizations should negotiate contracts to buy systems configured
securely out of the box using standardized images, which should be
devised to avoid extraneous software that would increase their
attack surface and susceptibility to vulnerabilities.
- N 0
C3.6 The master images themselves must be stored on securely
configured servers, with integrity checking tools and change
management to ensure that only authorized changes to the images
are possible. Alternatively, these master images can be stored in
offline machines, air-gapped from the production network, with
images copied via secure media to move them between the image
storage servers and the production network.
- N 0
C3.7 Run the last version of software and make sure it is fully patched. 6.1 F 1
C3.7.1 Remove outdated or older software from the system. - N 0 No specific requirements but ASV
scans must fail targetsiff the
version of the operating system is
an older version no longer
supported by the vendo
C3.8 At least once a month, run assessment programs on a varying
sample of systems to determine which ones are configured
according to the secure configuration guidelines.
- N 0
C3.9 Utilize file integrity checking tools on at least a weekly basis to
ensure that critical system files (including sensitive system and
application executables, libraries, and configurations) have not been
altered. All alterations to such files should be automatically reported
to security personnel. The reporting system should have the ability
to account for routine and expected changes, highlighting unusual
or unexpected alterations.
11.5 F 1
C3.10 Implement and test an automated configuration monitoring system
that measures all secure configuration elements that can be
measured through remote testing, using features such as those
included with SCAP-compliant tools to gather configuration
vulnerability information. These automated tests should analyze
both hardware and software changes, network configuration
changes, and any other modifications affecting security of the
system.
- N 0
C3.11 Provide senior executives with charts showing the number of
systems that match configuration guidelines versus those that do
not match, illustrating the change of such numbers month by month
for each organizational unit.
- N 0
C4 Critical Control 4: Continuous Vulnerability
Assessment and Remediation
20.00% 2
C4.1 Organizations should run automated vulnerability scanning tools
against all systems on their networks on a weekly or more frequent
basis. Where feasible, vulnerability scanning should occur on a daily
basis using an up-to-date vulnerability scanning tool.
11.2
11.2.1
11.2.2
11.2.3
P 0.5 PCI requirements less restrictive
(once a quarter or after major
changes
C4.1.1 Any vulnerability identified should be remediated in a timely
manner, with critical vulnerabilities fixed within 48 hours.
6.1 P 0.5 PCI less restrictive in terms of
critical vulnerabilities fixing period
(One month)
C4.2 Event logs should be correlated with information from vulnerability
scans to fulfill two goals. First, personnel should verify that the
activity of the regular vulnerability scanning tools themselves is
logged. Second, personnel should be able to correlate attack
detection events with earlier vulnerability scanning results to
determine whether the given exploit was used against a known-
vulnerable target
- N 0
C4.3 Organizations should deploy automated patch management tools
and software update tools for all systems for which such tools are
available and safe.
- N 0
C4.4 In order to overcome limitations of unauthenticated vulnerability
scanning, organizations should ensure that all vulnerability scanning
is performed in authenticated mode either with agents running
locally on each end system to analyze the security configuration or
with remote scanners that are given administrative rights on the
system being tested.
- N 0 11.2 requires ASV to run
unauthenticated scans with the
known limitations. PCI rules should
align on Top 20.
C4.5 Organizations should compare the results from back-to-back
vulnerability scans to verify that vulnerabilities were addressed
either by patching, implementing a compensating control, or
documenting and accepting a reasonable business risk. Such
acceptance of business risks for existing vulnerabilities should be
periodically reviewed to determine if newer compensating controls
or subsequent patches can address vulnerabilities that were
previously accepted, or if conditions have changed increasing the
risk.
6.2 F 1 For the risk approach. Nothing
about validation /control process
C4.6 Vulnerability scanning tools should be tuned to compare services
that are listening on each machine against a list of authorized
services. The tools should be further tuned to identify changes over
time on systems for both authorized and unauthorized services.
Organizations should use government-approved scanning
configuration files for their scanning to ensure that minimum
standards are met.
- N 0 Checking services and configuration
as part of a scan isn't explicitely
required by PCI.
C4.7 Security personnel should chart the numbers of unmitigated, critical
vulnerabilities for each department/division.
- N 0
C4.8 Security personnel should share vulnerability reports indicating
critical issues with senior management to provide effective
incentives for mitigation.
- N 0
C4.9 Organizations should measure the delay in patching new
vulnerabilities and ensure that the delay is equal to or less than the
benchmarks set forth by the organization. The timeframe should be
no more than a week for critical patches, unless a mitigating control
that blocks exploitation is available.
- N 0
C4.10 Critical patches must be evaluated in a test environment before
being pushed into production on enterprise systems. If such patches
break critical business applications on test machines, the
organization must devise other mitigating controls that block
exploitation on systems where the patch cannot be deployed
because of its impact on business functionality.
- N 0
C5 Critical Control 5: Malware Defenses
37.50% 3
C5.1 Organizations should monitor workstations, servers, and mobile
devices for active, up-to-date anti-malware protection with anti-
virus, anti-spyware,
5.1 P 0.5 PCI doesn't mention ati-malware
protection.
C5.1.1 personal firewalls 1.4 F 1
C5.1.2 and host-based IPS functionality. 11.4 P 0.5 11.4 requires the use of network
based IPS/IDS. PCI doesn't require
host based IPS
C5.1.3 All malware detection events should be sent to enterprise anti-
malware administration tools and event log servers.
- N 0 PCI doesn't address the
centralization of malware event
management. The closest
requirement is 5.2 requiring
generation of audit logs
C5.2 Organizations should employ anti-malware software and signature
auto update features or have administrators manually push updates
to all machines on a daily basis.
5.2 F 1 5.2 is the closest requirement:
(Anti-virus must be current)
C5.2.1 After applying an update, automated systems should verify that
each system has received its signature update.
- N 0
C5.3 Organizations should configure laptops, workstations, and servers
so that they will not auto-run content from USB tokens (i.e., thumb
drives), USB hard drives, CDs/DVDs, Firewire devices, external
serial advanced technology attachment devices, mounted network
shares, or other removable media.
- N 0
C5.4 Organizations should configure systems so that they conduct an
automated anti-malware scan of removable media when it is
inserted.
- N 0
C5.5 All attachments entering the organizations e-mail gateway should
be scanned and blocked if they contain malicious code. This
scanning should be done before the e-mail is placed in the users
inbox.
- N 0 Should be part of 5.2 but email
servers could not be within the
scope.
C5.6 Behavioral-based anomaly detection should be used to complement
and enhance traditional signature-based detection.
- N 0
C5.7 Organizations should deploy network access control tools to verify
security configuration and patch-level compliance before granting
access to a network.
- N 0
C5.8 Continuous monitoring should be performed on outbound traffic.
Any large transfers of data or unauthorized encrypted traffic should
be flagged and, if validated as malicious, the computer should be
moved to an isolated VLAN.
- N 0
C6 Critical Control 6: Application Software Security
50.00% 4.5
C6.1 Organizations should protect web applications by deploying web
application firewalls that inspect all traffic flowing to the web
application for common web application attacks, including but not
limited to cross-site scripting, SQL injection, command injection, and
directory traversal attacks. For applications that are not web- based,
specific application firewalls should be deployed if such tools are
available for the given application type. If the traffic is encrypted,
the device should either sit behind the encryption or be capable of
decrypting the traffic prior to analysis. If neither option is
appropriate, a host-based web application firewall should be
deployed.
6.6 P 0.5 Code review OR WAF
C6.2 At a minimum, explicit error checking should be done for all input.
Whenever a variable is created in source code, the size and type
should be determined. When input is provided by the user it should
be verified that it does not exceed the size or the data type of the
memory location in which it is stored or moved in the future.
- N 0
C6.3 Organizations should test in-house-developed and third-party-
procured web and other application software for coding errors and
malware insertion, including backdoors prior to deployment using
automated static code analysis software. If source code is not
available, these organizations should test compiled code using static
binary analysis tools. In particular, input validation and output
encoding routines of application software should be carefully
reviewed and tested.
6.3.2
6.4.5.3
6.6
F 1 No mention of automated static
code analysis software
C6.4 Organizations should test in-house-developed and third-party-
procured web applications for common security weaknesses using
automated remote web application scanners prior to deployment,
whenever updates are made to the application
and on a regular recurring basis.
11.2
11.2.3
11.3.2
F 1
C6.5 For applications that rely on a database, organizations should
conduct a configuration review of both the operating system
housing the database and the database software itself, checking
settings to ensure that the database system has been hardened
using standard hardening templates.
- N 0
C6.6 Organizations should verify that security considerations are taken
into account throughout the requirements, design, implementation,
testing, and other phases of the software development life cycle of
all applications.
6.3 F 1
C6.7 Organizations should ensure that all software development
personnel receive training in writing secure code for their specific
development environment.
6.5 F 1 Testing procedure 6.5.a require to
verify training requirement t
C6.8 Require that all in-house-developed software include white-list
filtering capabilities for all data input and output associated with the
system. These white lists should be configured to allow in or out
only the types of data needed for the system, blocking other forms
of data that are not required.
- N 0
C6.9 Sample scripts, libraries, components, compilers, or any other
unnecessary code that is not being used by an application should be
uninstalled or removed from the system.
- N 0 6.3.1 talks about account removal
6.4.4 talks about test data removal
but no mention of scripts,
librairies,...
C7 Critical Control 7: Wireless Device Control
28.13% 4.5
C7.1 Organizations should ensure that each wireless device connected to
the network matches an authorized configuration and security
profile, with a documented owner of the connection and a defined
business need. Organizations should deny access to those wireless
devices that do not have such a configuration and profile.
2.1.1
4.1.1
11.1
P 0.5 No mention of documented
configuration
C7.2 Organizations should ensure that all wireless access points are
manageable using enterprise management tools. Access points
designed for home use often lack such enterprise management
capabilities, and should therefore be avoided in enterprise
environments.
- N 0
C7.3 Network vulnerability scanning tools should be configured to detect
wireless access points connected to the wired network. Identified
devices should be reconciled against a list of authorized wireless
access points. Unauthorized (i.e., rogue) access points should be
deactivated.
11.1 F 1
C7.4 Organizations should use wireless intrusion detection systems
(WIDS) to identify rogue wireless devices and detect attack attempts
and successful compromises. In addition to WIDS, all wireless traffic
should be monitored by a wired IDS as traffic passes into the wired
network.
- N 0
C7.5 802.1x should be used to control which devices are allowed to
connect to the wireless network.
- N 0
C7.6 A site survey should be performed to determine what areas within
the organization need coverage. After the wireless access points are
strategically placed, the signal strength should be tuned to minimize
leakage to areas that do not need coverage.
- N 0
C7.7 Where a specific business need for wireless access has been
identified, organizations should configure wireless access on client
machines to allow access only to authorized wireless networks.
- N 0
C7.8 For devices that do not have an essential wireless business purpose,
organizations should disable wireless access in the hardware
configuration (basic input/output system or extensible firmware
interface), with password protections to lower the possibility that
the user will override such configurations.
- N 0
C7.9 Organizations should regularly scan for unauthorized or
misconfigured wireless infrastructure devices, using techniques such
as war driving to identify access points and clients accepting peer-
to-peer connections. Such unauthorized or misconfigured devices
should be removed from the network, or have their configurations
altered so that they comply with the security requirements of the
organization.
11.1 F 1
C7.10 Organizations should ensure that all wireless traffic leverages at
least Advanced Encryption Standard (AES) encryption used with at
least WiFi Protected Access 2 protection.
4.1.1. F 1 PCI DSS doesn't specify an
encryption algorithm.
C7.11 Organizations should ensure that wireless networks use
authentication protocols such as Extensible Authentication Protocol-
Transport Layer Security (EAP/TLS) or Protected Extensible
Authentication Protocol (PEAP), which provide credential protection
and mutual authentication.
- N 0
C7.12 Organizations should ensure that wireless clients use strong, multi-
factor authentication credentials to mitigate the risk of
unauthorized access from compromised credentials.
- N 0
C7.13 Organizations should disable peer-to-peer wireless network
capabilities on wireless clients, unless such functionality meets a
documented business need.
- N 0
C7.14 Organizations should disable wireless peripheral access of devices
(such as Bluetooth), unless such access is required for a
documented business need.
- N 0
C7.15 Wireless access points should never be directly connected to the
private network. They should either be placed behind a firewall or
put on a separate VLAN so all traffic can be examined and filtered.
1.2.3 F 1
C7.16 Organizations should configure all wireless clients used to access
agency networks or handle organization data in a manner so that
they cannot be used to connect to public wireless networks or any
other networks beyond those specifically allowed by the agency.
- N 0
C8 Critical Control 8: Data Recovery Capability
40.00% 2
C8.1
Organizations should ensure that each system is automatically
backed up on at least a weekly basis, and more often for systems
storing sensitive information. To help ensure the ability to rapidly
restore a system from backup, the operating system,
application software, and data on a machine should each be
included in the overall backup procedure. These three components
of a system do not have to be included in the same backup file or
use the same backup software. However, each must be backed up
at least weekly.
- N 0 10.5.3 requires backup of audit trail
files
C8.2 Data on backup media should be tested on a regular basis by
performing a data restoration process to ensure that the backup is
properly working.
- N 0
C8.3
Key personal should be trained on both the backup and restoration
processes. To be ready in case a major incident occurs, alternative
personnel should also be trained on the restoration process just in
case the primary IT point of contact is not available.
- N 0
C8.4
Organizations should ensure that backups are properly protected via
physical security or encryption when they are stored locally, as well
as when they are moved across the network.
3.4
9.5
F 1
C8.5 Backup media, such as hard drives and tapes, should be stored in
physically secure, locked facilities.
9.5 F 1
C9 Critical Control 9: Security Skills Assessment and
Appropriate Training to Fill Gaps
33.33% 2
C9.1 Organizations should develop security awareness training for
various personnel job descriptions. The training should include
specific, incident-based scenarios showing the threats an
organization faces, and should present proven defenses against the
latest attack techniques.
12.6 F 1
C9.2
Awareness should be carefully validated with policies and training.
Policies tell users what to do, training provides them the skills to do
it, and awareness changes their behavior so that they understand
the importance of following the policy.
12.6 F 1
C9.3 Metrics should be created for all policies and measured on a regular
basis. Awareness should focus on the areas that are receiving the
lowest compliance score.
- N 0 could be included in 12.6
(awareness program).
C9.4
Organizations should devise periodic security awareness assessment
quizzes to be given to employees and contractors on at least an
annual basis in order to determine whether they understand the
information security policies and procedures, as well as their role in
those procedures.
- N 0 No determination/validation of
level of understanding
C9.5
Organizations should conduct periodic exercises to verify that
employees and contractors are fulfilling their information security
duties by conducting tests to see whether employees will click on a
link from suspicious e-mail or provide sensitive information on the
telephone without following appropriate procedures for
authenticating a caller.
- N 0
C9.6
Provide awareness sessions for users who are not following policies
after they have received appropriate training.
- N 0
C10 Critical Control 10: Secure Configurations for
Network Devices such as Firewalls, Routers, and
Switches
50.00% 4
C10.1 Compare firewall, router, and switch configuration against standard
secure configurations defined for each type of network device in use
in the organization. The security configuration of such devices
should be documented, reviewed, and approved by an organization
change control board. Any deviations from the standard
configuration or updates to the standard configuration should be
documented and approved in a change control system.
1.2.2
1.1.5
1.1.6
2.2
F 1
C10.2 At network interconnection pointssuch as Internet gateways,
inter- organization connections, and internal network segments with
different security controlsimplement ingress and egress filtering
to allow only those ports and protocols with an explicit and
documented business need. All other ports and protocols should be
blocked with default-deny rules by firewalls, network-based IPS,
and/or routers.
1.2
1.2.1
1.1.5
F 1
C10.3 Network devices that filter unneeded services or block attacks
(including firewalls, network-based IPS, routers with access control
lists, etc.) should be tested under laboratory conditions with each
given organizations configuration to ensure that these devices
exhibit failure behavior in a closed/blocking fashion under
significant loads with traffic including a mixture of legitimate,
allowed traffic for that configuration intermixed with attacks at line
speeds.
- N 0
C10.4 All new configuration rules beyond a baseline-hardened
configuration that allow traffic to flow through network security
devices, such as firewalls and network-based IPS, should be
documented and recorded in a configuration management system,
with a specific business reason for each change, a specific
individuals name responsible for that business need, and an
expected duration of the need. At least once per quarter, these
rules should be reviewed to determine whether they are still
required from a business perspective. Expired rules should be
removed.
1.1
1.1.1
1.1.2
1.1.4
1.1.5
1.1.6
F 1
C10.5 Network filtering technologies employed between networks with
different security levels (firewalls, network-based IPS tools, and
routers with access controls lists) should be deployed with
capabilities to filter Internet Protocol version 6 (IPv6) traffic.
However, if IPv6 is not currently being used it should be disabled.
Since many operating systems today ship with IPv6 support
activated, filtering technologies need to take it into account.
- N 0
C10.6 Network devices should be managed using two-factor
authentication and encrypted sessions. Only true two-factor
authentication mechanisms should be used, such as a password and
a hardware token, or a password and biometric device. Requiring
two different passwords for accessing a system is not two-factor
authentication.
2.3
8.3
F 1
C10.7 The latest stable version of a network devices inter-network
operating system (IOS) or firmware must be installed within 30 days
of the update being released from the device vendor.
- N 0
C10.8 The network infrastructure should be managed across network
connections that are separated from the business use of that
network, relying on separate VLANs or, preferably, on entirely
different physical connectivity for management sessions for
network devices.
- N 0
C11 Critical Control 11: Limitation and Control of
Network Ports, Protocols, and Services
41.67% 2.5
C11.1 Host-based firewalls or port filtering tools should be applied on end
systems, with a default-deny rule that drops all traffic except those
services and ports that are explicitly allowed.
- N 0
C11.2 Automated port scans should be performed on a regular basis
against all key servers and compared to a known effective baseline.
If a new port is found open, an alert should be generated and
reviewed.
11.2.1
11.2.2
11.2.3
P 0.5 Part of the discovery phasis of a
newtork scan. Although, specific
reports should be built to list these
discrepencies.
C11.3 Any server that is visible from the Internet or an untrusted network
should be verified, and if it is not required for business purposes it
should be moved to an internal VLAN and given a private address.
- N 0
C11.4 Services needed for business use across the internal network should
be reviewed quarterly via a change control group, and business
units should re- justify the business use. Sometimes services are
turned on for projects or limited engagements, and should be
turned off when they are no longer needed.
1.1.5 P 0.5 1.1.5 is the closest requirement
related to busines justification. No
mention of regular review.
C11.5 Operate critical services on separate physical host machines, such as
DNS, file, mail, web, and database servers.
2.2.1 F 1
C11.6 Application firewalls should be placed in front of any critical servers
to verify and validate the traffic going to the server. Any
unauthorized services or traffic should be blocked and an alert
generated.
6.6 P 0.5 PCI leaves the choice between a
WAF or code-review.
C12 Critical Control 12: Controlled Use of
Administrative Privileges
53.57% 7.5
C12.1 Organizations should inventory all administrative passwords - N 0
C12.1.1and validate that each person with administrative privileges on
desktops, laptops, and servers is authorized by a senior executive
7.1 P 0.5 General statement. Not talk
specifically of Admin privileges.
C12.1.2and that his/her administrative password has at least 12 semi-
random characters, consistent with the FDCC standard.
8.5.10 P 0.5 General requirement of at least 7
characters. No specific req for
admin
C12.2 Before deploying any new devices in a networked environment,
organizations should change all default passwords for applications,
operating systems, routers, firewalls, wireless access points, and
other systems to a difficult-to-guess value.
2.1 F 1
C12.3 Organizations should configure all administrative-level accounts to
require regular password changes on a frequent interval of no
longer than 60 days.
8.5.9 F 1 General requirement: 90 days. No
specific requirement for admin
accounts.
C12.4 Organizations should ensure all service accounts have long and
difficult-to- guess passwords that are changed on a periodic basis, as
is done for traditional user and administrator passwords, at a
frequent interval of no longer than 90 days.
- N 0 Service account passwords aren't
addressed.
C12.5 Passwords for all systems should be stored in a well-hashed or
encrypted format.
8.4 F 1
C12.5.1Furthermore, files containing these encrypted or hashed passwords
required for systems to authenticate users should be readable only
with superuser privileges.
- N 0
C12.6 Organizations should ensure that administrator accounts are used
only for system administration activities, and not for reading e-mail,
composing documents, or surfing the Internet.
- N 0
C12.6.1Web browsers and e-mail clients especially must be configured to
never run as administrator.
- N 0
C12.7 Through policy and user awareness, organizations should require
that administrators establish unique, different passwords for their
administrator and nonadministrative accounts. Each person
requiring administrative access should be given his/her own
separate account. Administrative accounts should never be shared.
Users should only use the Windows administrator or Unix root
accounts in emergency situations.
- N 0
C12.8 Organizations should configure operating systems so that passwords
cannot be re-used within a certain timeframe, such as six months.
8.5.12 P 0.5
C12.9 Organizations should implement focused auditing on the use of
administrative privileged functions and monitor for anomalous
behavior (e.g., system reconfigurations during the night shift).
10.2.2 F 1
C12.10 Organizations should configure systems to issue a log entry and alert
when an account is added to or removed from a domain
administrators group.
10.2.2 P 0.5 10.2.2 is the closest requirement
C12.11 All administrative access, including domain administrative access,
should use two-factor authentication.
- N 0 8.3 Two-factor only required for
remote access.
C12.12 Access to a machine (either remotely or locally) should be blocked
for administrator-level accounts. Instead, administrators should be
required to access a system using a fully logged and
nonadministrative account. Then, once logged in to the machine
without administrative privileges, the administrator should then
transition to administrative privileges using tools such as sudo on
Linux/UNIX, Runas on Windows, and other similar facilities for other
types of systems.
- N 0
C12.13 If services are outsourced to third parties, language should be
included in the contracts to ensure that they properly protect and
control administrative access. It should be validated that they are
not sharing passwords and have accountability to hold
administrators liable for their actions.
12.8.2 F 1
C12.14 Organizations should segregate administrator accounts based on
defined roles within the organization. For example, Workstation
admin accounts should only be allowed administrative access of
workstations, laptops, etc.
7.2
7.2.2
P 0.5
C13 Critical Control 13: Boundary Defense
50.00% 6.5
C13.1 Organizations should deny communications with (or limit data flow
to) known malicious IP addresses (black lists) or limit access to
trusted sites (white lists). Lists of bogon addresses (unroutable or
otherwise unused IP addresses) are publicly available on the
Internet from various sources, and indicate a series of IP addresses
that should not be used for legitimate traffic traversing the Internet.
- N 0
C13.1.1Tests can be periodically carried out by sending packets from bogon
source IP addresses into the network to verify that they are not
transmitted through network perimeters.
1.1.1 P 0.5
C13.2 Deploy network-based IDS sensors on Internet and extranet DMZ
systems and networks that look for unusual attack mechanisms and
detect compromise of these systems. These network-based IDS
sensors may detect attacks through the use of
signatures, network behavior analysis, or other mechanisms to
analyze traffic.
11.4 F 1
C13.3 Network-based IPS devices should be deployed to compliment IDS
by
blocking known bad signature or behavior of attacks. As attacks
become automated, methods such as IDS typically delay the amount
of time it takes for someone to react to an attack. A properly
configured network-based IPS can provide automation to block bad
traffic.
11.4 F 1
C13.4 On DMZ networks, monitoring systems (which may be built in to the
IDS sensors or deployed as a separate technology) should be
configured to record at least packet header information, and
preferably full packet header and payloads of the traffic destined for
or passing through the network border. This traffic should be sent to
a properly configured Security Event Information Management
(SEIM) system so that events can be correlated from all devices on
the network.
- N 0
C13.5 Define a network architecture that clearly separates internal
systems from DMZ and extranet systems. DMZ systems are
machines that need to communicate with the internal network as
well as the Internet, while extranet systems are those whose
primary communication is with other systems at a business partner.
DMZ systems should never contain sensitive data and internal
systems should never be directly accessible from the Internet.
1.1.3
1.3.7
F 1
C13.6 Design and implement network perimeters so that all outgoing web,
file transfer protocol (FTP), and secure shell traffic to the Internet
must pass through at least one proxy on a DMZ network. The proxy
should support logging individual TCP sessions; blocking specific
URLs, domain names, and IP addresses to implement a black list;
and applying white lists of allowed sites that can be accessed
through the proxy while blocking all other sites. Organizations
should force outbound traffic to the Internet through an
authenticated proxy server on the enterprise perimeter. Proxies can
also be used to encrypt all traffic leaving an organization.
- N 0
C13.7 Require all remote login access (including VPN, dial-up, and other
forms of access that allow login to internal systems) to use two-
factor authentication.
8.3 F 1
C13.8 All devices remotely logging into the internal network should be
managed by the enterprise, with remote control of their
configuration, installed software,
and patch levels.
- N 0
C13.9 Organizations should periodically scan for back-channel
connections to the Internet that bypass the DMZ, including
unauthorized VPN connections and dual-homed hosts connected to
the enterprise network and to other networks via wireless, dial-up
modems, or other mechanisms.
11.1
11.2
11.3
F 1 Discovery
C13.10 To limit access by an insider or malware spreading on an internal
network, organizations should devise internal network
segmentation schemes to limit traffic to only those services needed
for business use across the internal network.
1.3.7 P 0.5
C13.11 Organizations should develop plans to rapidly deploy filters on
internal networks to help stop the spread of malware or an intruder.
- N 0
C13.12 To minimize the impact of an attacker pivoting between
compromised systems, only allow DMZ systems to communicate
with private network systems via application proxies or application-
aware firewalls over approved channels
6.6 P 0.5
C13.13 To help identify covert channels exfiltrating data through a firewall,
built-in firewall session tracking mechanisms included in many
commercial firewalls should be configured to identify TCP sessions
that last an unusually long time for the given organization and
firewall device, alerting personnel about the source and destination
addresses associated with these long sessions.
- N 0
C14 Critical Control 14: Maintenance, Monitoring, and
Analysis of Audit Logs
68.75% 5.5
C14.1 Validate audit log settings for each hardware device and the
software installed on it, ensuring that logs include a date,
timestamp, source addresses, destination addresses, and various
other useful elements of each packet and/or transaction.
10.2
10.3
F 1
C14.1.1Systems should record logs in a standardized format such as syslog
entries or those outlined by the Common Event Expression initiative.
If systems cannot generate logs in a standardized format, log
normalization tools can be deployed to convert logs into a
standardized format.
- N 0
C.14.2 Ensure that all systems that store logs have adequate storage space
for the logs generated on a regular basis, so that log files will not fill
up between log rotation intervals.
- N 0
C14.2.1The logs must be archived and digitally signed on a periodic basis. 10.5
10.5.3
P 0.5 No requirement for digital signature
C14.2 All remote access to a network, whether to the DMZ or the internal
network (i.e., VPN, dial-up, or other mechanism), should be logged
verbosely.
- N 0 Not specific requirement for
remote access
C.14.3 Operating systems should be configured to log access control events
associated with a user attempting to access a resource (e.g., a file or
directory) without the appropriate permissions. Failed logon
attempts must also be logged.
10.2.1 -
10.2.7
10.3.4
F 1 Resource = CC data
C14.4 Security personnel and/or system administrators should run
biweekly reports that identify anomalies in logs. They should then
actively review the anomalies, documenting their findings.
10.6 F 1
C.14.5 Each organization should include at least two synchronized time
sources (i.e., Network Time Protocol NTP) from which all servers
and network equipment retrieve time information on a regular basis
so that timestamps in logs are consistent.
10.4
(10.4.3)
P 0.5 Don't mention about # of time
synchronization sources
C14.6 Network boundary devices, including firewalls, network-based IPS,
and inbound and outbound proxies, should be configured to
verbosely log all traffic (both allowed and blocked) arriving at the
device.
10.2
10.6
P 0.5 No specific mention of such devices
C14.7 For all servers, organizations should ensure that logs are written to
write-only devices or to dedicated logging servers running on
separate machines from hosts generating the event logs, lowering
the chance that an attacker can manipulate logs stored locally on
compromised machines.
10.5.4 F 1
C14.8 Organizations should deploy a SEIM system tool for log aggregation
and consolidation from multiple machines and for log correlation
and analysis. Standard government scripts for analysis of the logs
should be deployed and monitored, and customized local scripts
should also be used. Using the SEIM tool, system administrators and
security personnel should devise profiles of common events from
given systems so that they can tune detection to focus on unusual
activity, avoid false positives, more rapidly identify anomalies, and
prevent overwhelming analysts with insignificant alerts.
- N 0 No mention of SEIM
C15 Critical Control 15: Controlled Access Based on the
Need to Know
28.57% 2
C15.1 Organizations should establish a multi-level data
identification/classification scheme (e.g., a three- or four-tiered
scheme with data separated into categories based on the impact of
exposure of the data).
- N 0 Could be part of a risk assessment
methodology.
C15.2 Organizations should ensure that file shares have defined controls
(such as Windows share access control lists) that specify at least
that only authenticated users can access the share.
- N 0
C15.3 Organizations should enforce detailed audit logging for access to
nonpublic data and special authentication for sensitive data.
7.2 P 0.5 7.2 is the closest requiremement
C15.4 The network should be segmented based on the trust levels of the
information stored on the servers.
1.2
1.3
P 0.5
C15.4.1Whenever information flows over a network of lower trust level, the
information should be encrypted.
4.1 F 1
C15.5 The use of portable USB drives should either be limited or data
should automatically be encrypted before it is written to a portable
drive.
- N 0
C15.6 Host-based data loss prevention (DLP) should be used to enforce
ACLs even when data is copied off a server. In most organizations,
access to the data is controlled by ACLs that are implemented on
the server. Once the data have been copied to a desktop system the
ACLs are no longer enforced and the users can send the data to
whomever they want.
- N 0
C15.7 Deploy honeytokens on key servers to identify users who might be
trying to access information that they should not access.
- N 0
C16 Critical Control 16: Account Monitoring and Control
68.18% 7.5
C16.1 Review all system accounts and disable any account that cannot be
associated with a business process and owner.
- N 0
C16.2 Systems should automatically create a report on a daily basis that
includes a list of locked-out accounts, disabled accounts, accounts
with passwords that exceed the maximum password age, and
accounts with passwords that never expire. This list should be sent
to the associated system administrator in a secure fashion.
- N 0
C16.3 Organizations should establish and follow a process for revoking
system access by disabling accounts immediately upon termination
of an employee or contractor.
8.5.4 F 1
C16.4 Organizations should regularly monitor the use of all accounts,
automatically
logging off users after a standard period of inactivity.
8.5.6
8.5.15
F 1
C16.5 Organizations should monitor account usage to determine dormant
accounts
that have not been used for a given period, such as 30 days,
notifying the user or users manager of the dormancy. After a longer
period, such as 60 days, the account should be disabled.
8.5.5 F 1 PCI less restrictive (90 days)
C16.6 When a dormant account is disabled, any files associated with that
account should be encrypted and moved to a secure file server for
analysis by security or management personnel.
- N 0
C16.7 All nonadministrator accounts should be required to have a
minimum length of 12 characters,
8.5.10 P 0.5 PCI les restrictive (7 characters)
C16.7.1 contain letters, numbers, and special characters 8.5.11 P 0.5 PCI less restrictive (No special
characters)
C16.7.2be changed at least every 90 days, have a minimal age of one day, 8.5.9 F 1 PCI is also 90 days
C1.7.3 and not be allowed to use the previous 15 passwords as a new
password.
8.5.12 P 0.5 PCI less restrictive (the last 4)
C16.8 After eight failed logon attempts within a 45-minute period, the
account should be locked
8.5.13 F 1 PCI more restrictive (6 attempts)
C16.8.1for 120 minutes. 8.5.14 P 0.5 PCI less restrictive (30 minutes or
unlocked by administrator)
C16.9 On a periodic basis, such as quarterly or at least annually,
organizations should require that managers match active employees
and contractors with each account belonging to their managed staff.
Security or system administrators should then disable accounts that
are not assigned to active employees or contractors.
12.2 P 0.5 Partially covered through the
requirement for a User account
maintenance procedure.
C16.10 Organizations should monitor attempts to access deactivated
accounts through audit logging.
- N 0
C16.11 Organizations should profile each users typical account usage by
determining normal time-of-day access and access duration for each
user. Daily reports should be generated that indicate users who
have logged in during unusual hours or have exceeded their normal
login duration by 150 percent.
- N 0
C17 Critical Control 17: Data Loss Prevention
30.00% 3
C17.1 Organizations should deploy approved hard drive encryption
software to mobile machines that hold sensitive data.
- N 0
C17.2 Network monitoring tools should analyze outbound traffic looking
for a variety of anomalies, including large file transfers, long-time
persistent connections, connections at regular repeated intervals,
unusual protocols and ports in use, and possibly the presence of
certain keywords in the data traversing the network perimeter.
10.0 F 1
C17.3 Deploy an automated tool on network perimeters that monitors for
certain sensitive information (i.e., personally identifiable
information), keywords, and other document characteristics to
discover unauthorized attempts to exfiltrate data across network
boundaries and block such transfers while alerting information
security personnel.
- N 0
C17.4 Conduct periodic scans of server machines using automated tools to
determine whether sensitive data (i.e., personally identity, health,
credit card, and classified information) is present on the system in
clear text. These tools, which search for patterns that indicate the
presence of sensitive information, can help identify if a business or
technical process is leaving behind or otherwise leaking sensitive
information in data at rest.
- N 0
C17.5 Use outbound proxies to be able to monitor and control all
information leaving an organization.
- N 0
C17.6 Data should be moved between networks using secure,
authenticated, and encrypted mechanisms.
4.00 F 1 PCI requires encryption only
through public network
C17.7 Data stored on removable and easily transported storage media
such as USB tokens (i.e., thumb drives), USB portable hard drives,
and CDs/DVDs should be encrypted. Systems should be configured
so that all data written to such media are automatically encrypted
without user intervention.
3.4 F 1
C17.8 If there is no business need for supporting such devices,
organizations should configure systems so that they will not write
data to USB tokens or USB hard drives. If such devices are required,
enterprise software should be used that can configure systems to
allow only specific USB devices (based on serial number or other
unique property) to be accessed, and that can automatically encrypt
all data placed on such devices. An inventory of all authorized
devices must be maintained.
- N 0
C17.9 Use network-based DLP solutions to monitor and control the flow of
data within the network. Any anomalies that exceed the normal
traffic patterns should be noted and appropriate action taken to
address them,.
- N 0
C17.1
0
Monitor all traffic leaving the organization and detect any
unauthorized use of encryption. Attackers often use an encrypted
channel to bypass network security devices. Therefore it is essential
that organizations are able to detect rogue connections, terminate
the connection, and remediate the infected system.
- N 0
C18 Critical Control 18: Incident Response Capability
100.00% 6
C18.1
Organizations should ensure that they have written incident
response procedures that include a definition of personnel roles for
handling incidents. The procedures should define the phases of
incident handling consistent with the NIST guidelines.
12.5.3
12.9
F 1
C18.2
Organizations should assign job titles and duties for handling
computer and network incidents to specific individuals.
12.9.1 F 1
C18.3 Organizations should define management personnel who will
support the incident handling process by acting in key decision-
making roles.
12.9.1 F 1
C18.4
Organizations should devise organization-wide standards for the
time required for system administrators and other personnel to
report anomalous events to the incident handling team, the
mechanisms for such reporting, and the kind of information that
should be included in the incident notification. This reporting should
also include notifying the appropriate US Community Emergency
Response Team in accordance with all government requirements for
involving that organization in computer incidents.
12.9.1 F 1
C18.5 Organizations should publish information for all personnel, including
employees and contractors, regarding reporting computer
anomalies and incidents to the incident handling team. Such
information should be included in routine employee awareness
activities.
12.9.4 F 1
C18.6
Organizations should conduct periodic incident scenario sessions for
personnel associated with the incident handling team to ensure that
they understand current threats and risks, as well as their
responsibilities in supporting the incident handling team.
12.9.4 F 1
C19 Critical Control 19: Secure Network Engineering
50.00% 2.5
C19.1 The network should be designed using a minimum of a three-tier
architecture (DMZ, middleware, and private network). Any system
accessible from the Internet should be on the DMZ, but DMZ
systems never contain sensitive data. Any system with sensitive
data should reside on the private network and never be directly
accessible from the Internet. DMZ systems should communicate
with private network systems through an application proxy residing
on the middleware tier.
1.3
1.3.1
1.3.2
1.3.3
F 1
C19.2 To support rapid response and shunning of detected attacks, the
network architecture and the systems that make it up should be
engineered for rapid deployment of new access control lists, rules,
signatures, blocks, blackholes, and other defensive measures.
- N 0
C19.3 DNS should be deployed in a hierarchical, structured fashion, with
all internal network client machines configured to send requests to
intranet DNS servers, not to DNS servers located on the Internet.
These internal DNS servers should be configured to forward
requests they cannot resolve to DNS servers located on a protected
DMZ. These DMZ servers, in turn, should be the only DNS servers
allowed to send requests to the Internet.
- N 0
C19.4 Security should be built into all phases of the software development
lifecycle, ensuring that any security issues are addressed as early as
possible.
6.3 F 1
C19.5 Organizations should segment the enterprise network into multiple,
separate trust zones to provide more granular control of system
access and additional intranet boundary defenses.
1.3 P 0.5 Network segmentation is
addressed as a way to reduce the
scope of the assessment.
C20 Critical Control 20: Penetration Tests and Red
Team Exercises
35.71% 2.5
C20.1 Organizations should conduct regular external and internal
penetration tests to identify vulnerabilities and attack vectors that
can be used to exploit enterprise systems successfully. Penetration
testing should occur from outside the network perimeter (i.e., the
Internet or wireless frequencies around an organization) as well as
from within its boundaries (i.e., on the internal network) to simulate
both outsider and insider attacks.
11.3 F 1
C20.2 Organizations should perform periodic red team exercises to test
the readiness of organizations to identify and stop attacks or to
respond quickly and effectively.
- N 0
C20.3 Organizations should ensure that systemic problems discovered in
penetration tests and red team exercises are fully mitigated.
11.3b F 1 Noted exploitable vulnerabilities
must be corrected
C20.4
Organizations should measure how well the organization has
reduced the significant enablers for attackers by setting up
automated processes to find:
o Cleartext e-mails and documents with password in the filename
or body o Critical network diagrams stored online and in cleartext
o Critical configuration files stored online and in cleartext
o Vulnerability assessment, penetration test reports, and red team
finding
documents stored online and in cleartext
o Other sensitive information identified by management personnel
as critical to the
operation of the enterprise during the scoping of a penetration test
or red team
exercise.
- N 0
C20.5
Social engineering should be included within a penetration test.
The human element is often the weakest link in an organization and
one that attackers
often target.
Supplement P 0.5 Social engineering is mentionned
within the Supplemental document
about pen test
C20.6
Organizations should devise a scoring method for determining the
results of
red team exercises so that results can be compared over time.
- N 0
C20.7
Organizations should create a test bed that mimics a production
environment
for specific penetration tests and red team attacks against elements
that are not typically tested in production, such as attacks against
supervisory control and data acquisition and other control systems.
- N 0
Return to Table of content
Report here under all vulnerability scans executed.
Date Int/Ext Scanning solution Operator or ASV's IPs (FAIL/PASS) Report
location
Return to Table of content
Date Int/Ext Tests provider IPs # exploitable
vulnerabilities
Report location
Report here under all penetration tests executed.
Training and other knowledge
evidences required by PCI DSS V3.0. Use this sheet to list the training evidences
Return to table of content
Security Awareness sessions (all staff)
Training Provided Audience Date
Secure Coding training for developers and code reviewers 6.5
Training Provided Audience Date
Training for Point-on-Sale personel on tampering and substitution of devices.
Training Provided Audience Date 9.9.3
Training for staff with Security breach response responsibilities 10.4
Training Provided Audience Date
Training and other knowledge
evidences required by PCI DSS V3.0. Use this sheet to list the training evidences
PCI Req Yes/No Evidences
2.2.4b
2.2.5
3.6.8
3.7
4.3
5.4
6.7
7.3
8.8
Security policies and operational procedures for protecting systems against malware are
known to all affected parties.
Security policies and operational procedures for restricting access to cardholder data are
known to all affected parties.
Security policies and operational procedures for identification and authentication are known
to all affected parties.
Security policies and operational procedures for developing and maintaining secure systems
and applications are known to all affected parties.
Others
System administrators and security managers have knowledge of common security parameter
settings for system components they are responsible for
Personnel knows security policies and operational procedures for managing vendor defaults
and other security parameters
Cryptographic key custodians understand and accept their key-custodian responsibilities.
Security policies and operational procedures for protecting stored cardholder data are known
to all affected parties.
Security policies and operational procedures for encrypting transmissions of cardholder data
are known to all affected parties.
Training and other knowledge
evidences required by PCI DSS V3.0. Use this sheet to list the training evidences
9.10
10.8
11.6
Personnel understands the security policies, their roles and responsibilities 12.4
Security policies and operational procedures for restricting physical access to cardholder data
are known to all affected parties.
Security policies and operational procedures for monitoring all access to network resources
and cardholder data are known to all affected parties.
Security policies and operational procedures for security monitoring and testing are known to
all affected parties.
Return to Table of content Go to requirement 2
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
PCI DSS Requirement Guidance
1.1 Establish firewall and router configuration
standards that include the following:
Firewalls and routers are key components of the
architecture that controls entry to and exit from the
network. These devices are software or hardware devices
that block unwanted access and manage authorized
access into and out of the network. Without policies and
procedures in place to document how staff should
configure firewalls and routers, a business could easily
lose its first line of defense in data-protection. The
policies and procedures will help to ensure that the
organizations first line of defense in the protection of its
data remains strong.
Virtual environments where data flows do not transit a
physical network should be assessed to ensure
appropriate network segmentation is achieved.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Major Observations from the Verizon 2014 PCI Compliance Report:
12.5% of organizations that suffered a data breach in 2013 were compliant with Requirement 1 at the time of their breach.
46.7% compliance with Requirement 1 in 2013.
most organizations ranked high in addressing thebasic security practices like 1.1.3.a, 1.2.1.b, and 1.3.6.
Compliance with 1.1.5 and 1.1.6.b addressing the documentation and reviewing of firewalls and routers was considerably low. Just 52.5% of companies comply with 1.1.6.b.
1.1.1 A formal process for approving and testing all
network connections and changes to the firewall and
router configurations
A policy and process for approving and testing all
connections and changes to the firewalls and routers
will help prevent security problems caused by
misconfiguration of the network, router, or firewall.
Data flows between virtual machines should be
included in policy and process
Network diagrams describe how networks are
configured, and identify the location of all network
devices.
Without current network diagrams, devices could be
overlooked and be unknowingly left out of the
security controls implemented for PCI DSS and thus
be vulnerable to compromise.
1.1.2 Current network diagram that identifies all
connections between the cardholder data
environment and other networks, including any
wireless networks.
1.1.1 A formal process for approving and testing all
network connections and changes to the firewall and
router configurations
A policy and process for approving and testing all
connections and changes to the firewalls and routers
will help prevent security problems caused by
misconfiguration of the network, router, or firewall.
Data flows between virtual machines should be
included in policy and process
1.1.3 Current diagram that shows all cardholder
data flows across systems and networks
Cardholder data-flow diagrams identify the location
of all cardholder data that is stored, processed, or
transmitted within the network.
Network and cardholder data-flow diagrams help an
organization to understand and keep track of the
scope of their environment, by showing how
cardholder data flows across networks and between
individual systems and devices.
1.1.5 Description of groups, roles, and
responsibilities for logical management of network
components
This description of roles and assignment of responsibility
ensures that someone is clearly responsible for the
security of all components and is aware of their
responsibility, and that no devices are left unmanaged.
Using a firewall on every connection coming into (and out
of) the network allows the organization to monitor and
control access in and out, and to minimize the chances of
a malicious individuals obtaining access to the internal
network.
1.1.4 Requirements for a firewall at each Internet
connection and between any demilitarized zone
(DMZ) and the internal network zone
1.1.6 Documentation and business justification for
use of all services, protocols, and ports allowed,
including documentation of security features
implemented for those protocols considered to be
insecure. Examples of insecure services, protocols,
or ports include but are not limited to FTP, Telnet,
POP3, IMAP, and SNMP.
Compromises often happen due to unused or insecure
service and ports, since these often have known
vulnerabilitiesand many organizations are vulnerable to
these types of compromises because they do not patch
security vulnerabilities for services, protocols, and ports
they don't use (even though the vulnerabilities are still
present). Each organization should clearly decide which
services, protocols, and ports are necessary for their
business, document them for their records, and ensure
that all other services, protocols, and ports and disabled
or removed. Also, organizations should consider blocking
all traffic and only re-opening those ports once a need
has been determined and documented.
Additionally, there are many services, protocols, or ports
that a business may need (or have enabled by default)
that are commonly used by malicious individuals to
compromise a network. If these insecure services,
protocols, or ports are necessary for business, the risk
posed by use of these protocols should be clearly
understood and accepted by the organization, the use of
the protocol should be justified, and the security features
that allow these protocols to be used securely should be
documented and implemented. If these insecure services,
protocols, or ports are not necessary for business, they
should be disabled or removed.
This review gives the organization an opportunity at least
every six months to clean up any unneeded, outdated, or
incorrect rules, and ensure that all rule sets allow only
authorized services and ports that match business
justifications.
It is advisable to undertake these reviews on a more
frequent basis, such as monthly, to ensure that the rule
sets are current and match the needs of the business
without opening security holes and running unnecessary
risks.
1.1.7 Requirement to review firewall and router
rule sets at least every six months
1.2 Build firewall and router configurations that
restrict connections between untrusted networks
and any system components in the cardholder data
environment.
Note: An untrusted network is any network that
is external to the networks belonging to the entity
under review, and/or which is out of the entity's
ability to control or manage.
It is essential to install network protection, namely a
system component with (at a minimum) stateful
inspection firewall capability, between the internal,
trusted network and any other untrusted network that is
external and/or out of the entitys ability to control or
manage. Failure to implement this measure correctly
means that the entity will be vulnerable to unauthorized
access by malicious individuals or software.
If firewall functionality is installed but does not have rules
that control or limit certain traffic, malicious individuals
may still be able to exploit vulnerable protocols and ports
to attack your network.
1.2.1 Restrict inbound and outbound traffic to that
which is necessary for the cardholder data
environment.
1.2.2 Secure and synchronize router configuration
files.
This requirement is intended to prevent malicious
individuals from accessing the organization's network via
unauthorized IP addresses or from using services,
protocols, or ports in an unauthorized manner (for
example, to send data they've obtained from within your
network out to an untrusted server.
All firewalls should include a rule that denies all inbound
and outbound traffic not specifically needed. This will
prevent inadvertent holes that would allow other,
unintended and potentially harmful traffic in or out.
While running configuration files are usually
implemented with secure settings, the start-up files
(routers run these files only upon re-start) may not be
implemented with the same secure settings because they
only run occasionally. When a router does re-start
without the same secure settings as those in the running
configuration files, it may result in weaker rules that
allow malicious individuals into the network, because the
start-up files may not be implemented with the same
secure settings as the running configuration files.
1.3 Prohibit direct public access between the
Internet and any system component in the
cardholder data environment.
A firewall's intent is to manage and control all
connections between public systems and internal systems
(especially those that store, process or transmit
cardholder data). If direct access is allowed between
public systems and the CDE, the protections offered by
the firewall are bypassed, and system components
storing cardholder data may be exposed to compromise.
1.2.3 Install perimeter firewalls between any
wireless networks and the cardholder data
environment, and configure these firewalls to deny
or control (if such traffic is necessary for business
purposes) any traffic from the wireless environment
into the cardholder data environment.
The known (or unknown) implementation and
exploitation of wireless technology within a network is a
common path for malicious individuals to gain access to
the network and cardholder data. If a wireless device or
network is installed without a companys knowledge, a
malicious individual could easily and invisibly enter the
network. If firewalls do not restrict access from wireless
networks into the payment card environment, malicious
individuals that gain unauthorized access to the wireless
network can easily connect to the payment card
environment and compromise account information.
Firewalls must be installed between all wireless networks
and the CDE, regardless of the purpose of the
environment to which the wireless network is connected.
This may include, but is not limited to, corporate
networks, retail stores, warehouse environments, etc.
1.3.1 Implement a DMZ to limit inbound traffic to
only system components that provide authorized
publicly accessible services, protocols, and ports.
The DMZ is that part of the network that manages
connections between the Internet (or other untrusted
networks), and internal services that an organization
needs to have available to the public (like a web server).
It is the first line of defense in isolating and separating
traffic that needs to communicate with the internal
network from traffic that does not.
This functionality is intended to prevent malicious
individuals from accessing the organization's network via
unauthorized IP addresses or from using services,
protocols, or ports in an unauthorized manner.
1.3.2 Limit inbound Internet traffic to IP addresses
within the DMZ.
Termination of IP connections at the DMZ provides
opportunity for inspection and restriction of
source/destination, and/or inspection / blocking of
content, thus preventing unfiltered access between
untrusted and trusted environments.
1.3.3 Do not allow any direct connections inbound
or outbound for traffic between the Internet and
the cardholder data environment.
Termination of IP connections both inbound and
outbound provides opportunity for inspection and
restriction of source/destination, and/or inspection /
blocking of content, thus preventing unfiltered access
between untrusted and trusted environments. This helps
prevent, for example, malicious individuals from sending
data they've obtained from within your network out to an
external untrusted server in an untrusted network.
1.3.4 Implement anti-spoofing measures to detect
and block forged source IP addresses from
entering the network.
(For example, block traffic originating from the
Internet with an internal source address.)
Normally a packet contains the IP address of the
computer that originally sent it so other computers in
the network know where the packet came from.
Malicious individuals will often try to spoof (or imitate)
the sending IP address so that the target system
believes the packet is from a trusted source.
Filtering packets coming into the network helps to,
among other things, ensure packets are not
spoofed to look like they are coming from an
organizations own internal network.
1.3.5 Do not allow unauthorized outbound traffic
from the cardholder data environment to the
Internet.
All traffic outbound from inside the cardholder data
environment should be evaluated to ensure that
outbound traffic follows established, authorized rules.
Connections should be inspected to restrict traffic to
only authorized communications (for example by
restricting source/destination addresses/ports, and/or
blocking of content).
Where environments have no inbound connectivity
allowed, outbound connections may be achieved via
architectures or system components that interrupt and
inspect the IP connectivity.
1.3.6 Implement stateful inspection, also known as
dynamic packet filtering. (That is, only
established connections are allowed into the
network.)
A firewall that performs stateful packet inspection
keeps "state" (or the status) for each connection to the
firewall. By keeping "state," the firewall knows whether
what appears to be a response to a previous
connection is truly a response (since it "remembers"
the previous connection) or is a malicious individual or
software trying to spoof or trick the firewall into
allowing the connection.
1.3.7 Place system components that store
cardholder data (such as a database) in an internal
network zone, segregated from the DMZ and other
untrusted networks.
Cardholder data requires the highest level of
information protection. If cardholder data is located
within the DMZ, access to this information is easier for
an external attacker, since there are fewer layers to
penetrate.
Note: the intent of this requirement does not include
storage in volatile memory.
1.3.8 Do not disclose private IP addresses and
routing information to unauthorized parties.
Note: Methods to obscure IP addressing may
include, but are not limited to:
- Network Address Translation (NAT)
- Placing servers containing cardholder data
behind proxy servers/firewalls or content caches,
- Removal or filtering of route advertisements for
private networks that employ registered
addressing,
- Internal use of RFC1918 address space instead of
registered addresses.
Restricting the broadcast of IP addresses is essential to
prevent a hacker learning the IP addresses of the
internal network, and using that information to access
the network.
Effective means to meet the intent of this requirement
may vary depending on the specific networking
technology being used in your environment. For example,
the controls used to meet this requirement may be
different for IPv4 networks than for IPv6 networks.
One technique to prevent IP address information from
being discovered on an IPv4 network is to implement
Network Address translation (NAT). NAT, which is
typically managed by the firewall, allows an organization
to have internal addresses that are visible only inside the
network and external address that are visible externally.
If a firewall does not hide or mask the IP addresses of
the internal network, a malicious individual could
discover internal IP addresses and attempt to access the
network with a spoofed IP address.
For IPv4 networks, the RFC1918 address space is reserved
for internal addressing, and should not be routable on the
Internet. As such, it is preferred for IP addressing of
internal networks. However, organizations may have
reasons to utilize non-RFC1918 address space on the
internal network. In these circumstances, prevention of
route advertisement or other techniques should be used
to prevent internal address space being broadcast on the
Internet or disclosed to unauthorized parties.
1.5 Ensure that security policies and operational
procedures for managing firewalls are
documented, in use, and known to all affected
parties.
Personnel need to be aware of and following security
policies and operational procedures to ensure firewalls
and routers are continuously managed to prevent
unauthorized access to the network.
NT
NA
1.4 Install personal firewall software on any
mobile and/or employee-owned devices that
connect to the Internet when outside the
network (for example, laptops used by
employees), and which are also used to access
the network. Firewall configurations include: -
Specific configuration settings are defined for
personal firewall software.
-Personal firewall software is actively running.
-Personal firewall software is not alterable by
users of mobile and/or employee-owned devices.
If a computer does not have a firewall or anti-virus
program installed, spyware, Trojans, viruses, worms and
rootkits (malware) may be downloaded and/or installed
unknowingly. The computer is even more vulnerable
when directly connected to the Internet and not behind
the corporate firewall. Malware loaded on a computer
when not behind the corporate firewall can then
maliciously target information within the network when
the computer is re-connected to the corporate network.
Note: The intent of this requirement applies to remote
access computers regardless of whether they are
employee owned or company owned. Systems that
cannot be managed by corporate policy introduce
weaknesses to the perimeter and provide opportunities
that malicious individuals may exploit.
Executive summary
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
SANS
Top 20 Critical
Security Controls
Testing Procedure
C10.4 1.1 Inspect the firewall and router configuration standards and other documentation
specified below and verify that standards are complete and implemented as follows:
1.1.1.a Examine documented procedures to verify there is a formal process for
testing and approval of all:
Network connections, and
Changes to firewall and router configurations.
1.1.1.b For a sample of network connections, interview responsible personnel and
examine records to verify that network connections were approved and tested.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
C10.4
C13.1.1
Major Observations from the Verizon 2014 PCI Compliance Report:
12.5% of organizations that suffered a data breach in 2013 were compliant with Requirement 1 at the time of their breach.
46.7% compliance with Requirement 1 in 2013.
most organizations ranked high in addressing thebasic security practices like 1.1.3.a, 1.2.1.b, and 1.3.6.
Compliance with 1.1.5 and 1.1.6.b addressing the documentation and reviewing of firewalls and routers was considerably low. Just 52.5% of companies comply with 1.1.6.b.
1.1.1.c Identify a sample of actual changes made to firewall and router,
configurations, compare to the change records, and interview responsible personnel
to verify the changes were approved and tested.
1.1.2.a Examine diagram(s) and observe network configurations to verify that a
current network diagram exists and that it documents all connections to cardholder
data, including any wireless networks.
1.1.2.b Interview responsible personnel to verify that the diagram is kept current.
C10.4
C13.1.1
C10.4
1.1.3 Examine data-flow diagram and interview personnel to verify the diagram:
Shows all cardholder data flows across systems and networks.
Is kept current and updated as needed upon changes to the environment.
1.1.4.a Examine the firewall configuration standards and verify that they include
requirements for a firewall at each Internet connection and between any DMZ and
the internal network zone.
1.1.4.b Verify that the current network diagram is consistent with the firewall
configuration standards.
1.1.4.c Observe network configurations to verify that a firewall is in place at each
Internet connection and between any demilitarized zone (DMZ) and the internal
network zone, per the documented configuration standards and network diagrams.
C10.4 1.1.5 Verify that firewall and router configuration standards include a description of
groups, roles, and responsibilities for logical management of network components.
1.1.5.b Interview personnel responsible for management of network components to
confirm that roles and responsibilities are assigned as documented.
C13.5
1.1.6.a Verify that firewall and router configuration standards include a documented
list of services, protocols and ports necessary for businessfor example, hypertext
transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and
Virtual Private Network (VPN) protocols.
1.1.6.b Identify insecure services, protocols, and ports allowed; and verify they are
necessary and that security features are documented and implemented by examining
firewall and router configuration standards and settings for each service.
1.1.6.c Examine firewall and router configurations to verify that the documented
security features are implemented for each insecure service, protocol, and port.
1.1.7.a Verify that firewall and router configuration standards require review of
firewall and router rule sets at least every six months.
1.1.7.b Examine documentation relating to rule set reviews and interview responsible
personnel to verify that the rule sets are reviewed at least every six months.
C10.1
C10.4
C10.1
C10.2
C10.4
C11.4
C10.2
C15.4
Left Blank by PCIco
1.2.1.a Examine firewall and router configurations and perform the following to verify
that connections are restricted between untrusted networks and system components
in the cardholder data environment:
1.2.1.b Examine firewall and router configurations to verify that inbound and
outbound traffic is limited to that which is necessary for the cardholder data
environment.
1.2.1.c Examine firewall and router configurations to verify that all other inbound and
outbound traffic is specifically denied, for example by using an explicit deny all or
an implicit deny after allow statement.
1.2.2.a Examine router configuration files to verify they are secured from
unauthorized access.
1.2.2.b Examine router configurations to verify they are synchronizedfor example,
the running (or active) configuration matches the start-up configuration (used when
machines are booted).
C10.1
C10.2
1.2.3.a Examine firewall and router configurations to verify that there are perimeter
firewalls installed between all wireless networks and the cardholder data
environment.
1.2.3.b Verify that the firewalls deny or, if traffic is necessary for business purposes,
permit only authorized traffic between the wireless environment and the cardholder
data environment.
C19.1
C19.5
C15.4
C7.15
C19.1 1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented
to limit inbound traffic to only system components that provide authorized publicly
accessible services, protocols, and ports.
C19.1 1.3.2 Examine firewall and router configurations to verify that inbound Internet
traffic is limited to IP addresses within the DMZ.
C19.1 1.3.3 Examine firewall and router configurations to verify direct connections inbound
or outbound are not allowed for traffic between the Internet and the cardholder data
environment.
C13.5 1.3.4 Examine firewall and router configurations to verify that anti-spoofing
measures are implemented, for example internal addresses cannot pass from the
Internet into the DMZ.
C10.2 1.3.5 Examine firewall and router configurations to verify that outbound traffic from
the cardholder data environment to the Internet is explicitly authorized.
NC 1.3.6 Examine firewall and router configurations to verify that the firewall performs
stateful inspection (dynamic packet filtering). (Only established connections should
be allowed in, and only if they are associated with a previously established session.)
C13.5
C13.10
1.3.7 Examine firewall and router configurations to verify that system components
that store cardholder data are on an internal network zone, segregated from the DMZ
and other untrusted networks.
NC 1.3.8.a Examine firewall and router configurations to verify that methods are in place
to prevent the disclosure of private IP addresses and routing information from
internal networks to the Internet.
1.3.8.b Interview personnel and examine documentation to verify that any disclosure
of private IP addresses and routing information to external entities is authorized.
1.4.a Examine policies and configuration standards to verify:
Personal firewall software is required for all mobile and/or employee-owned devices
that connect to the Internet (for example, laptops used by employees) when outside
the network, and which are also used to access the network.
Specific configuration settings are defined for personal firewall software.
Personal firewall software is configured to actively run.
Personal firewall software is configured to not be alterable by users of mobile and/or
employee-owned devices.
1.4.b Inspect a sample of mobile and/or employee-owned devices to verify that:
Personal firewall software is installed and configured per the organizations specific
configuration settings.
Personal firewall software is actively running.
Personal firewall software is not alterable by users of mobile and/or employee-owned
devices.
1.5 Examine documentation and interview personnel to verify that security policies
and operational procedures for managing firewalls are:
Documented,
In use, and
Known to all affected parties
NT
NA
C5.1.1
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
Validation instruction for QSA/ISA
(For In-Place Requirements)
Priority A A-EP PE2P
Left Blank by PCIco
6
0 0 0
Identify the document(s) reviewed to verify procedures define the formal processes
for:

Testing and approval of all network connections.


<Report Findings Here>

Testing and approval of all changes to firewall and router configurations.


<Report Findings Here>
6
0 0 0
Identify the sample of records for network connections that were examined.
<Report Findings Here>
Identify the responsible personnel interviewed who confirm that network
connections were approved and tested.
<Report Findings Here>
6
0 0 0
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Major Observations from the Verizon 2014 PCI Compliance Report:
12.5% of organizations that suffered a data breach in 2013 were compliant with Requirement 1 at the time of their breach.
46.7% compliance with Requirement 1 in 2013.
most organizations ranked high in addressing thebasic security practices like 1.1.3.a, 1.2.1.b, and 1.3.6.
Compliance with 1.1.5 and 1.1.6.b addressing the documentation and reviewing of firewalls and routers was considerably low. Just 52.5% of companies comply with 1.1.6.b.
Selected Merchant Type:
Identify the responsible personnel interviewed who confirm that changes made to
firewall and router configurations were approved and tested.
<Report Findings Here>

Describe how change records were compared to actual changes made to firewall
and router configurations to verify the changes were:

Approved
<Report Findings Here>

Tested
<Report Findings Here>
6
0 0 0
Identify the current network diagram(s) examined.
<Report Findings Here>

Describe how network connections were observed and compared to the


diagram(s) to verify that the diagram:

Is current.
<Report Findings Here>

Includes all connections to cardholder data.


<Report Findings Here>

Includes any wireless network connections.


<Report Findings Here>
1
0 0 0
Identify the document examined to verify processes require that the network
diagram is kept current.
<Report Findings Here>

Identify the responsible personnel interviewed for this testing procedure.


<Report Findings Here>

For the interview, summarize the relevant details discussed to verify that the
diagram is kept current.
<Report Findings Here>
1
0 0 0
Identify the data-flow diagram(s) examined.
<Report Findings Here>
Identify the responsible personnel interviewed
for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed to verify the diagram:

Shows all cardholder data flows across systems and networks.


<Report Findings Here>

Is kept current and updated as needed upon changes to the environment.


<Report Findings Here>
1
0 0 0
Identify the firewall configuration standards document examined to verify
requirements for a firewall:
At each Internet connection.
Between any DMZ and the internal network zone.
<Report Findings Here>
2
0 1 0
Provide the name of the assessor who attests that the current network diagram
identified at 1.1.2.a was compared to the firewall configuration standards identified
at 1.1.4.a to verify they are consistent with each other.
<Report Findings Here>
2
0 1 0
Describe how network configurations were observed to verify that, per the
documented configuration standards and network diagrams, a firewall is in place:

At each Internet connection.


<Report Findings Here>

Between any DMZ and the internal network zone.


<Report Findings Here>
2
0 1 0
Identify the firewall and router configuration standards document(s) reviewed to
verify they include a description of groups, roles and responsibilities for management
of network components.
<Report Findings Here>
6
0 0 0
Identify the personnel responsible for management of network components
interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed to verify that roles and
responsibilities are assigned as documented for management of firewall and router
components.
<Report Findings Here>
0 0 0
Identify the firewall configuration standards document(s) reviewed to verify the
document(s) contains a list of all services, protocols and ports necessary for business,
including a business justification for each.
<Report Findings Here>
Identify the router configuration standards document(s) reviewed to verify the
document contains a list of all services, protocols and ports necessary for business,
including a business justification for each.
<Report Findings Here>
2
0 1 0
Identify whether any insecure services, protocols or ports are allowed. (yes/no)
<Report Findings Here>
If yes, complete the instructions below for EACH insecure service, protocol, and
port allowed: (add rows as needed)
Identify the documented justification.
<Report Findings Here>
Identify the firewall and router configuration standards reviewed to verify that
security features are documented for each insecure service/protocol/port.
<Report Findings Here>
2
0 1 0
If yes at 1.1.6.b, complete the following for each insecure service, protocol, and/or
port present (add rows as needed):

Describe how the firewall and router configurations were examined to verify that the
documented security features are implemented for each insecure service, protocol
and/or port.
<Report Findings Here>
2
0 1 0
Identify the firewall and router configuration standards reviewed to verify they
require a review of firewall rule sets at least every six months.
<Report Findings Here>
6
0 0 0
Identify the document(s) relating to rule set reviews that were examined to verify
that rule sets are reviewed at least every six months for firewall and router rule sets.
<Report Findings Here>

Identify the responsible personnel interviewed who confirm that rule sets are
completed at least every six months:

Identify the responsible personnel interviewed who confirm that rule sets are
reviewed at least every six months for firewall and router rule sets.
<Report Findings Here>
6
0 0 0
Left Blank by PCIco
2
0 1 0
Identify the firewall and router configuration standards reviewed to verify they identify
inbound and outbound traffic necessary for the cardholder data environment.
<Report Findings Here> 2
0 1 0
Describe how firewall and router configurations were examined to verify that the
following traffic is limited to that which is necessary for the cardholder data
environment:

Inbound traffic
<Report Findings Here>

Outbound traffic
<Report Findings Here>
2
0 1 0
Describe how firewall and router configurations were examined to verify the
following is specifically denied:

All other inbound traffic


<Report Findings Here>

All other outbound traffic


<Report Findings Here>
2
0 0 0
Describe how router configuration files were examined to verify they are secured
from unauthorized access.
<Report Findings Here>
2
0 0 0
Describe how router configuration files were examined to verify they are
synchronized.
<Report Findings Here>
2
0 0 0
Describe how firewall and router configurations were examined to verify perimeter
firewalls are in place between all wireless networks and the cardholder data
environment.
<Report Findings Here>
2
0 0 0
Identify whether traffic between the wireless environment and the cardholder data
environment is necessary for business purposes. (yes/no)
<Report Findings Here>

If no:

Describe how firewall and/or router configurations were observed to verify firewalls
deny all traffic from any wireless environment into the cardholder environment.
<Report Findings Here>

If yes:

Describe how firewall and/or router configurations were observed to verify


firewalls permit only authorized traffic from any wireless environment into the
cardholder environment.
<Report Findings Here>
2
0 0 0
2
0 0 0
Describe how the firewall and router configurations were examined to verify that the
DMZ is implemented to limit inbound traffic to only system components that provide
authorized publicly accessible services, protocols, and ports.
<Report Findings Here>
2
0 0 0
Describe how the firewall and router configurations were examined to verify that
configurations limit inbound Internet traffic to IP addresses within the DMZ.
<Report Findings Here>
2
0 0 0
Describe how the examined firewall and router configurations were observed to
prevent direct connections between the Internet and the cardholder data
environment:

Inbound
<Report Findings Here>

Outbound
<Report Findings Here>
2
0 0 0
Describe how observed firewall/router configurations prevent internal addresses
passing from the Internet into the DMZ.
<Report Findings Here>
Describe how observed traffic from the Internet into the DMZ confirms that internal
addresses cannot pass from the Internet into the DMZ.
<Report Findings Here>
2
0 1 0
Describe how firewall and router configurations were examined to verify that
outbound traffic from the cardholder data environment to the Internet is explicitly
authorized.
<Report Findings Here>
2
0 1 0
Describe how firewall and router configurations were examined to verify that the
firewall performs stateful inspection.
<Report Findings Here>

Describe how observed firewall configurations implement stateful inspection


<Report Findings Here>
2
0 1 0
Identify whether any system components store cardholder data. (yes/no)
<Report Findings Here>

If yes:

Describe how firewall and router configurations were examined to verify that
the system components that store cardholder data are located on an internal
network zone, and are segregated from the DMZ and other untrusted networks.
<Report Findings Here>
2
0 0 0
Describe the methods in place to prevent the disclosure of private IP addresses and
routing information from internal networks to the Internet.
<Report Findings Here>
Describe how firewall and router configurations were examined to verify that
methods are in place to prevent the disclosure of private IP addresses and routing
information from internal networks to the Internet.
<Report Findings Here>
2
0 1 0
Identify the document reviewed that specifies whether any disclosure of private IP
addresses and routing information to external parties is permitted.
<Report Findings Here>

For each permitted disclosure, identify the responsible personnel interviewed who
confirm that the disclosure is authorized.
<Report Findings Here>
2
0 1 0
Identify whether mobile and/or employee- owned computers with direct connectivity
to the Internet are used to access the organizations network. (yes/no)
<Report Findings Here>
If no, identify the document reviewed that explicitly prohibits mobile and/or
employee- owned computers with direct connectivity to the Internet from being used
to access the organizations network
<Report Findings Here>
If yes, identify the documented policies and configuration standards that define the
following:
Personal firewall software is required for all mobile and/or employee-owned devices
that connect to the Internet when outside the network, and which are also used to
access the network.
Specific configuration settings are defined for personal firewall software.
Personal firewall software is configured to actively run.
Personal firewall software is configured to not be alterable by users of mobile and/or
employee-owned devices.
<Report Findings Here>
2
0 0 0
Identify the sample of mobile and/or employee-owned devices selected for this testing
procedure.
<Report Findings Here>

Describe how the sample of mobile and/or employee-owned devices was inspected to
verify that personal firewall software is:
Installed and configured per the organizations specific configuration settings.
<Report Findings Here>

Actively running.
<Report Findings Here>
Not alterable by users of mobile and/or employee-owned devices.
<Report Findings Here>
2
0 0 0
Identify the document reviewed to verify that security policies and operational
procedures for managing firewalls are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for managing firewalls are:
<Report Findings Here>
6
0 0 0
103 0 14 0
NT
NA
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
B B-IP C-VT C D S In Place ? Severity in
case of non
compliance
Proofs /
Documentation links
0 0 0 0 1 1 N 1
0 0 0 0 1 1 C 0
0 0 0 0 1 1 N 1
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Selected Merchant Type: D
0 0 0 0 1 1 N 1
0 1 0 0 1 1 Y 0
0 1 0 0 1 1 Y 0
0 0 0 0 1 1 C 0
0 1 0 0 1 1 N 5
0 1 0 0 1 1 N 5
0 1 0 0 1 1 N 5
0 0 0 0 1 1 N 1
0 0 0 0 1 1 N 7
0 1 0 0 1 1 N 5
0 1 0 0 1 1 Y 0
0 1 0 0 1 1 Y 0
0 0 0 0 1 1 Y 0
0 0 0 0 1 1 Y 0
0 1 1 1 1 1 Y 0
0 1 1 1 1 1 Y 0
0 1 1 1 1 1 Y 0
0 1 1 1 1 1 Y 0
0 0 0 0 1 1 Y 0
0 0 0 0 1 1 Y 0
0 1 1 1 1 1 Y 0
0 1 1 1 1 1 Y 0
0 1 1 1 1 1 Y 0
0 0 0 0 1 1 Y 0
0 0 0 0 1 1 Y 0
0 1 1 1 1 1 Y 0
0 1 0 0 1 1 Y 0
0 1 1 1 1 1 Y 0
0 1 1 1 1 1 Y 0
0 0 0 0 1 1 Y 0
0 0 0 0 1 1 Y 0
0 0 0 0 1 1 Y 0
0 0 1 0 1 1 Y 0
0 0 1 0 1 1 Y 0
0 0 0 0 1 1
N
1
0 19 12 10 38 38 Y 32
N
C
NT
NA
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
Stage of implementation Remediation plan Estimated date for completion
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
Comments Owner
Name
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted 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 untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.Other system components may provide firewall func
Return to Table of content
Go to requirement 1
PCI DSS Requirement Guidance
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
2.1 Always change vendor-supplied defaults before
installing a system on the network, including but not
limited to passwords, simple network management
protocol (SNMP) community strings, and elimination
of unnecessary accounts.
Major observations from the 2014 Verizon PCI Compliance Report
Only 38.8% of organizations suffering a breach had Requirement 2 in place.
90.1% of assessed organizations managed to comply with 2.2.3.a, which involves verifying that system administrators and security managers have knowledge of common security parameter settings for system components.
50.5% were complying with subcontrol 2.2.2: Enable only necessary and secure services, protocols
Only 55.4% of companies were in compliance with 2.2.2.a. This subcontrol requires that organizations document all services and protocols enabled on their system components, justify why theyre active, and verify that controls are implemented.
51.5% of companies complied with 2.2.2b, indicating that organizations still find it challenging to provide valid business justifications for the use of insecure services, daemons, and protocols, and presenting the documentation for it.
Malicious individuals (external and internal to a
company) often use vendor default settings, account
names, and passwords to compromise systems.
These settings are well known in hacker
communities and leave your system highly
vulnerable to attack.
2.1.1 For wireless environments connected to the
cardholder data environment or transmitting
cardholder data, change wireless vendor defaults,
including but not limited to default wireless
encryption keys, passwords, and SNMP
community strings.
Many users install these devices without
management approval and do not change default
settings or configure security settings. If wireless
networks are not implemented with sufficient
security configurations (including changing default
settings), wireless sniffers can eavesdrop on the
traffic, easily capture data and passwords, and easily
enter and attack your network. In addition, the key
exchange protocol for the older version of 802.11x
encryption (WEP) has been broken and can render
the encryption useless. Verify that firmware for
devices are updated to support more secure
protocols (for example, WPA2).
2.1 Always change vendor-supplied defaults before
installing a system on the network, including but not
limited to passwords, simple network management
protocol (SNMP) community strings, and elimination
of unnecessary accounts.
Malicious individuals (external and internal to a
company) often use vendor default settings, account
names, and passwords to compromise systems.
These settings are well known in hacker
communities and leave your system highly
vulnerable to attack.
2.1.1 For wireless environments connected to the
cardholder data environment or transmitting
cardholder data, change wireless vendor defaults,
including but not limited to default wireless
encryption keys, passwords, and SNMP
community strings.
2.2 Develop configuration standards for all system
components. Assure that these standards address all
known security vulnerabilities and are consistent
with industry-accepted system hardening standards.
Sources of industry-accepted system hardening
standards may include, but are not limited to:
- Center for Internet Security (CIS)
- International Organization for Standardization
(ISO)
- SysAdmin Audit Network Security (SANS) Institute
- National Institute of Standards Technology (NIST)
Many users install these devices without
management approval and do not change default
settings or configure security settings. If wireless
networks are not implemented with sufficient
security configurations (including changing default
settings), wireless sniffers can eavesdrop on the
traffic, easily capture data and passwords, and easily
enter and attack your network. In addition, the key
exchange protocol for the older version of 802.11x
encryption (WEP) has been broken and can render
the encryption useless. Verify that firmware for
devices are updated to support more secure
protocols (for example, WPA2).
There are known weaknesses with many operating
systems, databases, and enterprise applications, and
there are also known ways to configure these
systems to fix security vulnerabilities. To help those
that are not security experts, security organizations
have established system-hardening
recommendations, which advise how to correct
these weaknesses. If systems are left with these
weaknessesfor example, weak file settings or
default services and protocols (for services or
protocols that are often not needed)an attacker
will be able to use multiple, known exploits to attack
vulnerable services and protocols, and thereby gain
access to your organization's network. Source
websites where you can learn more about industry
best practices that can help you implement
configuration standards include, but are not limited
to: www.nist.gov, www.sans.org,
www.cisecurity.org, www.iso.org.
System configuration standards must also be kept up
to date to ensure that newly identified weaknesses
are corrected prior to a system being installed on
the network.
2.2 Develop configuration standards for all system
components. Assure that these standards address all
known security vulnerabilities and are consistent
with industry-accepted system hardening standards.
Sources of industry-accepted system hardening
standards may include, but are not limited to:
- Center for Internet Security (CIS)
- International Organization for Standardization
(ISO)
- SysAdmin Audit Network Security (SANS) Institute
- National Institute of Standards Technology (NIST)
2.2.1 Implement only one primary function per
server to prevent functions that require different
security levels from co-existing on the same
server. (For example, web servers, database
servers, and DNS should be implemented on
separate servers.)
Note: Where virtualization technologies are in
use, implement only one primary function per
virtual system component.
There are known weaknesses with many operating
systems, databases, and enterprise applications, and
there are also known ways to configure these
systems to fix security vulnerabilities. To help those
that are not security experts, security organizations
have established system-hardening
recommendations, which advise how to correct
these weaknesses. If systems are left with these
weaknessesfor example, weak file settings or
default services and protocols (for services or
protocols that are often not needed)an attacker
will be able to use multiple, known exploits to attack
vulnerable services and protocols, and thereby gain
access to your organization's network. Source
websites where you can learn more about industry
best practices that can help you implement
configuration standards include, but are not limited
to: www.nist.gov, www.sans.org,
www.cisecurity.org, www.iso.org.
System configuration standards must also be kept up
to date to ensure that newly identified weaknesses
are corrected prior to a system being installed on
the network.
This is intended to ensure your organization's system
configuration standards and related processes
address server functions that need to have different
security levels, or that may introduce security
weaknesses to other functions on the same server.
For example:
1. A database, which needs to have strong security
measures in place, would be at risk sharing a server
with a web application, which needs to be open and
directly face the Internet.
2. Failure to apply a patch to a seemingly minor
function could result in a compromise that impacts
other, more important functions (such as a
database) on the same server.
This requirement is meant for all servers within the
cardholder data environment (usually Unix, Linux, or
Windows based). This requirement may not apply to
systems which have the ability to natively
implement security levels on a single server (e.g.
mainframe).
Where virtualization technologies are used, each
virtual component (e.g. virtual machine, virtual
switch, virtual security appliance, etc.) should be
considered a server boundary. Individual
hypervisors may support different functions, but a
single virtual machine should adhere to the one
primary function rule. Under this scenario,
compromise of the hypervisor could lead to the
compromise of all system functions. Consequently,
consideration should also be given to the risk level
when locating multiple functions or components on
a single physical system.
2.2.1 Implement only one primary function per
server to prevent functions that require different
security levels from co-existing on the same
server. (For example, web servers, database
servers, and DNS should be implemented on
separate servers.)
Note: Where virtualization technologies are in
use, implement only one primary function per
virtual system component.
2.2.2 Enable only necessary and secure services,
protocols, daemons, etc., as required for the
function of the system. Implement security
features for any required services, protocols or
daemons that are considered to be insecurefor
example, use secured technologies such as SSH, S-
FTP, SSL, or IPSec VPN to protect insecure services
such as NetBIOS, file-sharing, Telnet, FTP, etc.
As stated in Requirement 1.1.5, there are many
protocols that a business may need (or have enabled
by default) that are commonly used by malicious
individuals to compromise a network. To ensure that
only the necessary services and protocols are
enabled and that all insecure services and protocols
are adequately secured before new servers are
deployed, this requirement should be part of your
organization's configuration standards and related
processes.
This is intended to ensure your organization's system
configuration standards and related processes
address server functions that need to have different
security levels, or that may introduce security
weaknesses to other functions on the same server.
For example:
1. A database, which needs to have strong security
measures in place, would be at risk sharing a server
with a web application, which needs to be open and
directly face the Internet.
2. Failure to apply a patch to a seemingly minor
function could result in a compromise that impacts
other, more important functions (such as a
database) on the same server.
This requirement is meant for all servers within the
cardholder data environment (usually Unix, Linux, or
Windows based). This requirement may not apply to
systems which have the ability to natively
implement security levels on a single server (e.g.
mainframe).
Where virtualization technologies are used, each
virtual component (e.g. virtual machine, virtual
switch, virtual security appliance, etc.) should be
considered a server boundary. Individual
hypervisors may support different functions, but a
single virtual machine should adhere to the one
primary function rule. Under this scenario,
compromise of the hypervisor could lead to the
compromise of all system functions. Consequently,
consideration should also be given to the risk level
when locating multiple functions or components on
a single physical system.
2.2.3 Implement additional security features
for any required services, protocols, or
daemons that are considered to be
insecurefor example, use secured
technologies such as SSH, S-FTP, SSL, or IPSec
VPN to protect insecure services such as
NetBIOS, file-sharing, Telnet, FTP, etc.
Enabling security features before new servers are
deployed will prevent servers being installed into the
environment with insecure configurations.
Ensuring that all insecure services, protocols, and
daemons are adequately secured with appropriate
security features makes it more difficult for
malicious individuals to take advantage of
commonly used points of compromise within a
network.
2.2.5 Remove all unnecessary functionality, such
as scripts, drivers, features, subsystems, file
systems, and unnecessary web servers.
2.2.4 Configure system security parameters to
prevent misuse.
This is intended to ensure your organizations
system configuration standards and related
processes specifically address security settings and
parameters that have known security implications.
The server-hardening standards must include
processes to address unnecessary functionality with
specific security implications (like
removing/disabling FTP or the web server if the
server will not be performing those functions).
2.2.5 Remove all unnecessary functionality, such
as scripts, drivers, features, subsystems, file
systems, and unnecessary web servers.
The server-hardening standards must include
processes to address unnecessary functionality with
specific security implications (like
removing/disabling FTP or the web server if the
server will not be performing those functions).
2.3 Encrypt all non-console administrative access
using strong cryptography. Use technologies such as
SSH, VPN, or SSL/TLS for webbased management
and other nonconsole administrative access.
If remote administration is not done with secure
authentication and encrypted communications,
sensitive administrative or operational level
information (like administrators passwords) can be
revealed to an eavesdropper. A malicious individual
could use this information to access the network,
become administrator, and steal data.
2.5 Ensure that security policies and operational
procedures for managing vendor defaults and
other security parameters are documented, in
use, and known to all affected parties.
Personnel need to be aware of and following
security policies and daily operational procedures to
ensure vendor defaults and other security
parameters are continuously managed to prevent
insecure configurations.
Maintaining a current list of all system components
will enable an organization to accurately and
efficiently define the scope of their environment for
implementing PCI DSS controls. Without an
inventory, some system components could be
forgotten, and be inadvertently excluded from the
organizations configuration standards.
2.4 Maintain an inventory of system
components that are in scope for PCI DSS.
2.3 Encrypt all non-console administrative access
using strong cryptography. Use technologies such as
SSH, VPN, or SSL/TLS for webbased management
and other nonconsole administrative access.
If remote administration is not done with secure
authentication and encrypted communications,
sensitive administrative or operational level
information (like administrators passwords) can be
revealed to an eavesdropper. A malicious individual
could use this information to access the network,
become administrator, and steal data.
2.6 Shared hosting providers must protect each
entitys hosted environment and cardholder data.
These providers must meet specific requirements as
detailed in Appendix A: Additional PCI DSS
Requirements for Shared Hosting Providers.
This is intended for hosting providers that provide
shared hosting environments for multiple clients on
the same server. When all data is on the same server
and under control of a single environment, often the
settings on these shared servers are not manageable
by individual clients, allow clients to add insecure
functions and scripts that impact the security of all
other client environments; and thereby make it easy
for a malicious individual to compromise one client's
data and thereby gain access to all other clients'
data.
Go to requirement 3 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
2.1 Choose a sample of system components, and attempt to log on (with system
administrator help) to the devices using default vendor-supplied accounts and
passwords, to verify that default accounts and passwords have been changed. (Use
vendor manuals and sources on the Internet to find vendor-supplied
accounts/passwords.)
2.1.b For the sample of system components, verify that all unnecessary default
accounts (including accounts used by operating systems, security software,
applications, systems, POS terminals, SNMP, etc.) are removed or disabled.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
Major observations from the 2014 Verizon PCI Compliance Report
Only 38.8% of organizations suffering a breach had Requirement 2 in place.
90.1% of assessed organizations managed to comply with 2.2.3.a, which involves verifying that system administrators and security managers have knowledge of common security parameter settings for system components.
50.5% were complying with subcontrol 2.2.2: Enable only necessary and secure services, protocols
Only 55.4% of companies were in compliance with 2.2.2.a. This subcontrol requires that organizations document all services and protocols enabled on their system components, justify why theyre active, and verify that controls are implemented.
51.5% of companies complied with 2.2.2b, indicating that organizations still find it challenging to provide valid business justifications for the use of insecure services, daemons, and protocols, and presenting the documentation for it.
C3.3
C12.2
2.1.c Interview personnel and examine supporting documentation to verify that:
All vendor defaults (including default passwords on operating systems, software
providing security services, application and system accounts, POS terminals, Simple
Network Management Protocol (SNMP) community strings, etc.) are changed before a
system is installed on the network.
Unnecessary default accounts (including accounts used by operating systems, security
software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled
before a system is installed on the network.
C11.5
C7.1
2.1.1.a Interview responsible personnel and examine supporting documentation to
verify that:
Encryption keys were changed from default at installation
C3.3
C12.2
2.1.1.b Interview personnel and examine policies and procedures to verify:
Default SNMP community strings are required to be changed upon installation.
Default passwords/phrases on access points are required to be changed upon
installation.
2.1.1.c Examine vendor documentation and login to wireless devices, with system
admin help
2.1.1.d Examine vendor documentation and observe wireless configuration settings
to verify firmware on wireless devices is updated to support strong encryption for:
Authentication over wireless networks
Transmission over wireless networks
2.1.1.e Examine vendor documentation and observe wireless configuration settings
to verify other security-related wireless vendor defaults were changed, if
applicable..
C3.1
C3.2
C3.3
C10.1
2.2.a Examine the organizations system configuration standards for all types of system
components and verify the system configuration standards are consistent with industry-
accepted hardening standards.
2.2.b Verify that system configuration standards are updated as new vulnerability
issues are identified, as defined in Requirement 6.1.
2.2.c Examine policies and interview personnel to verify that system configuration
standards are applied when new systems are configured and verified as being in place
before a system is installed on the network.
2.2.d Verify that system configuration standards include the following procedures for
all types of system components:
Changing of all vendor- supplied defaults and elimination of unnecessary default
accounts
Implementing only one primary function per server to prevent functions that require
different security levels from co-existing on the same server
Enabling only necessary services, protocols, daemons, etc., as required for the
function of the system
Implementing additional security features for any required services, protocols or
daemons that are considered to be insecure
Configuring system security parameters to prevent misuse
Removing all unnecessary functionality, such as scripts, drivers, features, subsystems,
file systems, and unnecessary web servers
NC 2.2.1.a Select a sample of system components and inspect the system configurations
to verify that only one primary function is implemented per server.
2.2.1.b If virtualization technologies are used, verify that only one primary function is
implemented per virtual system component or device.
2.2.2.a Select a sample of system components and inspect enabled system services,
daemons, and protocols to verify that only necessary services or protocols are
enabled.
2.2.2.b Identify any enabled insecure services, daemons, or protocols and interview
personnel to verify they are justified per documented configuration standards..
C3.3
C10.1
2.2.3 Inspect configuration settings to verify that security features are documented
and implemented for all insecure services, daemons, or protocols.
2.2.4.a Interview system administrators and/or security managers to verify that they
have knowledge of common security parameter settings for system components.
2.2.4.b Examine the system configuration standards to verify that common security
parameter settings are included.
2.2.4.c Select a sample of system components and inspect the common security
parameters to verify that they are set appropriately and in accordance with the
configuration standards.
C3.3 2.2.5.a For a sample of system components, verify that all unnecessary functionality
(for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.
2.2.5.b. Examine the documentation and security parameters to verify enabled
functions are documented and support secure configuration.
C3.3
C10.6
2.2.5.c. Examine the documentation and security parameters to verify that only
documented functionality is present on the sampled system components.
C10.6 2.3 Select a sample of system components and verify that non- console administrative
access is encrypted by performing the following:
2.3.a Observe an administrator log on to each system to verify that a strong encryption
method is invoked before the administrators password is requested.
2.3.b Review services and parameter files on systems to determine that Telnet and
other insecure remote-login commands are not available for non-console access.
2.3.c Observe an administrator log on to each system to verify that administrator
access to any web-based management interfaces is encrypted with strong cryptography.
2.3.d Examine vendor documentation and interview personnel to verify that strong
cryptography for the technology in use is implemented according to industry best
practices and/or vendor recommendations.
2.4.a Examine system inventory to verify that a list of hardware and software
components is maintained and includes a description of function/use for each.
2.4.b Interview personnel to verify the documented inventory is kept current.
2.5 Examine documentation and interview personnel to verify that security policies and
operational procedures for managing vendor defaults and other security parameters
are:
Documented,
In use, and
Known to all affected parties.
NC 2.6 Perform testing procedures A.1.1 through A.1.4 detailed in Appendix A: Additional
PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared
hosting providers, to verify that shared hosting providers protect their entities
(merchants and service providers) hosted environment and data.
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A A-EP
Identify the sample of system components selected.
<Report Findings Here>
Identify the vendor manuals and sources on the Internet used to find vendor-supplied
accounts/passwords.
<Report Findings Here>
For each item in the sample, describe how attempts to log on (with system
administrator help) to the sample of devices and applications using default vendor-
supplied accounts and passwords were performed to verify that all default passwords
have been changed.
<Report Findings Here>
2
0 1
For each item in the sample of system components indicated at 2.1.a, describe how all
unnecessary default accounts were verified to be either:

Removed
<Report Findings Here>
Disabled
<Report Findings Here>
2
0 1
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
Major observations from the 2014 Verizon PCI Compliance Report
Only 38.8% of organizations suffering a breach had Requirement 2 in place.
90.1% of assessed organizations managed to comply with 2.2.3.a, which involves verifying that system administrators and security managers have knowledge of common security parameter settings for system components.
50.5% were complying with subcontrol 2.2.2: Enable only necessary and secure services, protocols
Only 55.4% of companies were in compliance with 2.2.2.a. This subcontrol requires that organizations document all services and protocols enabled on their system components, justify why theyre active, and verify that controls are implemented.
51.5% of companies complied with 2.2.2b, indicating that organizations still find it challenging to provide valid business justifications for the use of insecure services, daemons, and protocols, and presenting the documentation for it.
Selected Merchant Type:
Identify responsible personnel interviewed who verify that:
All vendor defaults (including default passwords on operating systems, software
providing security services, application and system accounts, POS terminals, Simple
Network Management Protocol (SNMP) community strings, etc.) are changed before a
system is installed on the network.
Unnecessary default accounts (including accounts used by operating systems, security
software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled
before a system is installed on the network.
<Report Findings Here>
Identify supporting documentation examined for this testing procedure.
<Report Findings Here>
Describe how the supporting documentation was examined to verify that:

All vendor defaults are changed before a system is installed on the network.
<Report Findings Here>
Unnecessary default accounts are removed or disabled before a system is installed on
the network.
<Report Findings Here>
2
0 0
Identify whether there are wireless environments connected to the cardholder data
environment or transmitting cardholder data. (yes/no)
If no, mark 2.1.1 as Not Applicable and proceed
to 2.2.
<Report Findings Here>
If yes:
Identify responsible personnel interviewed who verify that encryption keys are
changed:
From default at installation
Anytime anyone with knowledge of the keys leaves the company or changes
positions.
<Report Findings Here>

Identify supporting documentation examined for this testing procedure.


<Report Findings Here>
Describe how the supporting documentation was examined to verify that encryption
keys are changed:
From default at installation
<Report Findings Here>
Anytime anyone with knowledge of the keys leaves the company or changes
positions.

<Report Findings Here>


2
0 0
Identify responsible personnel interviewed who verify that:
Default SNMP community strings are required to be changed upon installation.
Default passwords/phrases on access points are required to be changed upon
installation.
<Report Findings Here>
Identify policies and procedures examined to verify that:
Default SNMP community strings are required to be changed upon installation.
Default passwords/phrases on access points are required to be changed upon
installation.
<Report Findings Here>
2
0 0
Identify vendor documentation examined for this testing procedure.
<Report Findings Here>
Describe how examined vendor documentation was used to attempt to login to
wireless devices (with system administrator help) to verify:

Default SNMP community strings are not used.


<Report Findings Here>
Default passwords/passphrases on access points are not used.
<Report Findings Here>
2
0 0
Identify vendor documentation examined for this testing procedure.
<Report Findings Here>
Describe how wireless configuration settings were observed with examined vendor
documentation to verify that firmware on wireless devices is updated to support
strong encryption for:

Authentication over wireless networks.


<Report Findings Here>
Transmission over wireless networks.
<Report Findings Here>
2
0 0
Identify vendor documentation examined for this testing procedure.
<Report Findings Here>
Describe how wireless configuration settings were observed with examined vendor
documentation to verify other security-related wireless vendor defaults were
changed, if applicable.
<Report Findings Here>
2
0 0
Identify the documented system configuration standards for all types of system
components examined.
<Report Findings Here>
Identify the industry-accepted hardening standards the system configuration standards
were verified to be consistent with.
<Report Findings Here>
3
0 1
Identify the policy documentation verified to define that system configuration
standards are updated as new vulnerability issues are identified
<Report Findings Here>
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify that the process
is implemented.
<Report Findings Here>
3
0 1
Identify the policy documentation examined to verify it defines that system
configuration standards are applied when new systems are configured and verified as
being in place before a system is installed on the network
<Report Findings Here>
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify:
System configuration standards are applied when new systems are configured
<Report Findings Here>
System configuration standards are verified as being in place before a system is
installed on the network.
<Report Findings Here>
3
0 1
Identify the system configuration standards for all types of system components that
include the following procedures:
Changing of all vendor-supplied defaults and elimination of unnecessary default
accounts
Implementing only one primary function per server to prevent functions that require
different security levels from co-existing on the same server
Enabling only necessary services, protocols, daemons, etc., as required for the function
of the system
Implementing additional security features for any required services, protocols or
daemons that are considered to be insecure
Configuring system security parameters to prevent misuse
Removing all unnecessary functionality, such as scripts, drivers, features, subsystems,
file systems, and unnecessary web servers
<Report Findings Here>
3
0 1
Identify the sample of system components observed.
<Report Findings Here>
For each item in the sample, describe how system configurations were inspected to
verify that only one primary function per server is implemented.
<Report Findings Here>
3
0 1
Identify whether virtualization technologies are used. (yes/no)
<Report Findings Here>
IIf no, describe how systems were observed to verify that no virtualization
technologies are used.
<Report Findings Here>
If yes:

Identify the functions for which virtualization technologies are used.


<Report Findings Here>
Identify the sample of virtual system components or devices observed.
<Report Findings Here>
For each virtual system component and device in the sample, describe how the
system configurations were inspected to verify that only one primary function is
implemented per virtual system component or device.
<Report Findings Here>
3
0 1
Identify the sample of system components selected.
<Report Findings Here>
For each item in the sample, describe how the enabled system services, daemons,
and protocols were inspected to verify that only necessary services or protocols are
enabled.
<Report Findings Here>
3
0 1
For each item in the sample of system components from 2.2.2.a, identify if any
insecure services, daemons, or protocols are enabled. (yes/no)
If no, mark the remainder of 2.2.2.b and 2.2.3 as Not Applicable.
<Report Findings Here>
IIf yes, identify responsible personnel interviewed who confirm that a documented
business justification was present for each insecure service, daemon, or protocol
<Report Findings Here>
3
0 1
If yes at 2.2.b, perform the following:

Identify configuration settings inspected.


<Report Findings Here>
Describe how configuration settings were inspected to verify that security features
for all insecure services, daemons, or protocols are:

Documented
<Report Findings Here>
Implemented
<Report Findings Here>
3
0 1
Identify the system administrators and/or security managers interviewed for this
testing procedure.
<Report Findings Here>

For the interview, summarize the relevant details discussed to verify that they
have knowledge of common security parameter settings for system components.
<Report Findings Here>
3
0 1
Identify the system configuration standards examined to verify that common security
parameter settings are included.
<Report Findings Here>
3
0 1
Identify the sample of system components selected.
<Report Findings Here>
For each item in the sample, describe how the common security parameters
were inspected to verify that they are set appropriately and in accordance with the
configuration standards.
<Report Findings Here>
3
0 1
Identify the sample of system components selected.
<Report Findings Here>

For each item in the sample, describe how the configurations were inspected to
verify that all unnecessary functionality is removed.
<Report Findings Here>
3
0 1
Describe how the security parameters were examined with relevant documentation
to verify that enabled functions are:

Documented
<Report Findings Here>

Support secure configuration


<Report Findings Here>
3
0 1
Identify documentation examined for this testing procedure.
<Report Findings Here>
Describe how the security parameters were examined with relevant documentation
to verify that only documented functionality is present on the sampled system
components from 2.2.5.a.
<Report Findings Here>
3
0 1
Identify the sample of system components selected for 2.3.a-2.3.d to verify that non-
console administrative access is encrypted
<Report Findings Here>
2
0 1
For each item in the sample from 2.3:

Describe how the administrator log on for each system was observed to verify that a
strong encryption method is invoked before the administrators password is requested.
<Report Findings Here>
Describe how system configurations for each system were examined to verify that a
strong encryption method is invoked before the administrators password is requested.
<Report Findings Here>
Identify the strong encryption method used for non-console administrative access.
<Report Findings Here>
2
0 1
For each item in the sample from 2.3:
Describe how services on systems were reviewed to determine that Telnet and other
insecure remote-login commands are not available for non-console access.
<Report Findings Here>
Describe how parameter files on systems were reviewed to determine that Telnet and
other insecure remote-login commands are not available for non-console access.
<Report Findings Here>
2
0 1
For each item in the sample from 2.3:
Describe how the administrator log on to each system was observed to verify that
administrator access to any web-based management interfaces was encrypted with
strong cryptography.
<Report Findings Here>

Identify the strong encryption method used for any web-based management interfaces.
<Report Findings Here>
2
0 1
Identify the vendor documentation examined to verify that strong cryptography for the
technology in use is implemented according to industry best practices and/or vendor
recommendations.
<Report Findings Here>
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify that strong
cryptography for the technology in use is implemented according to industry best
practices and/or vendor recommendations.
<Report Findings Here>
2
0 1
Describe how the system inventory was examined to verify that a list of hardware and
software components is:

Maintained
<Report Findings Here>
Includes a description of function/use for each
<Report Findings Here>
2
0 0
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify that the
documented inventory is kept current.
<Report Findings Here>
2
0 0
Identify the document reviewed to verify that security policies and operational
procedures for managing vendor defaults and other security parameters are
documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for managing vendor defaults and other
security parameters are:
In use
Known to all affected parties
<Report Findings Here>
6
0 0
Identify whether the assessed entity is a shared hosting provider. (yes/no)
<Report Findings Here>
If yes, provide the name of the assessor who attests that Appendix A: Additional PCI
DSS Requirements for Shared Hosting Providers has been completed.
<Report Findings Here>
3
0 0
84 0 22
PE2P B B-IP C-VT C D S In place? Severity Proofs / Documentation links
0 0 1 1 1 1 1 Y 0
0 0 1 1 1 1 1 N 5
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
Selected Merchant Type: D
0 0 1 0 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 0 0 1 1 1 Y 0
0 0 0 0 1 1 1 N 4
0 0 0 0 1 1 1 N 4
0 0 0 0 1 1 1 N 4
0 0 0 0 1 1 1 N 4
0 0 0 0 1 1 1 Y 0
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 0 1 1 1 1 N 4
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 N 5
0 0 0 0 0 1 1 NT 5
0 0 0 0 0 1 1 NT 5
0 0 0 0 1 1 1 NT 1
0 0 0 0 0 0 1 N 0
0 0 13 21 29 31 32 Y 123
N
C
NT
NA
Stage of implementation Remediation plan
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
Estimated date for completion Comments Owner
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
Return to Table of content Go to requirement 2
PCI DSS Requirement Guidance
3.1 Keep cardholder data storage to a minimum by
implementing data retention and disposal policies,
procedures and processes, as follows.
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed,
and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms.
3.1.1 Implement a data retention and disposal
policy that includes:
- Limiting data storage amount and retention
time to that which is required for legal,
regulatory, and business requirements
- Processes for secure deletion of data when no
longer needed
- Specific retention requirements for cardholder
data
- A quarterly automatic or manual process for
identifying and securely deleting stored
cardholder data that exceeds defined retention
requirements
A formal data retention policy identifies what data
needs to be retained, and where that data resides so
it can be securely destroyed or deleted as soon as it
is no longer needed. In order to define appropriate
retention requirements, an entity first needs to
understand their own business needs as well as any
legal or regulatory obligations that apply to their
industry, and/or that apply to the type of data being
retained.
Extended storage of cardholder data that exceeds
business need creates an unnecessary risk. The only
cardholder data that may be stored after
authorization is the primary account number or PAN
(rendered unreadable), expiration date, cardholder
name, and service code.
Implementing secure deletion methods ensure that
the data cannot be retrieved when it is no longer
needed
Major observations from the 2014 Verizon PCI Compliance report
According to the 2013 DBIR, of all the breaches studied by the Verizon Investigative Response team, not a single one involved cardholder data in transit between systems. However, two-thirds of data breaches involved data at rest.
18.2% of organizations suffering a breach had Requirement 3 in place in 2013.
32.7% of companies complied with Requirement 3 in 2013
Many organizations failed to comply with 3.4, which demands that they confirm that the PAN is rendered unreadable via hashes, truncation, strong encryption or tokenization. Just 47.5% of companies were compliant with all four validation testing requirements:
3.1.1 Implement a data retention and disposal
policy that includes:
- Limiting data storage amount and retention
time to that which is required for legal,
regulatory, and business requirements
- Processes for secure deletion of data when no
longer needed
- Specific retention requirements for cardholder
data
- A quarterly automatic or manual process for
identifying and securely deleting stored
cardholder data that exceeds defined retention
requirements
A formal data retention policy identifies what data
needs to be retained, and where that data resides so
it can be securely destroyed or deleted as soon as it
is no longer needed. In order to define appropriate
retention requirements, an entity first needs to
understand their own business needs as well as any
legal or regulatory obligations that apply to their
industry, and/or that apply to the type of data being
retained.
Extended storage of cardholder data that exceeds
business need creates an unnecessary risk. The only
cardholder data that may be stored after
authorization is the primary account number or PAN
(rendered unreadable), expiration date, cardholder
name, and service code.
Implementing secure deletion methods ensure that
the data cannot be retrieved when it is no longer
needed
3.2 Do not store sensitive authentication data after
authorization (even if encrypted).
Sensitive authentication data includes the data as
cited in the following Requirements 3.2.1 through
3.2.3:
Note: It is permissible for issuers and companies
that support issuing services to store sensitive
authentication data if there is a business
justification and the data is stored securely.
Sensitive authentication data consists of magnetic
stripe (or track) data6, card validation code or
value7, and PIN data8. Storage of sensitive
authentication data after authorization is
prohibited! This data is very valuable to malicious
individuals as it allows them to generate counterfeit
payment cards and create fraudulent transactions.
See PCI DSS and PA-DSS Glossary of Terms,
Abbreviations, and Acronyms for the full definition
of sensitive authentication data.
Note: It is allowable for companies that perform,
facilitate, or support issuing services to store
sensitive authentication data ONLY IF they have a
legitimate business need to store such data. It
should be noted that all PCI DSS requirements apply
to issuers, and the only exception for issuers and
issuer processors is that sensitive authentication
data may be retained if there is a legitimate reason
to do so. A legitimate reason is one that is necessary
for the performance of the function being provided
for the issuer and not one of convenience.
Any such data must be stored securely and in
accordance with PCI DSS and specific payment brand
requirements.
3.2.1 Do not store the full contents of any track
(from the magnetic stripe located on the back of a
card, equivalent data contained on a chip, or
elsewhere). This data is alternatively called full
track, track, track 1, track 2, and magnetic-stripe
data.
Note: In the normal course of business, the
following data elements from the magnetic stripe
may need to be retained:
- The cardholders name
- Primary account number (PAN)
- Expiration date
- Service code
To minimize risk, store only these data elements
as needed for business.
If full track data is stored, malicious individuals who
obtain that data can reproduce and sell payment
cards.
3.2 Do not store sensitive authentication data after
authorization (even if encrypted).
Sensitive authentication data includes the data as
cited in the following Requirements 3.2.1 through
3.2.3:
Note: It is permissible for issuers and companies
that support issuing services to store sensitive
authentication data if there is a business
justification and the data is stored securely.
Sensitive authentication data consists of magnetic
stripe (or track) data6, card validation code or
value7, and PIN data8. Storage of sensitive
authentication data after authorization is
prohibited! This data is very valuable to malicious
individuals as it allows them to generate counterfeit
payment cards and create fraudulent transactions.
See PCI DSS and PA-DSS Glossary of Terms,
Abbreviations, and Acronyms for the full definition
of sensitive authentication data.
Note: It is allowable for companies that perform,
facilitate, or support issuing services to store
sensitive authentication data ONLY IF they have a
legitimate business need to store such data. It
should be noted that all PCI DSS requirements apply
to issuers, and the only exception for issuers and
issuer processors is that sensitive authentication
data may be retained if there is a legitimate reason
to do so. A legitimate reason is one that is necessary
for the performance of the function being provided
for the issuer and not one of convenience.
Any such data must be stored securely and in
accordance with PCI DSS and specific payment brand
requirements.
3.2.2 Do not store the card verification code or
value (three-digit or four-digit number printed on
the front or back of a payment card) used to verify
card-notpresent transactions.
The purpose of the card validation code is to protect
"card-not-present" transactionsInternet or mail
order/telephone order (MO/TO)
transactionswhere the consumer and the card are
not present. These types of transactions can be
authenticated as coming from the card owner only
by requesting this card validation code, since the
card owner has the card in-hand and can read the
value. If this prohibited data is stored and
subsequently stolen, malicious individuals can
execute fraudulent Internet and MO/TO transactions.
3.2.3 Do not store the personal identification
number (PIN) or the encrypted PIN block.
These values should be known only to the card
owner or bank that issued the card. If this prohibited
data is stored and subsequently stolen, malicious
individuals can execute fraudulent PIN-based debit
transactions (for example, ATM withdrawals).
3.3 Mask PAN when displayed (the first six and last
four digits are the maximum number of digits to be
displayed).
Notes:
- This requirement does not apply to employees and
other parties with a legitimate business need to see
the full PAN.
- This requirement does not supersede stricter
requirements in place for displays of cardholder
datafor example, for point-of-sale (POS) receipts.
T
he display of full PAN on items such as computer
screens, payment card receipts, faxes, or paper
reports can result in this data being obtained by
unauthorized individuals and used fraudulently. The
PAN can be displayed in full form on the merchant
copy receipts; however the paper receipts should
adhere to the same security requirements as
electronic copies and follow the guidelines of the PCI
Data Security Standard, especially Requirement 9
regarding physical security. The full PAN can also be
displayed for those with a legitimate business need
to see the full PAN.
This requirement relates to protection of PAN
displayed on screens, paper receipts, etc., and is not
to be confused with Requirement 3.4 for protection
of PAN when stored in files, databases, etc.
Lack of protection of PANs can allow malicious
individuals to view or download this data. PANs
stored in primary storage (databases, or flat files
such as text files spreadsheets) as well as non-
primary storage (backup, audit logs, exception or
troubleshooting logs) must all be protected. Damage
from theft or loss of backup tapes during transport
can be reduced by ensuring PANs are rendered
unreadable via encryption, truncation, or hashing.
Since audit, troubleshooting, and exception logs
have to be retained, you can prevent disclosure of
data in logs by rendering PANs unreadable (or
removing them) in logs.
By correlating hashed and truncated versions of a
given PAN, a malicious individual may easily derive
the original PAN value. Controls that prevent the
correlation of this data will help ensure that the
original PAN remains unreadable.
Please refer to the PCI DSS and PA-DSS Glossary of
Terms, Abbreviations, and Acronyms for definitions
of strong cryptography.
3.4 Render PAN unreadable anywhere it is stored
(including on portable digital media, backup media,
and in logs) by using any of the following approaches:
- One-way hashes based on strong cryptography
(hash must be of the entire PAN)
- Truncation (hashing cannot be used to replace the
truncated segment of PAN)
- Index tokens and pads (pads must be securely
stored)
- Strong cryptography with associated key-
management processes and procedures
Note: It is a relatively trivial effort for a
malicious individual to reconstruct original
PAN data if they have access to both the
truncated and hashed version of a PAN.
Where hashed and truncated versions of
the same PAN are present in an entitys
environment, additional controls should
be in place to ensure that the hashed and
truncated versions cannot be correlated
to reconstruct the original PAN.
3.5 Protect any keys used to secure cardholder data
against disclosure and misuse:
Note: This requirement also applies to key-
encrypting keys used to protect dataencrypting
keyssuch key-encrypting keys must be at least as
strong as the data-encrypting key.
Cryptographic keys must be strongly protected
because those who obtain access will be able to
decrypt data. Key-encrypting keys, if used, must be
at least as strong as the data-encrypting key in order
to ensure proper protection of the key that encrypts
the data as well as the data encrypted with that key.
The requirement to protect keys from disclosure and
misuse applies to both data- encrypting keys and
key-encrypting keys. Because one key-encrypting
key may grant access to many data-encrypting keys,
the key-encrypting keys require strong protection
measures. Methods for secure storage of key-
encrypting keys include but are not limited to
hardware security modules (HSMs) and tamper
evident storage with dual control and split
knowledge.
3.5.1 Restrict access to cryptographic keys to the
fewest number of custodians necessary.
There should be very few who have access to
cryptographic keys, usually only those who have key
custodian responsibilities.
The intent of this requirement is to address the
acceptability of disk encryption for rendering
cardholder data unreadable. Disk encryption
encrypts data stored on a computer's mass storage
and automatically decrypts the information when an
authorized user requests it. Disk-encryption systems
intercept operating system read and write
operations and carry out the appropriate
cryptographic transformations without any special
action by the user other than supplying a password
or pass phrase at the beginning of a session. Based
on these characteristics of disk encryption, to be
compliant with this requirement, the disk-
encryption method cannot have:
1) A direct association with the operating system, or
2) Decryption keys that are associated with user
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 user account
databases). Decryption keys must not be tied to
user accounts.
3.5.3 Store cryptographic keys securely in the fewest
possible locations and forms.
Cryptographic keys must be stored securely, usually
encrypted with key-encrypting keys, and stored in
very few locations. It is not intended that the key-
encrypting keys be encrypted, however they are to
be protected against disclosure and misuse as
defined in Requirement 3.5. Storing key-encrypting
keys in physically and/or logically separate locations
from data-encrypting keys reduces the risk of
unauthorized access to both keys.
Cryptographic keys must be stored securely to
prevent unauthorized or unnecessary access that
could result in the exposure of cardholder data.
It is not intended that the key-encrypting keys be
encrypted, however they are to be protected against
disclosure and misuse as defined in Requirement
3.5. If key-encrypting keys are used, storing the key-
encrypting keys in physically and/or logically
separate locations from the data- encrypting keys
reduces the risk of unauthorized access to both keys.
3.5.2 Store secret and private keys used to
encrypt/decrypt cardholder data in one (or more) of
the following forms at all times:
-Encrypted with a key-encrypting key that is at least
as strong as the data-encrypting key, and that is
stored separately from the data- encrypting key
-Within a secure cryptographic device (such as a
host security module (HSM) or PTS-approved point-
of-interaction device)
-As at least two full-length key components or key
shares, in accordance with an industry- accepted
method
3.6.2 Secure cryptographic key distribution
3.6 Fully document and implement all key-
management processes and procedures for
cryptographic keys used for encryption of
cardholder data, including the following:
Note: Numerous industry standards for key
management are available from various resources
including NIST, which can be found at
http://csrc.nist.gov.
The manner in which cryptographic keys are
managed is a critical part of the continued security
of the encryption solution. A good key management
process, whether it is manual or automated as part
of the encryption product, is based on industry
standards and addresses all key elements at 3.6.1
through 3.6.8.
The encryption solution must generate strong keys,
as defined in the PCI DSS and PA-DSS Glossary of
Terms, Abbreviations, and Acronyms under "strong
cryptography."
3.6.3 Secure cryptographic key storage
The encryption solution must distribute keys
securely, meaning the keys are not distributed in the
clear, and only to custodians identified in 3.5.1.
The encryption solution must store keys securely,
meaning the keys are not stored in the clear (encrypt
them with a key-encryption key).
3.6.1 Generation of strong cryptographic keys
3.6.4 Cryptographic key changes for keys that have
reached the end of their cryptoperiod (for example,
after a defined period of time has passed and/or
after a certain amount of ciphertext has been
produced by a given key), as defined by the
associated application vendor or key owner, and
based on industry best practices and guidelines (for
example, NIST Special Publication 800-57).
A cryptoperiod is the time span during which a
particular cryptographic key can be used for its
defined purpose. Considerations for defining the
cryptoperiod include, but are not limited to, the
strength of the underlying algorithm, size or length
of the key, risk of key compromise, and the
sensitivity of the data being encrypted.
Periodic changing of encryption keys when the keys
have reached the end of their cryptoperiod is
imperative to minimize the risk of someones
obtaining the encryption keys, and being able to
decrypt data.
If provided by encryption application vendor, follow
the vendors documented processes or
recommendations for periodic changing of keys. The
designated key owner or custodian can also refer to
industry best practices on cryptographic algorithms
and key management, for example NIST Special
Publication 800-57, for guidance on the appropriate
cryptoperiod for different algorithms and key
lengths.
The intent of this requirement applies to keys used
to encrypt stored cardholder data, and any
respective key-encrypting keys.
Old keys that are no longer used or needed should
be retired and destroyed to ensure that the keys can
no longer be used. If old keys need to be kept (to
support archived, encrypted data, for example) they
should be strongly protected. (See 3.6.6 below.) The
encryption solution should also allow for and
facilitate a process to replace keys that are known to
be, or suspected of being, compromised.
3.6.5 Retirement or replacement (for example,
archiving, destruction, and/or revocation) of keys
as deemed necessary when the integrity of the key
has been weakened (for example, departure of an
employee with knowledge of a clear-text key), or
keys are suspected of being compromised.
Note: If retired or replaced cryptographic keys
need to be retained, these keys must be securely
archived (for example, by using a key encryption
key). Archived cryptographic keys should only be
used for decryption/verification purposes.
The encryption solution should not allow for or
accept substitution of keys coming from
unauthorized sources or unexpected processes.
3.6.8 Requirement for cryptographic key custodians
to formally acknowledge that they understand and
accept their key-custodian responsibilities.
This process will ensure individuals that act as key
custodians commit to the key- custodian role and
understand the responsibilities.
3.6.7 Prevention of unauthorized substitution of
cryptographic keys.
Split knowledge and dual control of keys are used to
eliminate the possibility of one persons having
access to the whole key. This control is applicable for
manual key management operations, or where key
management is not implemented by the encryption
product.
3.6.6 If manual clear-text cryptographic key
management operations are used, these operations
must be managed using split knowledge and dual
control (for example, requiring two or three people,
each knowing only their own key component, to
reconstruct the whole key).
Note: Examples of manual key management
operations include, but are not limited to: key
generation, transmission, loading, storage and
destruction.
3.7 Ensure that security policies and operational
procedures for protecting stored cardholder data are
documented, in use, and known to all affected parties.
Personnel need to be aware of and following
security policies and documented operational
procedures for managing the secure storage of
cardholder data on a continuous basis.
Go to requirement
4 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
NC 3.1 Obtain and examine the policies, procedures and processes for data retention and
disposal, and perform the following:
NC 3.1.1.a Verify that policies and procedures are implemented and include legal,
regulatory, and business requirements for data retention, including specific
requirements for retention of cardholder data (for example, cardholder data needs to
be held for X period for Y business reasons).
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed,
and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms.
Major observations from the 2014 Verizon PCI Compliance report
According to the 2013 DBIR, of all the breaches studied by the Verizon Investigative Response team, not a single one involved cardholder data in transit between systems. However, two-thirds of data breaches involved data at rest.
18.2% of organizations suffering a breach had Requirement 3 in place in 2013.
32.7% of companies complied with Requirement 3 in 2013
Many organizations failed to comply with 3.4, which demands that they confirm that the PAN is rendered unreadable via hashes, truncation, strong encryption or tokenization. Just 47.5% of companies were compliant with all four validation testing requirements:
3.1.1.b Verify that policies and procedures include provisions for secure disposal of
data when no longer needed for legal, regulatory, or business reasons, including
disposal of cardholder data.
3.1.1.c Verify that policies and procedures include coverage for all storage of
cardholder data.
NA 3.2.a For issuers and/or companies that support issuing services and store sensitive
authentication data, verify there is a business justification for the storage of sensitive
authentication data, and that the data is secured.
3.2.b For issuers and/or companies that support issuing services and store sensitive
authentication data, examine data stores and system configurations to verify that the
sensitive authentication data is secured.
3.2.c For all other entities, if sensitive authentication data is received, review policies
and procedures, and examine system configurations to verify the data is not retained
after authorization.
3.2.d For all other entities, if sensitive authentication data is received, review
procedures and examine the processes for securely deleting the data to verify that the
data is unrecoverable.
NA 3.2.1 For a sample of system components, examine data sources, including but not
limited to the following, and verify that the full contents of any track from the
magnetic stripe on the back of card or equivalent data on a chip are not stored under
any circumstance:
- Incoming transaction data
- All logs (for example, transaction, history, debugging, error)
- History files
- Trace files
- Several database schemas
- Database contents
NA 3.2.2 For a sample of system components, examine data sources, including but not
limited to the following, and verify that the threedigit or four-digit card verification
code or value printed on the front of the card or the signature panel (CVV2, CVC2,
CID, CAV2 data) is not stored under any circumstance:
- Incoming transaction data
- All logs (for example, transaction, history, debugging, error)
- History files
- Trace files
- Several database schemas
- Database contents
NA 3.2.3 For a sample of system components, examine data sources, including but not
limited to the following and verify that PINs and encrypted PIN blocks are not stored
under any circumstance:
- Incoming transaction data
- All logs (for example, transaction, history, debugging, error)
- History files
- Trace files
- Several database schemas
- Database contents
NA 3.3.a Examine written policies and procedures for masking the display of PANs to verify:
A list of roles that need access to displays of full PAN is documented, together with a
legitimate business need for each role to have such access.
PAN must be masked when displayed such that only personnel with a legitimate
business need can see the full PAN.
All other roles not specifically authorized to see the full PAN must only see masked
PANs..
3.3.b Examine system configurations to verify that full PAN is only displayed for
users/roles with a documented business need, and that PAN is masked for all other
requests.
3.3.c Examine displays of PAN for example, on screen, on paper receipts) to verify that
PANs are masked when displaying cardholder data, and that only those with a
legitimate business need are able to see full PAN.
3.4.a Examine documentation about the system used to protect the PAN, including the
vendor, type of system/process, and the encryption algorithms (if applicable) to verify
that the PAN is rendered unreadable using any of the following methods:
One-way hashes based on strong cryptography,
Truncation
Index tokens and pads, with the pads being securely stored
Strong cryptography, with associated key- management processes and procedures.
3.4.b Examine several tables or files from a sample of data repositories to verify the
PAN is rendered unreadable (that is, not stored in plain-text).
3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm
that the PAN is rendered unreadable.
3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable or
removed from the logs.
C17.7
C8.4
NC 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 user account databases).
3.4.1.b Verify that cryptographic keys are stored securely (for example, stored on
removable media that is adequately protected with strong access controls).
3.4.1.c Examine the configurations and observe the processes to verify that
cardholder data on removable media is encrypted wherever stored.
NC 3.5 Examine key-management policies and procedures to verify processes are
specified to protect keys used for encryption of cardholder data against disclosure
and misuse and include at least the following:
Access to keys is restricted to the fewest number of custodians necessary.
Key-encrypting keys are at least as strong as the data- encrypting keys they protect.
Key-encrypting keys are stored separately from data- encrypting keys.
Keys are stored securely in the fewest possible locations and forms.
NC 3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest
number of custodians necessary.
3.5.2.a Examine documented procedures to verify that cryptographic keys used to
encrypt/decrypt cardholder data must only exist in one (or more) of the following
forms at all times.
Encrypted with a key-encrypting key that is at least as strong as the data-encrypting
key, and that is stored separately from the data-encrypting key
Within a secure cryptographic device (such as a host security module (HSM) or PTS-
approved point-of- interaction device)
As key components or key shares, in accordance with an industry-accepted method
3.5.2.b Examine system configurations and key storage locations to verify that
cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of
the following form at all times.
Encrypted with a key-encrypting key
Within a secure cryptographic device (such as a host security module (HSM) or PTS-
approved point-of- interaction device)
As key components or key shares, in accordance with an industry-accepted method
3.5.2.c Wherever key-encrypting keys are used, examine system configurations and key
storage locations to verify:
Key-encrypting keys are at least as strong as the data- encrypting keys they protect
Key-encrypting keys are stored separately from data- encrypting keys.
NC 3.5.3 Examine key storage locations and observe processes to verify that keys are
stored in the fewest possible locations.
NC 3.6.a Additional Procedure for service providers: If the service provider shares keys with
their customers for transmission or storage of cardholder data, examine the
documentation that the service provider provides to their customers to verify that it
includes guidance on how to securely transmit, store, and update customers keys, in
accordance with Requirements 3.6.1 through 3.6.8 below.
3.6.bExamine the key-management procedures and processes for keys used for
encryption of cardholder data and perform the following:
3.6.1.a Verify that key- management procedures specify how to generate strong keys.
3.6.1.b Observe the method for generating keys to verify that strong keys are
generated
3.6.2.a Verify that key- management procedures specify how to securely distribute
keys.
3.6.2.b Observe the method for distributing keys to verify that keys are distributed
securely.
3.6.3.a Verify that key- management procedures specify how to securely store keys.
3.6.3.b Observe the method for storing keys to verify that keys are stored securely.
NC
NC
NC
3.6.4.a Verify that key-management procedures are implemented to require periodic
key changes at the end of the defined cryptoperiod.
3.6.4.b Interview personnel to verify that keys are changed at the end of the defined
cryptoperiod(s).
NC 3.6.5.a Verify that key- management procedures specify processes for the following:
The retirement or replacement of keys when the integrity of the key has been
weakened.
The replacement of known or suspected compromised keys.
Any keys retained after retiring or replacing are not used for encryption operations.
3.6.5.b Interview personnel to verify the following processes are implemented:
Keys are retired or replaced as necessary when the integrity of the key has been
weakened, including when someone with knowledge of the key leaves the
company.
Keys are replaced if known or suspected to be compromised.
Any keys retained after retiring or replacing are not used for encryption operations.
NC
3.6.6.a Verify that manual clear- text key-management procedures specify
processes for the use of the following:
Split knowledge of keys, such that key components are under the control of at least
two people who only have knowledge of their own key components; AND
Dual control of keys, such that at least two people are required to perform any key-
management operations and no one person has access to the authentication
materials (for example, passwords or keys) of another.
3.6.6 b Interview personnel and/or observe processes to verify that manual clear-text
keys are managed with:
Split knowledge, AND
Dual control
3.6.7.a Verify that key- management procedures specify processes to prevent
unauthorized substitution of keys.
3.6.7.b Interview personnel and/or observe process to verify that unauthorized
substitution of keys is prevented.
3.6.8.a Verify that key- management procedures specify processes for key custodians
to acknowledge (in writing or electronically) that they understand and accept their
key-custodian responsibilities.
3.6.8.b Observe documentation or other evidence showing that key custodians have
acknowledged (in writing or electronically) that they understand and accept their key-
custodian responsibilities.
NC
NC
NC
3.7 Examine documentation interview personnel to verify that security policies and
operational procedures for protecting stored cardholder data are:
Documented,
In use, and
Known to all affected parties.
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A
left blank by pcico 1 0
Identify the data-retention and disposal documentation examined to verify policies,
procedures, and processes define:
Legal, regulatory, and business requirements for data retention, including:
- Specificrequirementsforretentionof
cardholder data (for example, cardholder data needs to be held for X period for Y
business reasons).
- Securedeletionofcardholderdatawhen no longer needed for legal, regulatory, or
business reasons.
- Coverageforallstorageofcardholder data.
A quarterly process for identifying and securely deleting stored cardholder data that
exceeds defined retention requirements.
<Report Findings Here>
1 0
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed,
and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms.
Major observations from the 2014 Verizon PCI Compliance report
According to the 2013 DBIR, of all the breaches studied by the Verizon Investigative Response team, not a single one involved cardholder data in transit between systems. However, two-thirds of data breaches involved data at rest.
18.2% of organizations suffering a breach had Requirement 3 in place in 2013.
32.7% of companies complied with Requirement 3 in 2013
Many organizations failed to comply with 3.4, which demands that they confirm that the PAN is rendered unreadable via hashes, truncation, strong encryption or tokenization. Just 47.5% of companies were compliant with all four validation testing requirements:
Selected Merchant Type:

Identify the personnel interviewed who confirm that:
All locations of stored cardholder data are included in the data-retention and disposal
processes.
Either a quarterly automatic or manual process is in place to identify and securely
delete stored cardholder data.
The quarterly automatic or manual process is performed for all locations of
cardholder data.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify the following:
All locations of stored cardholder data are included in the data-retention and disposal
process.
<Report Findings Here>
Either a quarterly automatic or manual process is in place to identify and securely
delete stored cardholder data.
<Report Findings Here>
The quarterly automatic or manual process is performed for all locations of cardholder
data.
<Report Findings Here>
Describe the quarterly process in place to identify and securely delete stored
cardholder data, including whether it is an automatic or manual process.
<Report Findings Here>
1 0
Identify the sample of system components selected.
<Report Findings Here>
For each item in the sample, describe how files and system records were examined to
verify that the data stored does not exceed the requirements defined in the data-
retention policy.
<Report Findings Here>
Describe how the deletion mechanism was observed to verify data is deleted securely.
<Report Findings Here>
1 0
Identify whether the assessed entity is an issuer or supports issuing service. (yes/no)
<Report Findings Here>
If yes, complete the responses for 3.2.a and 3.2.b and mark 3.2.c and 3.2.d as Not
Applicable. If no, mark the remainder of 3.2.a and 3.2.b as Not Applicable and
proceed to 3.2.c and 3.2.d.
Identify the documentation reviewed to verify there is a documented business
justification for the storage of sensitive authentication data.
<Report Findings Here>
Identify the interviewed personnel who confirm there is a documented business
justification for the storage of sensitive authentication data.
<Report Findings Here>
For the interview, summarize the relevant details of the business justification described.
<Report Findings Here>
1 0
If yes at 3.2.a,
Identify data stores examined.
<Report Findings Here>
Identify the system configurations examined.
<Report Findings Here>
Describe how the data stores and system configurations were examined to verify that
the sensitive authentication data is secured.
<Report Findings Here>
1 0
Identify whether sensitive authentication data is received. (yes/no)
<Report Findings Here>
If yes, complete 3.2.c and 3.2.d.
If no, mark the remainder of 3.2.c and 3.2.d as Not Applicable and proceed to 3.2.1.
Identify the document(s) reviewed to verify that it defines that data is not retained
after authorization.
<Report Findings Here>
Describe how system configurations were examined to verify the data is not retained
after authorization.
<Report Findings Here>
1 0
Identify the document(s) reviewed to verify that it defines processes for securely
deleting the data to verify that the data is unrecoverable.
<Report Findings Here>
Describe how the processes for securely deleting the data were examined to verify that
the data is unrecoverable.
<Report Findings Here>
2 0
Identify the sample of system components selected for 3.2.1-3.2.3.
<Report Findings Here>
For each data source type below from the sample of system of components examined,
summarize the specific examples of each data source type observed to verify that the
full contents of any track from the magnetic stripe on the back of card or equivalent
data on a chip are not stored after authorization. If that type of data source is not
present, indicate that in the space.

Incoming transaction data


<Report Findings Here>
All logs (for example, transaction, history, debugging error)
<Report Findings Here>
History files
<Report Findings Here>
Trace files
<Report Findings Here>
Database schemas
<Report Findings Here>
Database contents
<Report Findings Here>
If applicable, any other output observed to be generated
<Report Findings Here>
1 0
For each data source type below from the sample of system of components at 3.2.1,
summarize the specific examples of each data source type observed to verify that the
three-digit or four-digit card verification code or value printed on the front of the card
or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization. If
that type of data source is not present, indicate that in the space.

Incoming transaction data


<Report Findings Here>

All logs (for example, transaction, history, debugging error)


<Report Findings Here>

History files
<Report Findings Here>

Trace files
<Report Findings Here>

Database schemas
<Report Findings Here>

Database contents
<Report Findings Here>

If applicable, any other output observed to be generated


<Report Findings Here>
1 0
For each data source type below from the sample of system of components at 3.2.1,
summarize the specific examples of each data source type observed. If that type of data
source is not present, indicate that in the space.
Incoming transaction data
<Report Findings Here>
All logs (for example, transaction, history,debugging error) History files
<Report Findings Here>
Trace files
<Report Findings Here>
Database schemas
<Report Findings Here>
Database contents
<Report Findings Here>

If applicable, any other output observed to be generated
<Report Findings Here>
1 0
Identify the document(s) reviewed to verify that written policies and procedures for
masking the displays of PANs include the following:
A list of roles that need access to displays of full PAN is documented, together with a
legitimate business need for each role to have such access.
PAN must be masked when displayed such that only personnel with a legitimate
business need can see the full PAN.
All other roles not specifically authorized to see the full PAN must only see masked
PANs.
<Report Findings Here>
5 0
Describe how system configurations were examined to verify that:

Full PAN is only displayed for users/roles with a documented business need.
<Report Findings Here>

PAN is masked for all other requests.


<Report Findings Here>
5 0
Describe how displays of PAN were examined to verify that:
PANs are masked when displaying cardholder data.
<Report Findings Here>
Only those with a legitimate business need are able to see full PAN.
<Report Findings Here>
5 0
Identify the documentation about the system used to protect the PAN
examined.
<Report Findings Here>
Briefly describe the documented methods including the vendor, type of
system/process, and then encryption algorithms (if applicable) used to
protect the PAN.
<Report Findings Here>
Identify which of the following methods is used to render the PAN unreadable:
One-way hashes based on strong cryptography
Truncation
Index token and pads, with the pads being
securely stored
Strong cryptography, with associated key- management processes and
procedures
<Report Findings Here>
5 0
Identify the sample of data repositories selected.
<Report Findings Here>
Identify the tables or files examined for each item in the sample of data
repositories.
<Report Findings Here>
For each item in the sample, describe how the table or file was examined to
verify the PAN is rendered unreadable.
<Report Findings Here>
5 0
Identify the sample of removable media selected.
<Report Findings Here>
For each item in the sample, describe how the sample of removable media was
examined to confirm that the PAN is rendered unreadable.
<Report Findings Here>
5 0
Identify the sample of audit logs selected.
<Report Findings Here>
For each item in the sample, describe how the sample of audit logs was
examined to confirm that the PAN is rendered unreadable or removed from the
logs.
<Report Findings Here>
5 0
Identify whether disk encryption is used. (yes/no)
<Report Findings Here>
If yes, complete the remainder of 3.4.1.a, 3.4.1.b, and 3.4.1.c.
If no, mark the remainder of 3.4.1.a, 3.4.1.b and 3.4.1.c as Not Applicable.
Describe the disk encryption mechanism(s) in use.
<Report Findings Here>
For each disk encryption mechanism in use, describe how the configuration was
inspected and the authentication process observed to verify that logical access
to encrypted file systems is separate from the native operating systems
authentication mechanism.
<Report Findings Here>
5 0
Describe how processes were observed to verify that cryptographic keys are
stored securely.
<Report Findings Here>
Identify the personnel interviewed who confirm that cryptographic keys are
5 0
Identify the configurations examined.
<Report Findings Here>
5 0
Identify the documented key-management policies and processes examined to verify
processes are defined to protect keys used for encryption of cardholder data against
disclosure and misuse and include at least the following:
Access to keys is restricted to the fewest number of custodians necessary.
Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
Key-encrypting keys are stored separately from data-encrypting keys.
Keys are stored securely in the fewest possible locations and forms.
<Report Findings Here>
5 0
Identify user access lists examined.
<Report Findings Here>
Describe how user access lists were examined to verify that access to keys is
restricted to the fewest number of custodians necessary.
<Report Findings Here>
5 0
Identify the documented procedures examined to verify that cryptographic keys
used to encrypt/decrypt cardholder data must only exist in one (or more) of the
following forms at all times.
Encrypted with a key-encrypting key that is at least as strong as the data-
encrypting key, and that is stored separately from the data-encrypting key.
Within a secure cryptographic device (such as a host security module (HSM) or
PTS- approved point-of-interaction device).
As key components or key shares, in accordance with an industry-accepted
method.
<Report Findings Here>
5 0
Provide the name of the assessor who attests that all locations where keys are
stored were identified.
<Report Findings Here>
Describe how system configurations and key storage locations were examined
to verify that cryptographic keys used to encrypt/decrypt cardholder data must
only exist in one (or more) of the following forms at all times.
Encrypted with a key-encrypting key that is at least as strong as the data-
encrypting key, and that is stored separately from the data-encrypting key.
Within a secure cryptographic device (such as a host security module (HSM) or
PTS- approved point-of-interaction device).
As key components or key shares, in accordance with an industry-accepted
method.
<Report Findings Here>
5 0
Describe how system configurations and key storage locations were examined
to verify that, wherever key-encrypting keys are used:

Key-encrypting keys are at least as strong as the data-encrypting keys they


protect
<Report Findings Here>
Key-encrypting keys are stored separately from data-encrypting keys.
<Report Findings Here>
5 0
Describe how key storage locations were examined and processes were
observed to verify that keys are stored in the fewest possible locations.
<Report Findings Here>
5 0
Identify whether the assessed entity is a service provider that shares keys with their
customers for transmission or storage of cardholder data. (yes/no)
<Report Findings Here>

If yes,

Identify the document that the service provider provides to their customers examined
to verify that it includes guidance on how to securely transmit, store and update
customers keys, in accordance with Requirements 3.6.1 through 3.6.8 below.
<Report Findings Here>
5 0
left blank by PCIco 5 0
Identify the documented key-management procedures examined to verify procedures
specify how to generate strong keys.
<Report Findings Here>
5 0
Describe how the method for generating strong keys was observedto verify that strong
keys are generated
<Report Findings Here>
6 0
Identify the documented key-management procedures examined to verify procedures
specify how to securely distribute keys.
<Report Findings Here>
5 0
Describe how the method for distributing keys was observed to verify that keys are
distributed securely.
<Report Findings Here>
6 0
Identify the documented key-management procedures examined to verify procedures
specify how to securely store keys.
<Report Findings Here>
5 0
Describe how the method for storing keys was observed to verify that keys are stored
securely.
<Report Findings Here>
6 0
Identify the document that defines:
Key cryptoperiod(s) for each key type in use
A process for key changes at the end of the defined cryptoperiod(s)
<Report Findings Here>
5 0
Identify personnel interviewed for this testing procedure who confirm that keys are
changed at the end of the defined cryptoperiod(s).
<Report Findings Here>
6 0
Identify the key-management document examined to verify that key-management
processes specify the following:
The retirement or replacement of keys when the integrity of the key has been
weakened.
The replacement of known or suspected compromised keys.
Any keys retained after retiring or replacing are not used for encryption operations.
<Report Findings Here>
5 0
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify the following
processes are implemented:
Keys are retired or replaced as necessary when the integrity of the key has been
weakened, including when someone with knowledge of the key leaves the company.
<Report Findings Here>
Keys are replaced if known or suspected to be compromised.
<Report Findings Here>
Any keys retained after retiring or replacing are not used for encryption operations.
<Report Findings Here>
5 0
Identify the document examined to verify that manual clear-text key-management
procedures define processes for the use of the following:
Split knowledge of keys, such that key components are under the control of at least two
people who only have knowledge of their own key components; AND
Dual control of keys, such that at least two people are required to perform any key-
management operations and no one person has access to the authentication materials
of another.
<Report Findings Here>
5 0
Identify the personnel interviewed for this testing procedure, if applicable.
<Report Findings Here>
For the interview, summarize the relevant details discussed and/or describe how
processes were observed to verify the following processes are implemented:
Split knowledge
<Report Findings Here>
Dual Control
<Report Findings Here>
5 0
Identify the document examined to verify that key-management procedures specify
processes to prevent unauthorized substitution of keys.
<Report Findings Here>
5 0
Identify the personnel interviewed for this testing procedure, if applicable.
<Report Findings Here>
For the interview, summarize the relevant details discussed and/or describe how
processes were observed to verify that unauthorized substitution of keys is prevented.
<Report Findings Here>
5 0
Identify the document examined to verify that key-management procedures specify
processes for key custodians to acknowledge that they understand and accept their key-
custodian responsibilities.
<Report Findings Here>
5 0
Describe how key custodian acknowledgements or other evidence were observed to
verify that key custodians have acknowledged that they understand and accept their
key-custodian responsibilities.
<Report Findings Here>
5 0
Identify the document reviewed to verify that security policies and operational
procedures for protecting stored cardholder data are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for protecting stored cardholder data are:
<Report Findings Here>
6
0
192 0
A-EP PE2P B B-IP C-VT C D S In Place ? Severity Proofs /
Documentation links
0 0 0 0 0 0 1 1 N 6
0 1 0 0 0 0 1 1 Y 0
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed,
and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms.
D
Selected Merchant Type:

0 1 0 0 0 0 1 1 N 6
0 1 0 0 0 0 1 1 N 6
0 0 1 0 0 1 1 1 N 6
0 0 1 0 0 1 1 1 N 6
1 0 1 1 1 1 1 1 N 6
0 0 1 1 1 1 1 1 N 5
0 0 1 1 0 1 1 1 N 6
1 1 1 1 1 1 1 1 N 6
1 0 1 1 1 1 1 1 N 6
0 1 1 1 1 1 1 1 N 2
0 0 1 1 1 1 1 1 N 2
0 0 1 1 0 1 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 NT 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 0 1 N 0
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 1
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 1
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 1
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 1
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2
0 1 0 0 0 0 1 1 N 1
3 6 10 8 6 10 45 46 Y 122
N
C
NT
NA
Stage of implementation Remediation plan
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed,
and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms.
Estimated date for completion Comments Owner
Name 1
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed,
and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms.
Return to Table of content Go to requirement 3
PCI DSS Requirement Guidance
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.
Sensitive information must be encrypted during
transmission over public networks, because it is easy
and common for a malicious individual to intercept
and/or divert data while in transit.
Secure transmission of cardholder data requires
using trusted keys/certificates, a secure protocol for
transport, and proper encryption strength to encrypt
cardholder data. Connection requests from systems
that do not support the required encryption
strength, and that would result in an insecure
connection, should not be accepted.
Note that some protocol implementations (such as
SSL v2.0, SSH v1.0 and TLS 1.0) have known
vulnerabilities that an attacker can use to gain
control of the affected system. Whichever security
protocol is used, ensure it is configured to use only
secure versions and configurations to prevent use of
an insecure connection. For example, TLS v1.1, or
later, certificates obtained from a recognized, public
certificate authority and supporting only strong
encryption, may be considered.
Verifying that certificates are trusted (for example,
have not expired and are issued from a trusted
source) helps ensure the integrity of the secure
connection.
4.1 Use strong cryptography and security protocols
(for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard
sensitive cardholder data during transmission over
open, public networks, including the following:
-Only trusted keys and certificates are accepted.
-The protocol in use only supports secure versions or
configurations.
-The encryption strength is appropriate for the
encryption methodology in use.
Major observations from the 2014 Verizon PCI Compliance Report:
The most-often complied-with subcontrols included 4.1.b on the use of trusted keys and certificates (84.2%) and 4.1.e on using HTTPS in web sessions (83.2%).
The least complied-with subcontrol within Requirement 4 was 4.1.a [Implement and maintain a system and supporting processes to ensure that cardholder data is always encrypted during transit over unsecure networks], with 24.8% of organizations failing to pass muster.
Sensitive information must be encrypted during
transmission over public networks, because it is easy
and common for a malicious individual to intercept
and/or divert data while in transit.
Secure transmission of cardholder data requires
using trusted keys/certificates, a secure protocol for
transport, and proper encryption strength to encrypt
cardholder data. Connection requests from systems
that do not support the required encryption
strength, and that would result in an insecure
connection, should not be accepted.
Note that some protocol implementations (such as
SSL v2.0, SSH v1.0 and TLS 1.0) have known
vulnerabilities that an attacker can use to gain
control of the affected system. Whichever security
protocol is used, ensure it is configured to use only
secure versions and configurations to prevent use of
an insecure connection. For example, TLS v1.1, or
later, certificates obtained from a recognized, public
certificate authority and supporting only strong
encryption, may be considered.
Verifying that certificates are trusted (for example,
have not expired and are issued from a trusted
source) helps ensure the integrity of the secure
connection.
4.1 Use strong cryptography and security protocols
(for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard
sensitive cardholder data during transmission over
open, public networks, including the following:
-Only trusted keys and certificates are accepted.
-The protocol in use only supports secure versions or
configurations.
-The encryption strength is appropriate for the
encryption methodology in use.
4.1.1 Ensure wireless networks transmitting
cardholder data or connected to the cardholder
data environment, use industry best practices (for
example, IEEE 802.11i) to implement strong
encryption for authentication and transmission.
Note: The use of WEP as a security control was
prohibited as of 30 June 2010.
Malicious users use free and widely available tools
to eavesdrop on wireless communications. Use of
strong cryptography can limit disclosure of
sensitive information across the network. Many
known compromises of cardholder data stored
only in the wired network originated when a
malicious user expanded access from an insecure
wireless network. Examples of wireless
implementations requiring strong cryptography
include but are not limited to GPRS, GSM, WIFI,
satellite, and Bluetooth.
Strong cryptography for authentication and
transmission of cardholder data is required to
prevent malicious users from gaining access to the
wireless network the data on the networkor
utilizing the wireless networks to get to other
internal networks or data. WEP encryption should
never be used as the sole means of encrypting
data over a wireless channel since it is not
considered strong cryptography, it is vulnerable
due to weak initialization vectors in the WEP key-
exchange process, and it lacks required key
rotation. An attacker can use freely available brute-
force cracking tools to easily penetrate WEP
encryption.
Current wireless devices should be upgraded
(example: upgrade access point firmware to
WPA2) to support strong encryption. If current
devices cannot be upgraded, new equipment
E-mail, instant messaging, and chat can be easily
intercepted by packet-sniffing during delivery
traversal across internal and public networks. Do not
utilize these messaging tools to send PAN unless
they provide strong encryption.
4.2 Never send unprotected PANs by end-user
messaging technologies (for example, e-mail, instant
messaging, chat, etc.).
4.3 Ensure that security policies and operational
procedures for encrypting transmissions of
cardholder data are documented, in use, and
known to all affected parties.
Personnel need to be aware of and following
security policies and operational procedures for
managing the secure transmission of cardholder
data on a continuous basis.
4.2 Never send unprotected PANs by end-user
messaging technologies (for example, e-mail, instant
messaging, chat, etc.).
Go to requirement 5 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
4.1.a Identify all locations where cardholder data is transmitted or received over
open, public networks. Examine documented standards and compare to system
configurations to verify the use of security protocols and strong cryptography for all
locations.
4.1.b Review documented policies and procedures to verify processes are specified for
the following:
For acceptance of only trusted keys and/or certificates
For the protocol in use to only support secure versions and configurations (that
insecure versions or configurations are not supported)
For implementation of proper encryption strength per the encryption methodology
in use
4.1.c Select and observe a sample of inbound and outbound transmissions as they
occur to verify that all cardholder data is encrypted with strong cryptography during
transit.
4.1.d Examine keys and certificates to verify that only trusted keys and/or certificates
are accepted.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.
C15.4.1
C17.6
Major observations from the 2014 Verizon PCI Compliance Report:
The most-often complied-with subcontrols included 4.1.b on the use of trusted keys and certificates (84.2%) and 4.1.e on using HTTPS in web sessions (83.2%).
The least complied-with subcontrol within Requirement 4 was 4.1.a [Implement and maintain a system and supporting processes to ensure that cardholder data is always encrypted during transit over unsecure networks], with 24.8% of organizations failing to pass muster.
4.1.e Examine system configurations to verify that the protocol is implemented to use
only secure configurations and does not support insecure versions or configurations.
4.1.f Examine system configurations to verify that the proper encryption strength is
implemented for the encryption methodology in use. (Check vendor
recommendations/best practices.)
4.1.g.For SSL/TLS implementations, examine system configurations to verify that
SSL/TLS is enabled whenever cardholder data is transmitted or received.
C15.4.1
C17.6
C7.1
C7.10
4.1.1 For wireless networks transmitting cardholder data or connected to the
cardholder data environment, verify that industry best practices (for example, IEEE
802.11i) are used to implement strong encryption for authentication and
transmission.
NA 4.2.a If end-user messaging technologies are used to send cardholder data, observe
processes for sending PAN and examine a sample of outbound transmissions as they
occur to verify that PAN is rendered unreadable or secured with strong cryptography
whenever it is sent via end-user messaging technologies.
4.2.b Review written policies to verify the existence of a policy stating that unprotected
PANs are not to be sent via end-user messaging technologies.
4.3 Examine documentation interview personnel to verify that security policies and
operational procedures for encrypting transmissions of cardholder data are:
Documented,
In use, and
Known to all affected parties.
Vaidation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A A-EP
Identify all locations where cardholder data is transmitted or received over open,
public networks.
<Report Findings Here>
Identify the documented standards examined
<Report Findings Here>
Describe how the documented standards were examined and compared to system
configurations to verify the use of:
Security protocols observed in use
<Report Findings Here>
Strong cryptography for all locations
<Report Findings Here>
2 0 1
Identify the document reviewed to verify that processes are specified for the
following:
insecure versions or configurations are not supported).
in use.
<Report Findings Here>
2 0 1
Describe the sample of inbound and outbound transmissions observed as they
occurred.
<Report Findings Here>
Describe how the samples of inbound and outbound transmissions were observed as
they occurred to verify that all cardholder data is encrypted with strong cryptography
during transit.
<Report Findings Here>
2 0 1
For all instances where cardholder data is transmitted or received over open, public
networks:
Describe the mechanisms used to ensure that only trusted keys and/or certificates
are accepted.
<Report Findings Here>
Describe how the mechanisms were observed to accept only trusted keys and/or
certificates.
<Report Findings Here>
2 0 1
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.
Major observations from the 2014 Verizon PCI Compliance Report:
The most-often complied-with subcontrols included 4.1.b on the use of trusted keys and certificates (84.2%) and 4.1.e on using HTTPS in web sessions (83.2%).
The least complied-with subcontrol within Requirement 4 was 4.1.a [Implement and maintain a system and supporting processes to ensure that cardholder data is always encrypted during transit over unsecure networks], with 24.8% of organizations failing to pass muster.
Selected Merchant Type:
For all instances where cardholder data Is transmitted or received over open, public
networks, describe how system configurations were observed to verify that the
protocol is implemented:
To use only secure configurations.
<Report Findings Here>
Does not support insecure versions or configurations.
<Report Findings Here>
2 0 1
For each encryption methodology in use,
Identify vendor recommendations/best practices for encryption strength.
<Report Findings Here>
Identify the encryption strength observed to be implemented.
<Report Findings Here>
2 0 0
Identify whether SSL/TLS use to encrypt cardholder date over open, public networks
at all in the cardholder date environment. (yes/no)
<Report Findings Here>
If yes, for all instances where SSL/TLS is used to encrypt cardholder data over open,
public networks, describe how system configurations were examined to verify that
SSL/TLS is enabled whenever cardholder data is transmitted or received, as follows:
HTTPS appears as part of the browser URL.
<Report Findings Here>
Cardholder is only requested if HTTPS appears as part of the URL.
<Report Findings Here>
2 0 0
identify all wireless networks transmitting cardholder data or connected to the
cardholder data environment.
<Report Findings Here>
Identify the documented standards examined to verify processes define the
following for all wireless networks identified:
Industry best practices (for example, IEEE 802.11i) are used to implement strong
encryption for authentication and transmission.
Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a
security control for authentication or transmission.
<Report Findings Here>
Describe how documented standards were examined and compared to system
configuration settings to verify the following for all wireless networks identified:
Industry best practices are used to implement strong encryption for authentication
and transmission.
<Report Findings Here>
Weak encryption is not used as a security control for authentication or
transmission.
<Report Findings Here>
2 0 0
Identify whether end-user messaging technologies are used to send cardholder data.
(yes/no)
<Report Findings Here>
f no, mark the remainder of 4.2.a as Not Applicable and proceed to 4.2.b. If yes,
complete the following:
Describe how processes for sending PAN were observed to verify that PAN is
rendered unreadable or secured with strong cryptography whenever it is sent via end-
user messaging technologies.
<Report Findings Here>
Describe the sample of outbound transmissions observed as they occurred to verify
that PAN is rendered unreadable or secured with strong cryptography whenever it is
sent via end-user messaging technologies.
<Report Findings Here>
2 0 0
If no at 4.2.a:
Identify the policy document stating that unprotected PANs must not be sent via end-
user messaging technologies.
<Report Findings Here>
If yes at 4.2.a:
Identify the policy document that explicitly prohibits PAN from being sent via end-
user messaging technologies under any circumstance.
<Report Findings Here>
2 0 1
Identify the document reviewed to verify that security policies and operational
procedures for encrypting transmissions of cardholder data are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for encrypting transmissions of
cardholder data are:
<Report Findings Here>
.
6
0 0
26 0 6
PE2P B B-IP C-VT C D S In Place? Severity Proofs /
Documentation links
0 0 1 1 1 1 1 N 5
0 0 1 1 1 1 1 Y 0
0 0 1 1 1 1 1 Y 0
0 0 1 1 1 1 1 N 5
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.
Selected Merchant Type: D
0 0 1 1 1 1 1 N 5
0 0 0 0 1 1 1 N 5
0 0 0 0 0 1 1 N 5
0 0 1 1 1 1 1 N 5
0 1 0 0 0 1 1 N 5
1 1 1 1 1 1 1 NT 5
0 0 0 0 0 1 1 N 1
1 2 7 7 8 11 11 Y 41
N
C
NT
NA
Stage of implementation Remediation plan
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.
Estimated date for completion Comments Owner
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.
Return to Table of content Go to requirement 4
PCI DSS Requirement Guidance
5.1 Deploy anti-virus software on all systems
commonly affected by malicious software
(particularly personal computers and servers).
There is a constant stream of attacks using widely
published exploits, often "0 day" (published and
spread throughout networks within an hour of
discovery) against otherwise secured systems.
Without anti-virus software that is updated
regularly, these new forms of malicious software can
attack and disable your network.
Malicious software may be unknowingly
downloaded and/or installed from the internet, but
computers are also vulnerable when using
removable storage devices such as CDs and DVDs,
USB memory sticks and hard drives, digital cameras,
personal digital assistants (PDAs) and other
peripheral devices. Without anti-virus software
installed, these computers may become access
points into your network, and/or maliciously target
information within the network.
While systems that are commonly affected by
malicious software typically do not include
mainframes and most Unix systems (see more detail
below), each entity must have a process according
to PCI DSS Requirement 6.2 to identify and address
new security vulnerabilities and update their
configuration standards and processes accordingly.
If another type of solution addresses the identical
threats with a different methodology than a
signature-based approach, it may still be acceptable
to meet the requirement.
Trends in malicious software related to operating
Major Observations from the 2014 Verizon PCI Compliance Report:
Just 34.9% compliance with Requirement 5. The average compliance across all organizations was 56.4%.
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
5.1.1 Ensure that all anti-virus programs are
capable of detecting, removing, and protecting
against all known types of malicious software.
It is important to protect against ALL types and
forms of malicious software.
5.1.2 For systems considered to be not commonly
affected by malicious software, perform periodic
evaluations to identify and evaluate evolving
malware threats in order to confirm whether such
systems continue to not require anti-virus
software.
Typically, mainframes, mid-range computers (such
as AS/400) and similar systems may not currently
be commonly targeted or affected by malware.
However, industry trends for malicious software
can change quickly, so it is important for
organizations to be aware of new malware that
might affect their systemsfor example, by
monitoring vendor security notices and anti-virus
news groups to determine whether their systems
might be coming under threat from new and
evolving malware.
Trends in malicious software should be included in
the identification of new security vulnerabilities,
and methods to address new trends should be
incorporated into the company's configuration
standards and protection mechanisms as needed
Even the best anti-virus solutions are limited in
effectiveness if they are not maintained and kept
current with the latest security updates, signature
files, or malware protections.
Audit logs provide the ability to monitor virus and
malware activity and anti-malware reactions. Thus,
it is imperative that anti-malware solutions be
configured to generate audit logs and that these logs
be managed in accordance with Requirement 10.
5.2 Ensure that all anti-virus mechanisms are
maintained as follows:
Are kept current,
Perform periodic scans
Generate audit logs which are
retained per PCI DSS Requirement 10.7.
Even the best anti-virus solutions are limited in
effectiveness if they are not maintained and kept
current with the latest security updates, signature
files, or malware protections.
Audit logs provide the ability to monitor virus and
malware activity and anti-malware reactions. Thus,
it is imperative that anti-malware solutions be
configured to generate audit logs and that these logs
be managed in accordance with Requirement 10.
5.2 Ensure that all anti-virus mechanisms are
maintained as follows:
Are kept current,
Perform periodic scans
Generate audit logs which are
retained per PCI DSS Requirement 10.7.
5.3 Ensure that all anti-virus mechanisms are
current, actively running, and generating audit logs.
Anti-virus that continually runs and is unable to be
altered will provide persistent security against
malware.
Use of policy-based controls on all systems to ensure
anti-malware protections cannot be altered or
disabled will help prevent system weaknesses from
being exploited by malicious software.
Additional security measures may also need to be
implemented for the period of time during which
anti-virus protection is not activefor example,
disconnecting the unprotected system from the
Internet while the anti-virus protection is disabled,
and running a full scan after it is re-enabled.
5.4 Ensure that security policies and operational
procedures for protecting systems against
malware are documented, in use, and known to
all affected parties.
Personnel need to be aware of and following
security policies and operational procedures to
ensure systems are protected from malware on a
continuous basis.
Go to requirement 6 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
C5.1 5.1 For a sample of system components including all operating system types commonly
affected by malicious software, verify that anti-virus software is deployed if applicable
anti-virus technology exists.
Major Observations from the 2014 Verizon PCI Compliance Report:
Just 34.9% compliance with Requirement 5. The average compliance across all organizations was 56.4%.
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
C5.1
C5.2
C5.3
C5.4
C5.5
5.1.1 For a sample of system components, verify that all anti-virus programs detect,
remove, and protect against all known types of malicious software (for example,
viruses, Trojans, worms, spyware, adware, and rootkits).
5.1.2 Interview personnel to verify that evolving malware threats are monitored and
evaluated for systems not currently considered to be commonly affected by
malicious software, in order to confirm whether such systems continue to not require
anti-virus software.
5.2.a Examine policies and procedures to verify that anti-virus software and
definitions are required to be kept up to date.
5.2.b Examine anti-virus configurations, including the master installation of the
software to verify anti-virus mechanisms are:
Configured to perform automatic updates, and
Configured to perform periodic scans.
5.2.c Examine a sample of system components, including all operating system types
commonly affected by malicious software, to verify that:
The anti-virus software and definitions are current.
Periodic scans are performed.
5.2.d Examine anti-virus configurations, including the master installation of the
software and a sample of system components, to verify that:
Anti-virus software log generation is enabled, and
Logs are retained in accordance with PCI DSS Requirement 10.7.
5.3.a Examine anti-virus configurations, including the master installation of the
software and a sample of system components, to verify the anti-virus software is
actively running.
5.3.b Examine anti-virus configurations, including the master installation of the
software and a sample of system components, to verify that the anti-virus software
cannot be disabled or altered by users.
5.3.c Interview responsible personnel and observe processes to verify that anti-virus
software cannot be disabled or altered by users, unless specifically authorized by
management on a case-by-case basis for a limited time period.
C5.2
5.4 Examine documentation and interview personnel to verify that security policies
and operational procedures for protecting systems against malware are:
Documented,
In use, and
Known to all affected parties.
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A A-EP PE2P
Identify the sample of system components observed (include all operating system types
commonly affected by malicious software).
to be deployed.
<Report Findings Here>
2
0 1 0
Major Observations from the 2014 Verizon PCI Compliance Report:
Just 34.9% compliance with Requirement 5. The average compliance across all organizations was 56.4%.
Selected Merchant Type:
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
Identify the vendor documentation reviewed to verify that anti-virus programs:
Detect all known types of malicious software,
Remove all known types of malicious software, and
Protect against all known types of malicious software.
<Report Findings Here>
Describe how anti-virus configurations were examined to verify that anti-virus
programs:
Detect all known types of malicious software,
<Report Findings Here>
Remove all known types of malicious software
<Report Findings Here>
Protect against all known types of malicious software.
<Report Findings Here>
2
0 1 0
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed and/or describe how
processes were observed to verify that evolving malware threats are monitored and
evaluated for systems not currently considered to be commonly affected by
malicious software, and that such systems continue to not require anti-virus software.
<Report Findings Here>
2
0 1 0
Identify the documented policies and procedures examined to verify that anti-virus
software and definitions are required to be kept up to date.
<Report Findings Here>
2
0 1 0
Describe how anti-virus configurations, including the master installation of the
software, were examined to verify anti-virus mechanisms are:
Configured to perform automatic updates,
<Report Findings Here>
Configured to perform periodic scans.
<Report Findings Here>
2
0 1 0
Identify the sample of system components, including all operating system types
commonly affected by malicious software, selected for this testing procedure.
<Report Findings Here>
Describe how system components were examined to verify that:
The anti-virus software and definitions are current.
<Report Findings Here>
Periodic scans are performed.
<Report Findings Here>
2
0 1 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how anti-virus configurations, including the
master installation of the software, were examined to verify that:
Anti-virus software log generation is enabled
<Report Findings Here>
Logs are retained in accordance with PCI DSS Requirement 10.7
<Report Findings Here>
2
0 1 0
Identify the sample of system components selected.
<Report Findings Here>
For each item in the sample, describe how anti-virus configurations, including the
master installation of the software, were examined to verify that the anti-virus
software is actively running.
<Report Findings Here>
2
0 1 0
For each item in the sample from 5.3.a, describe how anti-virus configurations,
including the master installation of the software, were examined to verify that the
anti-virus software cannot be disabled or altered by users.
<Report Findings Here>
2
0 1 0
0 1 Identify the responsible personnel interviewed who confirm that anti-virus software
cannot be disabled or altered by users, unless specifically authorized by management
on a case-by-case basis for a limited time period.
<Report Findings Here>
Describe how the process was observed to verify that anti-virus software cannot be
disabled or altered by users, unless specifically authorized by management on a case-
by-case basis for a limited time period.
<Report Findings Here>
2
0
Identify the document reviewed to verify that security policies and operational
procedures for protecting systems against malware are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for protecting systems against malware
are:
<Report Findings Here>
6
0 0 0
26 0 10 0
B B-IP C-VT C D S In Place? Severity Proofs / Documentation
links
0 0 1 1 1 1 N 5
Selected Merchant Type: D
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
0 0 1 1 1 1 N 5
0 0 1 1 1 1 N 5
0 0 1 1 1 1 N 5
0 0 1 1 1 1 N 5
0 0 1 1 1 1 NT 5
0 0 1 1 1 1 N 5
0 0 1 1 1 1 N 5
0 0 1 1 1 1 N 5
1 1 1 1 Y 0
0 0
0 0 0 0 1 1
NT
1
0 0 10 10 11 11 Y 46
N
C
NT
NA
Stage of implementation Remediation plan
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
Estimated date for completion Comments Owner
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
Return to Table of content Go to requirement 5
PCI DSS Requirement Guidance
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
6.1 Ensure that all system components and software
are protected from known vulnerabilities by having
the latest vendor-supplied security patches installed.
Install critical security patches within one month of
release.
Note: An organization may consider applying a risk-
based approach to prioritize their patch
installations. For example, by prioritizing critical
infrastructure (for example, public-facing devices
and systems, databases) higher than less-critical
internal devices, to ensure high-priority systems and
devices are addressed within one month, and
addressing less critical devices and systems within
three months.
There are a considerable amount of attacks using
widely published exploits, often "0 day" (published
within the hour) against otherwise secured systems.
Without implementing the most recent patches on
critical systems as soon as possible, a malicious
individual can use these exploits to attack and
disable the network. Consider prioritizing changes
such that critical security patches on critical or at-
risk systems can be installed within 30 days, and
other less-risky changes are installed within 2-3
months.
Major observations from the 2014 Verizon PCI Compliance Report:
-The three most-often complied-with subcontrols were all met by at least three-quarters of the organizations we analyzed.
6.5.b [Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques] is relatively simple to comply with, given the wealth of resources in secure coding available from major vendors such as Microsoft and Oracle.
Subcontrols 6.4.4 and 6.3.1 govern the process of moving a system into production; specifying that test data, accounts and user IDs are removed before the system goes live a one-off activity thats relatively easy to incorporate into launch processes.
-The least-often complied-with subcontrols tended to be those related to the much more problematic areas of identifying and managing vulnerabilities and the associated changes on an ongoing basis. For example, 6.1.a (renumbered 6.2 in DSS 3.0) demands that systems and software are verified to have the
latest vendor security patches installed. This subcontrol ranked among our Bottom 20, with only 49.5% compliance.
-Patch management and associated vulnerability management processes represent the biggest problem areas, because theyre rarely well documented and automated.
-6.4Change-management is also of significant problems specifically relating to documentation and verification of changes. Change-management features, such as functionality testing and change impact assessment documentation, were not in place in about half of the organizations assessed.
6.3 Develop software applications (internal and
external, and including webbased administrative
access to applications) in accordance with PCI DSS
(for example, secure authentication and logging),
and based on industry best practices. Incorporate
information security throughout the software
development life cycle. These processes must
include the following:
Without the inclusion of security during the
requirements definition, design, analysis, and testing
phases of software development, security
vulnerabilities can be inadvertently or maliciously
introduced into the production environment.
6.2 Establish a process to identify and assign a risk
ranking to newly discovered security vulnerabilities.
Notes:
- Risk rankings should be based on industry best
practices. For example, criteria for ranking High
risk vulnerabilities may include a CVSS base score of
4.0 or above, and/or a vendor-supplied patch
classified by the vendor as critical, and/or a
vulnerability affecting a critical system component.
- The ranking of vulnerabilities as defined in 6.2.a is
considered a best practice until June 30, 2012, after
which it becomes a requirement.
The intention of this requirement is that
organizations keep up-to-date with new
vulnerabilities that may impact their environment.
While it is important to monitor vendor
announcements for news of vulnerabilities and
patches related to their products, it is equally
important to monitor common industry vulnerability
news groups and mailing lists for vulnerabilities and
potential workarounds that may not yet be known
or resolved by the vendor.
Once an organization identifies a vulnerability that
could affect their environment, the risk that
vulnerability poses must be evaluated and ranked.
This implies that the organization has some method
in place to evaluate vulnerabilities and assign risk
rankings on a consistent basis. While each
organization will likely have different methods for
evaluating a vulnerability and assigning a risk rating
based on their unique CDE, it is possible to build
upon common industry accepted risk ranking
systems, for example CVSS. 2.0, NIST SP 800-30, etc.
Classifying the risks (for example, as high,
medium, or low) allows organizations to identify
and address high priority risk items more quickly,
and reduce the likelihood that vulnerabilities posing
the greatest risk will be exploited
6.3.1 Removal of custom application accounts,
user IDs, and passwords before applications
become active or are released to customers
Custom application accounts, user IDs, and
passwords should be removed from production code
before the application becomes active or is released
to customers, since these items may give away
information about the functioning of the application.
Possession of such information could facilitate
compromise of the application and related cardholder
data.
6.3.2 Review custom code prior to release to
production or customers in order to identify any
potential coding vulnerability (using either
manual or automated processes) to include at
least the following:
- Code changes are reviewed by individuals other
than the originating code author, and by
individuals knowledgeable about code-review
techniques and secure coding practices.
- Code reviews ensure code is developed
according to secure coding guidelines
- Appropriate corrections are implemented prior
to release.
-Code-review results are reviewed and approved
by management prior to release.
Security vulnerabilities in custom code are
commonly exploited by malicious individuals to gain
access to a network and compromise cardholder
data.
Code reviews may be performed manually, or with
the assistance of automated review tools.
Automated review tools have functionality that
reviews code for common coding mistakes and
vulnerabilities. While automated review is useful, it
should not generally be relied upon as the sole
means of code review. An individual knowledgeable
and experienced in code review should be involved
in the review process in order to identify code issues
that are difficult or even impossible for an
automated tool to identify. Assigning code reviews
to someone other than the developer of the code
allows an independent, objective review to be
performed.
6.4 Follow change control processes and procedures
for all changes to system components. The
processes must include the following:
Without proper change controls, security features
could be inadvertently or deliberately omitted or
rendered inoperable, processing irregularities could
occur, or malicious code could be introduced.
6.3.2 Review custom code prior to release to
production or customers in order to identify any
potential coding vulnerability (using either
manual or automated processes) to include at
least the following:
- Code changes are reviewed by individuals other
than the originating code author, and by
individuals knowledgeable about code-review
techniques and secure coding practices.
- Code reviews ensure code is developed
according to secure coding guidelines
- Appropriate corrections are implemented prior
to release.
-Code-review results are reviewed and approved
by management prior to release.
6.4.1 Separate development/test and production
environments
Security vulnerabilities in custom code are
commonly exploited by malicious individuals to gain
access to a network and compromise cardholder
data.
Code reviews may be performed manually, or with
the assistance of automated review tools.
Automated review tools have functionality that
reviews code for common coding mistakes and
vulnerabilities. While automated review is useful, it
should not generally be relied upon as the sole
means of code review. An individual knowledgeable
and experienced in code review should be involved
in the review process in order to identify code issues
that are difficult or even impossible for an
automated tool to identify. Assigning code reviews
to someone other than the developer of the code
allows an independent, objective review to be
performed.
Due to the constantly changing state of
development and test environments, they tend to be
less secure than the production environment.
Without adequate separation between
environments it may be possible for the production
environment, and cardholder data, to be
compromised due to vulnerabilities in a test or
development environment.
6.4.2 Separation of duties between
development/test and production environments
Reducing the number of personnel with access to
the production environment and cardholder data
minimizes risk and helps ensure that access is
limited to those individuals with a business need
to know.
The intent of this requirement is to ensure that
development/test functions are separated from
production functions. For example, a developer
may use an administrator-level account with
elevated privileges for use in the development
environment, and have a separate account with
user-level access to the production environment.
In environments where one individual performs
multiple roles (for example application
development and implementing updates to
production systems), duties should be assigned
such that no one individual has end-to-end control
of a process without an independent checkpoint.
For example, assign responsibility for
development, authorization and monitoring to
separate individuals.
6.4.3 Production data (live PANs) are not used for
testing or development
Security controls are usually not as stringent in the
development environment. Use of production data
provides malicious individuals with the opportunity
to gain unauthorized access to production data
(cardholder data).
Payment card brands and many acquires are able to
provide account numbers suitable for testing in the
event that you need realistic PANs to test system
functionality prior to release.
6.4.4 Removal of test data and accounts before
production systems become active
Test data and accounts should be removed from
production code before the application becomes
active, since these items may give away
information about the functioning of the
application. Possession of such information could
facilitate compromise of the application and
related cardholder data.
6.4.5.1 Documentation of impact. The impact of the change should be documented
so that all affected parties will be able to plan
appropriately for any processing changes.
Without proper change controls, security features
could be inadvertently or deliberately omitted or
rendered inoperable, processing irregularities could
occur, or malicious code could be introduced.
Likewise, a change may negatively affect security
functionality of a system necessitating the change to
be backed out.
6.4.5 Change control procedures for the
implementation of security patches and software
modifications. Procedures must include the
following:
6.4.5.2 Documented change approval by
authorized parties.
Approval by authorized parties indicates that the
change is a legitimate and approved change
sanctioned by the organization.
6.4.5.4 Back-out procedures. For each change, there should be back-out
procedures in case the change fails, to allow for
restoring back to the previous state.
6.5 Address common coding vulnerabilities in
software-development processes as follows:
- Train developers in secure coding techniques,
including how to avoid common coding
vulnerabilities, and understanding how sensitive
data is handled in memory.
- Develop applications based on secure coding
guidelines.
Thorough testing should be performed to verify that
the security of the environment is not reduced by
implementing a change. Testing should validate that
all existing security controls remain in place, are
replaced with equally strong controls, or are
strengthened after any change to the environment.
For custom code changes, testing includes verifying
that no coding vulnerabilities have been introduced
by the change.
6.4.5.3 Functionality testing to verify that the
change does not adversely impact the security of
the system.
The application layer is high-risk and may be
targeted by both internal and external threats.
Requirements 6.5.1 through 6.5.10 are the minimum
controls that should be in place, and organizations
should incorporate the relevant secure coding
practices as applicable to the particular technology
in their environment.
Application developers should be properly trained to
identify and resolve issues related to these (and
other) common coding vulnerabilities. Having staff
knowledgeable of secure coding guidelines should
minimize the number of security vulnerabilities
introduced through poor coding practices. Training
for developers may be provided in-house or by third
parties and should be applicable for technology used.
As industry-accepted secure coding practices
change, organizational coding practices and
developer training should likewise be updated to
address new threatsfor example, memory
scraping attacks.
The vulnerabilities identified in 6.5.1 through 6.5.10
provide a minimum baseline. It is up to the
organization to remain up to date with vulnerability
trends and incorporate appropriate measures into
their secure coding practices.
6.5.1 Injection flaws, particularly SQL injection.
Also consider OS Command Injection, LDAP and
XPath injection flaws as well as other injection
flaws.
Validate input to verify user data cannot modify
meaning of commands and queries. Injection
flaws, particularly SQL injection, are a commonly
used method for compromising applications.
Injection occurs when user-supplied data is sent to
an interpreter as part of a command or query. The
attacker's hostile data tricks the interpreter into
executing unintended commands or changing
data, and allows the attacker to attack
components inside the network through the
application, to initiate attacks such as buffer
overflows, or to reveal both confidential
information and server application functionality.
This is also a popular way to conduct fraudulent
transactions on commerce-enabled web sites.
Information from requests should be validated
before being sent to the application for example,
by checking for all alpha characters, mix of alpha
and numeric characters, etc.
6.5 Address common coding vulnerabilities in
software-development processes as follows:
- Train developers in secure coding techniques,
including how to avoid common coding
vulnerabilities, and understanding how sensitive
data is handled in memory.
- Develop applications based on secure coding
guidelines.
The application layer is high-risk and may be
targeted by both internal and external threats.
Requirements 6.5.1 through 6.5.10 are the minimum
controls that should be in place, and organizations
should incorporate the relevant secure coding
practices as applicable to the particular technology
in their environment.
Application developers should be properly trained to
identify and resolve issues related to these (and
other) common coding vulnerabilities. Having staff
knowledgeable of secure coding guidelines should
minimize the number of security vulnerabilities
introduced through poor coding practices. Training
for developers may be provided in-house or by third
parties and should be applicable for technology used.
As industry-accepted secure coding practices
change, organizational coding practices and
developer training should likewise be updated to
address new threatsfor example, memory
scraping attacks.
The vulnerabilities identified in 6.5.1 through 6.5.10
provide a minimum baseline. It is up to the
organization to remain up to date with vulnerability
trends and incorporate appropriate measures into
their secure coding practices.
6.5.2 Buffer overflow Ensure that applications are not vulnerable to
buffer overflow attacks. Buffer overflows happen
when an application does not have appropriate
bounds checking on its buffer space. To exploit a
buffer overflow vulnerability, an attacker would
send an application a larger amount of
information than one of its particular buffers is
able to handle. This can cause the information in
the buffer to be pushed out of the buffers
memory space and into executable memory space.
When this occurs, the attacker has the ability to
insert malicious code at the end of the buffer and
then push that malicious code into executable
memory space by overflowing the buffer. The
malicious code is then executed and often enables
the attacker remote access to the application
and/or infected system.
6.5.3 Insecure cryptographic storage Prevent cryptographic flaws. Applications that do
not utilize strong cryptographic functions properly
to store data are at increased risk of being
compromised and exposing cardholder data. If an
attacker is able to exploit weak cryptographic
processes, they may be able to gain clear-text
access to encrypted data.
6.5.4 Insecure communications Properly encrypt all authenticated and sensitive
communications. Applications that fail to
adequately encrypt network traffic using strong
cryptography are at increased risk of being
compromised and exposing cardholder data. If an
attacker is able to exploit weak cryptographic
processes, they may be able to gain control of an
application or even gain clear-text access to
encrypted data.
6.5.5 Improper error handling Do not leak information via error messages or
other means. Applications can unintentionally leak
information about their configuration, internal
workings, or violate privacy through a variety of
application problems. Attackers use this weakness
to steal sensitive data, or conduct more serious
attacks. Also, incorrect error handling provides
information that helps a malicious individual
compromise the system. If a malicious individual
can create errors that the application does not
handle properly, they can gain detailed system
information, create denial-of- service
interruptions, cause security to fail, or crash the
server. For example, the message "incorrect
password provided" tells them the user ID
provided was accurate and that they should focus
their efforts only on the password. Use more
generic error messages, like "data could not be
verified."
6.5.6 All High vulnerabilities identified in the
vulnerability identification process (as defined in
PCI DSS Requirement 6.2).
Note: This requirement is considered a best
practice until June 30, 2012, after which it
becomes a requirement.
Any high vulnerabilities noted per Requirement
6.2 that could affect the application should be
accounted for during the development phase. For
example, a vulnerability identified in a shared
library or in the underlying operating system
should be evaluated and addressed prior to the
application being released to production.
6.5.7 Cross-site scripting (XSS) All parameters should be validated before
inclusion. XSS flaws occur whenever an application
takes user supplied data and sends it to a web
browser without first validating or encoding that
content. XSS allows attackers to execute script in
the victim's browser which can hijack user
sessions, deface web sites, possibly introduce
worms, etc.
6.5.8 Improper Access Control (such as insecure
direct object references, failure to restrict URL
access, and directory traversal)
Do not expose internal object references to users.
A direct object reference occurs when a developer
exposes a reference to an internal implementation
object, such as a file, directory, database record,
or key, as a URL or form parameter. Attackers can
manipulate those references to access other
objects without authorization.
Consistently enforce access control in
presentation layer and business logic for all URLs.
Frequently, the only way an application protects
sensitive functionality is by preventing the display
of links or URLs to unauthorized users. Attackers
can use this weakness to access and perform
unauthorized operations by accessing those URLs
directly.
Protect against directory traversal. An attacker
may be able to enumerate and navigate the
directory structure of a website thus gaining
access to unauthorized information as well as
gaining further insight into the workings of the site
for later exploitation.
6.5.9 Cross-site request forgery (CSRF) Do not reply on authorization credentials and
tokens automatically submitted by browsers. A
CSRF attack forces a logged-on victim's browser to
send a pre- authenticated request to a vulnerable
web application, which then forces the victim's
browser to perform a hostile action to the benefit
of the attacker. CSRF can be as powerful as the
web application that it attacks.
6.5.10 Broken authentication and session
management
Secure authentication and session management
prevents unauthorized individuals from
compromising legitimate account credentials,
keys, or session tokens that would otherwise
enable the intruder to assume the identity of an
authorized user.
Attacks on web-facing applications are common and
often successful, and are allowed by poor coding
practices. This requirement for reviewing
applications or installing web-application firewalls is
intended to greatly reduce the number of
compromises on public-facing web applications that
result in breaches of cardholder data.
Manual or automated vulnerability security
assessment tools or methods that review and/or
scan for application vulnerabilities can be used to
satisfy this requirement
Web-application firewalls filter and block non-
essential traffic at the application layer. Used in
conjunction with a network-based firewall, a
properly configured web-application firewall
prevents application-layer attacks if applications are
improperly coded or configured.
6.6 For public-facing web applications, address
new threats and vulnerabilities on an ongoing
basis and ensure these applications are protected
against known attacks by either of the following
methods:
- Reviewing public-facing web applications via
manual or automated application vulnerability
security assessment tools or methods, at least
annually and after any changes
- Installing a web-application firewall in front of
public-facing web applications
6.7 Ensure that security policies and operational
procedures for developing and maintaining secure
systems and applications are documented, in use,
and known to all affected parties.
Personnel need to be aware of and following
security policies and operational procedures to
ensure systems and applications are securely
developed and protected from vulnerabilities on a
continuous basis.
Attacks on web-facing applications are common and
often successful, and are allowed by poor coding
practices. This requirement for reviewing
applications or installing web-application firewalls is
intended to greatly reduce the number of
compromises on public-facing web applications that
result in breaches of cardholder data.
Manual or automated vulnerability security
assessment tools or methods that review and/or
scan for application vulnerabilities can be used to
satisfy this requirement
Web-application firewalls filter and block non-
essential traffic at the application layer. Used in
conjunction with a network-based firewall, a
properly configured web-application firewall
prevents application-layer attacks if applications are
improperly coded or configured.
6.6 For public-facing web applications, address
new threats and vulnerabilities on an ongoing
basis and ensure these applications are protected
against known attacks by either of the following
methods:
- Reviewing public-facing web applications via
manual or automated application vulnerability
security assessment tools or methods, at least
annually and after any changes
- Installing a web-application firewall in front of
public-facing web applications
Go to requirement 7 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
6.1.a For a sample of system components and related software, compare the list of
security patches installed on each system to the most recent vendor security patch list,
to verify that current vendor patches are installed.
6.1.b Examine policies related to security patch installation to verify they require
installation of all critical new security patches within one month.
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
C3.7
C4.1.1
Major observations from the 2014 Verizon PCI Compliance Report:
-The three most-often complied-with subcontrols were all met by at least three-quarters of the organizations we analyzed.
6.5.b [Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques] is relatively simple to comply with, given the wealth of resources in secure coding available from major vendors such as Microsoft and Oracle.
Subcontrols 6.4.4 and 6.3.1 govern the process of moving a system into production; specifying that test data, accounts and user IDs are removed before the system goes live a one-off activity thats relatively easy to incorporate into launch processes.
-The least-often complied-with subcontrols tended to be those related to the much more problematic areas of identifying and managing vulnerabilities and the associated changes on an ongoing basis. For example, 6.1.a (renumbered 6.2 in DSS 3.0) demands that systems and software are verified to have the
latest vendor security patches installed. This subcontrol ranked among our Bottom 20, with only 49.5% compliance.
-Patch management and associated vulnerability management processes represent the biggest problem areas, because theyre rarely well documented and automated.
-6.4Change-management is also of significant problems specifically relating to documentation and verification of changes. Change-management features, such as functionality testing and change impact assessment documentation, were not in place in about half of the organizations assessed.
C4.5 6.2.a Interview responsible personnel to verify that processes are implemented to
identify new security vulnerabilities, and that a risk ranking is assigned to such
vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be
ranked as High.)
6.2.b Verify that processes to identify new security vulnerabilities include using outside
sources for security vulnerability information.
6.3.a Obtain and examine written software development processes to verify that the
processes are based on industry standards and/or best practices.
6.3.b Examine written software development processes to verify that information
security is included throughout the life cycle.
6.3.c Examine written software development processes to verify that software
applications are developed in accordance with PCI DSS.
6.3.d From an examination of written software development processes, and interviews
of software developers, verify that:
C6.6
C19.4
C3.3 6.3.1 Custom application accounts, user IDs and/or passwords are removed before
system goes into production or is released to customers.
6.3.2.a Examine written software-development procedures and interview responsible
personnel to verify that all custom application code changes must be reviewed (using
either manual or automated processes) as follows:
- Code changes are reviewed by individuals other than the originating code author,
and by individuals who are knowledgeable in code-review techniques and secure
coding practices.
- Code reviews ensure code is developed according to secure coding guidelines (see
PCI DSS Requirement 6.5).
- Appropriate corrections are implemented prior to release.
- Code-review results are reviewed and approved by management prior to release.
C6.3
6.3.2.b Select a sample of recent custom application changes and verify that custom
application code is reviewed according to 6.3.2.a, above.
Identify the documented policies and procedures examined to verify that the following
are defined:
access control in place to enforce separation.
environments and those assigned to the production environment.
modifications are documented.
6.4.1.a Examine network documentation and network device configurations to verify
that the development/test environments are separate from the production
environment(s)
6.4.1.b Examine access controls settings to verify that access controls are in place to
enforce separation between the development/test environments and the production
environment(s).

C20.7
C6.3
NC 6.4.2 There is a separation of duties between personnel assigned to the
development/test environments and those assigned to the production environment.
6.4.3.a Observe testing processes and interview personnel to verify procedures are in
place to ensure production data (live PANs) are not used for testing or development.
6.4.3.b Examine a sample of test data to verify production data (live PANs) is not used
for testing or development.
NC
NC 6.4.4.a Observe testing processes and interview personnel to verify test data and
accounts are removed before a production system becomes active.
6.4.4.b Examine a sample of data and accounts from production systems recently
installed or updated to verify test data and accounts are removed before the system
becomes active.
NC 6.4.5.a Verify that change-control procedures related to implementing security
patches and software modifications are documented and require items 6.4.5.1
6.4.5.4 below.
6.4.5.b For a sample of system components and recent changes/security patches,
trace those changes back to related change control documentation. For each change
examined, perform the following:
NC 6.4.5.1 Verify that documentation of impact is included in the change control
documentation for each sampled change.
NC 6.4.5.2 Verify that documented approval by authorized parties is present for each
sampled change.
C6.3 6.4.5.3.a For each sampled change, verify that functionality testing is performed to
verify that the change does not adversely impact the security of the system.
6.4.5.3.b For custom code changes, verify that all updates are tested for compliance
with PCI DSS Requirement 6.5 before being deployed into production.
NC 6.4.5.4 Verify that back-out procedures are prepared for each sampled change.
6.5.a Examine software-development policies and procedures to verify that training in
secure coding techniques is required for developers, based on industry best practices
and guidance.
6.5.b Interview a sample of developers and obtain evidence that they are
knowledgeable in secure coding techniques.
C6.7
6.5.c Examine records of training to verify that software developers received training
on secure coding techniques, including how to avoid common coding vulnerabilities,
and understanding how sensitive data is handled in memory.
6.5.d. Verify that processes are in place to protect applications from, at a minimum,
the following vulnerabilities:
C6.1 6.5.1 Injection flaws, particularly SQL injection. (Validate input to verify user data
cannot modify meaning of commands and queries, utilize parameterized queries, etc.)
C6.7
NC 6.5.2 Buffer overflow (Validate buffer boundaries and truncate input strings.)
NC 6.5.3 Insecure cryptographic storage (Prevent cryptographic flaws)
6.5.4 Insecure communications (Properly encrypt all authenticated and sensitive
communications)
NC 6.5.5 Improper error handling (Do not leak information via error messages)
NA 6.5.6 All High vulnerabilities as identified in PCI DSS Requirement 6.2.
C6.1 6.5.7 Cross-site scripting (XSS) (Validate all parameters before inclusion, utilize
context-sensitive escaping, etc.)
NC 6.5.8 Improper Access Control, such as insecure direct object references, failure to
restrict URL access, and directory traversal (Properly authenticate users and sanitize
input. Do not expose internal object references to users.)
C6.1 6.5.9 Cross-site request forgery (CSRF). (Do not reply on authorization credentials and
tokens automatically submitted by browsers.)
6.5.10 Examine software development policies and procedures and interview
responsible personnel to verify that broken authentication and session management
are addressed via coding techniques that commonly include:
-Flagging session tokens (for example cookies) as secure
-Not exposing session IDs in the URL
-Incorporating appropriate time-outs and rotation of session IDs after a successful
login.
6.6 For public-facing web applications, ensure that either one of the following methods
are in place as follows:
- Verify that public-facing web applications are reviewed (using either manual or
automated vulnerability security assessment tools or methods), as follows:
- At least annually
- After any changes
- By an organization that specializes in application security
- That all vulnerabilities are corrected
- That the application is re-evaluated after the corrections
- Verify that a web-application firewall is in place in front of public-facing web
applications to detect and prevent web-based attacks.
Note: An organization that specializes in application security can be either a third-
party company or an internal organization, as long as the reviewers specialize in
application security and can demonstrate independence from the development team.
C13.12
C6.1
C6.3
C11.6
6.7 Examine documentation and interview personnel to verify that security policies and
operational procedures for developing and maintaining secure systems and
applications are:
-Documented,
-In use, and
-Known to all affected parties.
6.6 For public-facing web applications, ensure that either one of the following methods
are in place as follows:
- Verify that public-facing web applications are reviewed (using either manual or
automated vulnerability security assessment tools or methods), as follows:
- At least annually
- After any changes
- By an organization that specializes in application security
- That all vulnerabilities are corrected
- That the application is re-evaluated after the corrections
- Verify that a web-application firewall is in place in front of public-facing web
applications to detect and prevent web-based attacks.
Note: An organization that specializes in application security can be either a third-
party company or an internal organization, as long as the reviewers specialize in
application security and can demonstrate independence from the development team.
C13.12
C6.1
C6.3
C11.6
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A
Identify the documented policies and procedures examined to confirm that processes
are defined:
risk and critical vulnerabilities.
<Report Findings Here>
3
0
Identify the responsible personnel interviewed who confirm that:
risk and critical vulnerabilities.
sources for security vulnerability information.
<Report Findings Here>
Describe the processes observed to verify that:

New security vulnerabilities are identified.


A risk ranking is assigned to vulnerabilities to include identification of all high risk
and critical vulnerabilities.
Processes to identify new security vulnerabilities include using reputable outside
sources for security vulnerability information.
Identify the outside sources used.
<Report Findings Here>
3
0
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
Major observations from the 2014 Verizon PCI Compliance Report:
-The three most-often complied-with subcontrols were all met by at least three-quarters of the organizations we analyzed.
6.5.b [Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques] is relatively simple to comply with, given the wealth of resources in secure coding available from major vendors such as Microsoft and Oracle.
Subcontrols 6.4.4 and 6.3.1 govern the process of moving a system into production; specifying that test data, accounts and user IDs are removed before the system goes live a one-off activity thats relatively easy to incorporate into launch processes.
-The least-often complied-with subcontrols tended to be those related to the much more problematic areas of identifying and managing vulnerabilities and the associated changes on an ongoing basis. For example, 6.1.a (renumbered 6.2 in DSS 3.0) demands that systems and software are verified to have the
latest vendor security patches installed. This subcontrol ranked among our Bottom 20, with only 49.5% compliance.
-Patch management and associated vulnerability management processes represent the biggest problem areas, because theyre rarely well documented and automated.
-6.4Change-management is also of significant problems specifically relating to documentation and verification of changes. Change-management features, such as functionality testing and change impact assessment documentation, were not in place in about half of the organizations assessed.
Selected Merchant Types
Identify the documented policies and procedures related to security-patch
installation examined to verify processes are defined for:
month of release.
time frame.
<Report Findings Here>
3
0
Identify the sample of system components and related software selected for this
testing procedure.
<Report Findings Here>
Identify the vendor security patch list reviewed.
<Report Findings Here>
For each item in the sample, describe how the list of security patches installed on
each system was compared to the most recent vendor security-patch list to verify
that:
Applicable critical vendor-supplied security patches are installed within one month of
release.
All applicable vendor-supplied security patches are installed within an appropriate
time frame.
<Report Findings Here>
3
0
Identify the document that defines software development processes based on
industry standards and/or best practices.
<Report Findings Here>
Identify the industry standards and/or best practices used.
<Report Findings Here>
3
0
Identify the documented software development processes examined to verify that
information security is included throughout the life cycle.
<Report Findings Here>
3
0
Identify the documented software development processes examined to verify that
software applications are developed in accordance with PCI DSS.
<Report Findings Here>
3
0
Identify the software developers interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed to verify that written
software development processes are implemented.
<Report Findings Here>
3
0
Identify the documented software-development processes examined to verify
processes define that pre-production and/or custom application accounts, user IDs
and/or passwords are removed before an application goes into production or is
released to customers.
<Report Findings Here>
Identify the responsible personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed to confirm that pre-
production and/or custom application accounts, user IDs and/or passwords are
removed before an application goes into production or is released to customers.
<Report Findings Here>
3
0
Identify the documented software-development processes examined to verify
processes define that all custom application code changes must be reviewed (using
either manual or automated processes) as follows:
and by individuals who are knowledgeable in code review techniques and secure
coding practices.
PCI DSS Requirement 6.5).
<Report Findings Here>
Identify the responsible personnel interviewed for this testing procedure who
confirm that all custom application code changes are reviewed as follows:
and by individuals who are knowledgeable in code-review techniques and secure
coding practices.
PCI DSS Requirement 6.5).
Describe how all custom application code changes must be reviewed, including
whether processes are manual or automated.
<Report Findings Here>
3
0
Identify the sample of recent custom application changes selected for this testing
procedure.
<Report Findings Here>
For each item in the sample, describe how code review processes were observed to
verify custom application code is reviewed as follows:
Code changes are reviewed by individuals other than the originating code author.
<Report Findings Here>
Code changes are reviewed by individuals who are knowledgeable in code-review
techniques and secure coding practices.
<Report Findings Here>
Code reviews ensure code is developed according to secure coding guidelines (see PCI
DSS Requirement 6.5).
<Report Findings Here>
Appropriate corrections are implemented prior to release.
<Report Findings Here>
Code-review results are reviewed and approved by management prior to release.
<Report Findings Here>
3
0
Left blank by PCIco
3
0
Identify the network documentation that illustrates that the development/test
environments are separate from the production environment(s).
<Report Findings Here>
Describe how network device configurations were examined to verify that the
development/test environments are separate from the production environment(s).
<Report Findings Here>
3
0
Identify the access control settings examined for this testing procedure.
<Report Findings Here>
Describe how the access control settings were examined to verify that access controls
are in place to enforce separation between the development/test environments and
the production environment(s).
<Report Findings Here>
3
0
Identify the personnel assigned to development/test environments interviewed who
confirm that separation of duties is in place between development/test
environments and the production environment.
<Report Findings Here>
Identify the personnel assigned to production environments interviewed who confirm
that separation of duties is in place between development/test environments and the
production environment.
<Report Findings Here>
Describe how processes were observed to verify that separation of duties is in place
between development/test environments and the production environment.
<Report Findings Here>
3
0
Identify the personnel interviewed who confirm that procedures are in place to
ensure production data (live PANs) are not used for testing or development.
<Report Findings Here>
Describe how testing processes were observed to verify procedures are in place to
ensure production data (live PANs) are not used for testing.
<Report Findings Here>
Describe how testing processes were observed to verify procedures are in place to
ensure production data (live PANs) are not used for development.
<Report Findings Here>
3
0
Describe how a sample of test data was examined to verify production data (live
PANs) is not used for testing.
<Report Findings Here>
Describe how a sample of test data was examined to verify production data (live
PANs) is not used for development.
<Report Findings Here>.
3
0
Identify the personnel interviewed who confirm that test data and accounts are
removed before a production system becomes active.
<Report Findings Here>
Describe how testing processes were observed to verify that test data is removed
before a production system becomes active.
<Report Findings Here>
Describe how testing processes were observed to verify that test accounts are
removed before a production system becomes active.
<Report Findings Here>
3
0
Describe how a sample of test data from production systems recently installed or
updated was examined to verify test data is removed before the system becomes
active.
<Report Findings Here>
Describe how a sample of test accounts from production systems recently installed or
updated was examined to verify test accounts are removed before the system
becomes active.
<Report Findings Here>
3
0
Identify the documented change-control procedures related to implementing security
patches and software modification examined to verify procedures are defined for:
authorized parties.
security of the system.
<Report Findings Here>
6
0
Identify the sample of system components selected.
<Report Findings Here>
Identify the responsible personnel interviewed to determine recent changes/security
patches.
<Report Findings Here>
For each item in the sample, identify the sample of changes and the related change
control documentation selected for this testing procedure (through 6.4.5.4)
<Report Findings Here>
6
0
For each change from 6.4.5.b, describe how the changes were traced back to the
identified related change control documentation to verify that documentation of
impact is included in the change control documentation for each sampled change.
<Report Findings Here>
6
0
For each change from 6.4.5.b, describe how the changes were traced back to the
identified related change control documentation to verify that documented approval
by authorized parties is present in the change control documentation for each
sampled change.
<Report Findings Here>
6
0
For each change from 6.4.5.b, describe how the changes were traced back to the
identified related change control documentation to verify that the change control
documentation for each sampled change includes evidence that functionality testing
is performed to verify that the change does not adversely impact the security of the
system.
<Report Findings Here>
6
0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, identify the sample of custom code changes and the
related change control documentation selected for this testing procedure.
<Report Findings Here>
Describe how the custom code changes were traced back to the identified related
change control documentation to verify that the change control documentation for
each sampled custom code change includes evidence that all updates are tested for
compliance with PCI DSS Requirement 6.5 before being deployed into production.
<Report Findings Here>
6
0
For each change from 6.4.5.b, describe how the changes were traced back to the
identified related change control documentation to verify that back-out procedures
are prepared for each sampled change and present in the change control
documentation for each sampled change.
<Report Findings Here>
6
0
Identify the document requiring that developers are trained in secure coding
<Report Findings Here>
Identify the industry best practices and guidance that training is based on.
<Report Findings Here>
3
0
Identify the sample of developers interviewed.
<Report Findings Here>
For the interview, summarize the relevant details discussed to verify that they are
knowledgeable in secure coding techniques.
<Report Findings Here>
3
0
Identify the records of training that were examined to verify that software developers
received training on secure coding techniques, including how to avoid common
coding vulnerabilities, and understanding how sensitive data is handled in memory.
<Report Findings Here>
3
0
Identify the software-development policies and procedures examined to verify that
processes are in place to protect applications from, at a minimum, the following
vulnerabilities:
<Report Findings Here>
Identify the responsible personnel interviewed to verify that processes are in place to
protect applications from, at a minimum, the following vulnerabilities:
<Report Findings Here>
3
0
IFor the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that injection flaws are addressed by coding techniques that include:
Validating input to verify user data cannot modify meaning of commands and queries.
Utilizing parameterized queries.
<Report Findings Here>
3
0
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that buffer overflows are addressed by coding techniques that
include:
Validating buffer boundaries.
Truncating input strings.
<Report Findings Here>
3
0
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that insecure cryptographic storage is addressed by coding
techniques that:
Prevent cryptographic flaws.
Use strong cryptographic algorithms and keys.
<Report Findings Here>
3
0
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that insecure communications are addressed by coding techniques
that properly:
Authenticate all sensitive communications.
Encrypt all sensitive communications.
<Report Findings Here>
3
0
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that improper error handling is addressed by coding techniques that
do not leak information via error messages.
<Report Findings Here>
3
0
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that applications are not vulnerable to High vulnerabilities, as
identified in PCI DSS Requirement 6.1.
<Report Findings Here>
3
0
Identify whether web applications and application interfaces are present. (yes/no)
<Report Findings Here>
If no, mark the below 6.5.8-6.5.11 as Not Applicable.
If yes, complete the following:
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that cross-site scripting (XSS) is addressed by coding techniques that
include:
Validating all parameters before inclusion.
Utilizing context-sensitive escaping.
<Report Findings Here>
3
0
Identify whether web applications and application interfaces are present. (yes/no)
<Report Findings Here>
If no, mark the below 6.5.8-6.5.11 as Not Applicable.
If yes, complete the following:
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that improper access control is addressed by coding techniques that
include:
Proper authentication of users.
Sanitizing input.
Not exposing internal object references to users.
User interfaces that do not permit access to unauthorized functions.
<Report Findings Here>
3
0
Identify whether web applications and application interfaces are present. (yes/no)
<Report Findings Here>
If no, mark the below 6.5.8-6.5.11 as Not Applicable.
If yes, complete the following:
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that cross-site request forgery (CSRF) is addressed by coding
techniques that ensure applications do not rely on authorization credentials and
tokens automatically submitted by browsers.
<Report Findings Here>
3
0
Identify whether web applications and application interfaces are present. (yes/no)
<Report Findings Here>
If no, mark the below 6.5.8-6.5.11 as Not Applicable.
If yes, complete the following:
Indicate whether this ROC is being completed prior to June 30, 2015. (yes/no)
<Report Findings Here>
If yes AND the assessed entity does not have this in place ahead of the
requirements effective date, mark the remainder of 6.5.10 as Not Applicable.
If no OR if the assessed entity has this in place ahead of the requirements effective
date, complete the following:
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that broken authentication and session management are addressed
via coding techniques that protect credentials and session IDs, including:
Flagging session tokens (for example cookies) as secure.
Not exposing session IDs in the URL.
Implementing appropriate time-outs and rotation of session IDs after a successful
login
<Report Findings Here>
3
0
For each public-facing web application, identify which of the two methods are
implemented:
web application firewalls.
<Report Findings Here>
If application vulnerability security assessments are indicated above:
Describe the tools and/or methods used (manual or automated, or a combination of
both).
Identify the organization(s) confirmed to specialize in application security that is
performing the assessments.
<Report Findings Here>
Identify the documented processes that were examined to verify that public-facing
web applications are reviewed using the tools and/or methods indicated above, as
follows:
assessment.
<Report Findings Here>
Identify the responsible personnel interviewed who confirm that public-facing web
applications are reviewed, as follows:
3
0
Identify the records of application security assessments examined for this testing
procedure.
<Report Findings Here>
Describe how the records of application security assessments were examined to
verify that public-facing web applications are reviewed as follows:
At least annually.
assessment.
<Report Findings Here>
If an automated technical solution that detects and prevents web-based attacks (for
example, a web-application firewall) is indicated above:
Describe the automated technical solution in use that detects and prevents web-
based attacks.
Identify the responsible personnel interviewed who confirm that the above
automated technical solution in use to detect and prevent web-based attacks is in
place as follows:
based attacks.
<Report Findings Here>
Identify the document reviewed to verify that security policies and operational
procedures for developing and maintaining secure systems and applications are
documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for developing and maintaining secure
systems and applications are:
<Report Findings Here>
6
0
150 0
3
0
A-EP PE2P B B-IP C-VT C D S In Place? Severity
1 0 0 1 1 1 1 1
N 4
1 0 0 1 1 1 1 1
N 4
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
Selected Merchant Types D
1 0 0 1 1 1 1 1
N 4
1 0 0 1 1 1 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
1 0 0 0 0 0 1 1
N 1
0 0 0 0 0 0 1 1
N 1
1 0 0 0 0 0 1 1
N 1
1 0 0 0 0 0 1 1
N 1
1 0 0 0 0 0 1 1
N 1
1 0 0 0 0 0 1 1
N 1
1 0 0 0 0 0 1 1
N 1
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
1 0 0 0 0 0 1 1
N 4
1 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
0 0 0 0 0 0 1 1
N 4
1 0 0 0 0 0 1 1
N 4
1 0 0 0 0 0 1 1
N 4
1 0 0 0 0 0 1 1
N 4
1 0 0 0 0 0 1 1
N 4
0 1 1 0 0 0 0 1
N 4
0 0 0 0 0 0 1 1
Y 0
17 0 0 4 4 4 42 42 Y 143
N
C
NA
NT
0 1 1 0 0 0 0 1
N 4
Proofs /
Documentation links
Stage of implementation Remediation plan
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
Estimated date for completion Comments Owner
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
Return to Table of content Go to Req 6
PCI DSS Requirement Guidance
7.1Limit access to system components and
cardholder data to only those individuals whose job
requires such access. Access limitations must include
the following:
The more people who have access to cardholder
data, the more risk there is that a users account will
be used maliciously. Limiting access to those with a
legitimate business reason for the access helps an
organization prevent mishandling of cardholder data
through inexperience or malice.
7.1.1 Define access needs for each role, including:
System components and data resources that each
role needs to access for their job function
Level of privilege required (for example, user,
administrator, etc.) for accessing resources.
In order to limit access to cardholder data to only
those individuals who need such access, first it is
necessary to define access needs for each role (for
example, system administrator, call center
personnel, store clerk), the systems/devices/data
each role needs access to, and the level of privilege
each role needs to effectively perform assigned
tasks. Once roles and corresponding access needs
are defined, individuals can be granted access
accordingly.
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
7.1.2 Restrict access to privileged user IDs to least
privileges necessary to perform job responsibilities.
When assigning privileged IDs, it is important to
assign individuals only the privileges they need to
perform their job (the least privileges). For
example, the database administrator or backup
administrator should not be assigned the same
privileges as the overall systems administrator.
Major Observations 2014 Verizon PCI Compliance Report:
-The subcontrols most-often complied with cover technical considerations: the implementation of automated access-control systems (7.1.4) to cover all system components (7.2.1), with deny all set by default (7.2.3).
-More than 80% of organizations were compliant with each of these subcontrols.
-The subcontrols least-often complied with showed that organizations are struggling with role-based access controls and defining least privilege:
-Only73.3% of organizations met control 7.1.2,which requires that privileges are assigned to individuals based on job classification and function.
-Just 68.3% of companies complied with7.1.1,which requires that access rights for privileged user IDs are restricted to the least privileges necessary to perform job responsibilities.
-A mere 65.3% of companies were compliant with7.2.2,which requires that access-control systems are configured to enforce privileges assigned to individuals based on job classification and function.
7.1.3 Assign access based on individual personnels
job classification and function.
Once needs are defined for user roles (per PCI DSS
requirement 7.1.1), it is easy to grant individuals
access according to their job classification and
function by using the already-created roles.
7.1.4 Require documented approval by authorized
parties specifying required privileges.
Documented approval (for example, in writing or
electronically) assures that those with access and
privileges are known and authorized by
management, and that their access is necessary for
their job function.
7.2 Establish an access control system for systems
components with multiple users that restricts access
based on a users need to know, and is set to deny
all unless specifically allowed.
This access control system must include the
following:
7.2.1 Coverage of all system components
Without a mechanism to restrict access based on
users need to know, a user may unknowingly be
granted access to cardholder data. Use of an
automated access control system or mechanism is
essential to manage multiple users. This system
should be established in accordance with your
organizations access control policy and processes
(including need to know and role-based access
control), should manage access to all system
components, and should have a default deny-all
setting to ensure no one is granted access until and
unless a rule is established specifically granting such
access.
7.1.2 Restrict access to privileged user IDs to least
privileges necessary to perform job responsibilities.
When assigning privileged IDs, it is important to
assign individuals only the privileges they need to
perform their job (the least privileges). For
example, the database administrator or backup
administrator should not be assigned the same
privileges as the overall systems administrator.
7.2.2 Assignment of privileges to individuals based
on job classification and function
7.2.3 Default deny-all setting
Note: Some access control systems are set by
default to allow-all, thereby permitting access
unless/until a rule is written to specifically deny it.
7.3 Ensure that security policies and operational
procedures for restricting access to cardholder
data are documented, in use, and known to all
affected parties.
Without a mechanism to restrict access based on
users need to know, a user may unknowingly be
granted access to cardholder data. Use of an
automated access control system or mechanism is
essential to manage multiple users. This system
should be established in accordance with your
organizations access control policy and processes
(including need to know and role-based access
control), should manage access to all system
components, and should have a default deny-all
setting to ensure no one is granted access until and
unless a rule is established specifically granting such
access.
Go to Req 8 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
C12.1.1 7.1.a Examine written policy for access control, and verify that the policy incorporates
7.1.1 through 7.1.4 as follows:
- Defining access needs and privilege assignments for each role
- Restriction of access to privileged user IDs to least privileges
necessary to perform job responsibilities
- Assignment of access based on individual personnels job
classification and function
- Documented approval (electronically or in writing) by
authorized parties for all access, including listing of specific privileges approved.
7.1.1 Select a sample of roles and verify access needs for each role are defined and
include:
System components and data resources that each role needs to access for their job
function
Identification of privilege necessary for each role to perform their job function.
7.1.2.a Interview personnel responsible for assigning access to verify that access to
privileged user IDs is:
-Assigned only to roles that specifically require such privileged access
-Restricted to least privileges necessary to perform job responsibilities.
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
C12.6
C12.7
Major Observations 2014 Verizon PCI Compliance Report:
-The subcontrols most-often complied with cover technical considerations: the implementation of automated access-control systems (7.1.4) to cover all system components (7.2.1), with deny all set by default (7.2.3).
-More than 80% of organizations were compliant with each of these subcontrols.
-The subcontrols least-often complied with showed that organizations are struggling with role-based access controls and defining least privilege:
-Only73.3% of organizations met control 7.1.2,which requires that privileges are assigned to individuals based on job classification and function.
-Just 68.3% of companies complied with7.1.1,which requires that access rights for privileged user IDs are restricted to the least privileges necessary to perform job responsibilities.
-A mere 65.3% of companies were compliant with7.2.2,which requires that access-control systems are configured to enforce privileges assigned to individuals based on job classification and function.
7.1.2.b Select a sample of user IDs with privileged access and interview responsible
management personnel to verify that privileges assigned are:
Necessary for that individuals job function
Restricted to least privileges necessary to perform job responsibilities.
NC 7.1.3 Select a sample of user IDs and interview responsible management personnel to
verify that privileges assigned are based on that individuals job classification and
function.
NC 7.1.4 Select a sample of user IDs and compare with documented approvals to verify
that:
- Documented approval exists for the assigned privileges
- The approval was by authorized parties
-That specified privileges match the roles assigned to the individual.
C12.14
C15.3
7.2 Examine system settings and vendor documentation to verify that an access control
system is implemented as follows:
NC 7.2.1 Confirm that access control systems are in place on all system components.
C12.6
C12.7
C12.14 7.2.2 Confirm that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.
NC 7.2.3 Confirm that the access control systems have a default deny-all setting.
7.3 Examine documentation interview personnel to verify that security policies and
operational procedures for restricting access to cardholder data are:
Documented,
In use, and
Known to all affected parties.
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A
Identify the written policy for access control that was examined to verify the policy
incorporates 7.1.1 through 7.1.4 as follows:
job responsibilities.
access, including listing of specific privileges approved.
<Report Findings Here>
4 0
Identify the selected sample of roles for this testing procedure.
<Report Findings Here>
For each role in the selected sample, describe how the role was examined to verify
access needs for each role are defined and include:
<Report Findings Here>
System components and data resources that each role needs to access for their job
function.
<Report Findings Here>
Identification of privilege necessary for each role to perform their job function.
<Report Findings Here>
4 0
Identify the responsible personnel interviewed who confirm that access to privileged
user IDs is:
<Report Findings Here>
4 0
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Major Observations 2014 Verizon PCI Compliance Report:
-The subcontrols most-often complied with cover technical considerations: the implementation of automated access-control systems (7.1.4) to cover all system components (7.2.1), with deny all set by default (7.2.3).
-More than 80% of organizations were compliant with each of these subcontrols.
-The subcontrols least-often complied with showed that organizations are struggling with role-based access controls and defining least privilege:
-Only73.3% of organizations met control 7.1.2,which requires that privileges are assigned to individuals based on job classification and function.
-Just 68.3% of companies complied with7.1.1,which requires that access rights for privileged user IDs are restricted to the least privileges necessary to perform job responsibilities.
-A mere 65.3% of companies were compliant with7.2.2,which requires that access-control systems are configured to enforce privileges assigned to individuals based on job classification and function.
Selected Merchant Type
Identify the sample of user IDs with privileged access selected for this testing
procedure.
<Report Findings Here>
Identify the responsible management personnel interviewed to confirm that
privileges assigned are:
<Report Findings Here>
For the interview, summarize the relevant details discussed to confirm that privileges
assigned to each user ID in the selected sample are:
Necessary for that individuals job function.
Restricted to least privileges necessary to perform job responsibilities.
<Report Findings Here>
4 0
Identify the sample of user IDs examined for this testing procedure.
<Report Findings Here>
Identify the responsible management personnel interviewed who confirm that
privileges assigned are based on that individuals job classification and function.
<Report Findings Here>
For the interview, summarize the relevant details discussed to confirm that privileges
assigned to each user ID in the selected sample are based on an individuals job
classification and function.
<Report Findings Here>
4 0
Identify the sample of user IDs examined for this testing procedure.
<Report Findings Here>
Describe how each item in the sample of user IDs was compared with documented
approvals to verify that:
Documented approval exists for the assigned privileges.
<Report Findings Here>
The approval was by authorized parties.
<Report Findings Here>
That specified privileges match the roles assigned to the individual.
<Report Findings Here>
4 0
Left blank by PCIco 4 0
Identify vendor documentation examined.
<Report Findings Here>
Describe how system settings were examined with the vendor documentation to
verify that access control systems are in place on all system components.
<Report Findings Here>
4 0
Describe how system settings were examined with the vendor documentation at
7.2.1 to verify that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.
<Report Findings Here>
4 0
Describe how system settings were examined with vendor documentation at 7.2.1 to
verify that access control systems have a default deny-all setting.
<Report Findings Here>
4 0
Identify the document reviewed to verify that security policies and operational
procedures for restricting access to cardholder data are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for restricting access to cardholder data
are:
<Report Findings Here>
6
0
46 0
A-EP PE2P B B-IP C-VT C D S In place Severity Proofs /
Documentation links
0 0 1 1 1 1 1 1 NT 3
0 0 0 0 0 1 1 1 Y 0
1 0 1 1 1 1 1 1 C 0
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Selected Merchant Type D
1 0 1 1 1 1 1 1 C 0
1 0 1 1 1 1 1 1 C 0
0 0 0 0 0 0 1 1 N 3
0 0 0 0 0 0 1 1 C 0
0 0 0 0 0 0 1 1 C 0
0 0 0 0 0 0 1 1 C 0
0 0 0 0 0 0 1 1 C 0
0 0 0 0 0 0 1 1 N 1
3 0 4 4 4 5 11 11 Y 7
N
C
NA
NT
Stage of implementation Remediation plan
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Estimated date for completion Comments Owner
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Return to Table of content Go to Req 7
PCI DSS Requirement Guidance
8.1.1 Assign all users a unique ID before allowing
them to access system components or cardholder
data.
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
By ensuring each user is uniquely identified
instead of using one ID for several
employeesan organization can maintain
individual responsibility for actions and an
effective audit trail per employee. This will help
speed issue resolution and containment when
misuse or malicious intent occurs.
8.1 Define and implement policies and
procedures to ensure proper user identification
management for non- consumer users and
administrators on all system components as
follows:
Major Observations from the 2014 Verizon PCI Compliance report:
-According to our RISK teams assessments, only 24.2% of organizations that suffered a security breach were compliant with Requirement 8 at the time of their breach.
-Average compliance with Requirement 8: 84,1%
-Seven of the subcontrols (8.5.10.b, 8.5.12.b, 8.5.13.b, 8.5.9.b, 8.4.b, 8.5.11.b, 8.5.7) are met with over 90% compliance.
-But a mere 57.4% of organizations complied with 8.5.1, which governs the addition, deletion, and modification of IDs and credentials.
-62.4% of organizations complied with 8.5.15, which specifies that idle sessions expire after no more than 15 minutes
-62.4% of organizations complied with 8.5.13.a, which requires that users are locked out after no more than six failed login attempts
-55.4% complied with both (8.5.15 and 8.5.13.a ), 13.9% with just one, and 30.7% with neither.
8.1.2 Control addition, deletion, and modification of
user IDs, credentials, and other identifier objects.
To ensure users added to your systems are all valid
and recognized users, the addition, deletion, and
modification of user IDs should be managed and
controlled by a small group with specific authority.
The ability to manage these user IDs should be
limited to only this small group.
If an employee has left the company, and still has
access to the network via their user account,
unnecessary or malicious access to cardholder data
could occur. This access could happen from the
former employee or from a malicious user who
exploits the older and/or unused account. Consider
implementing a process with Human Resources for
immediate notification when an employee is
terminated so that the user account can be quickly
deactivated.
8.1.5 Manage IDs used by vendors to access,
support, or maintain system components via remote
access as follows:
- Enabled only during the time period needed and
disabled when not in use.
- Monitored when in use.
8.1.4 Remove/disable inactive user accounts at least
every 90 days.
Allowing vendors to have 24/7 access into your
network in case they need to support your systems
increases the chances of unauthorized access, either
from a user in the vendors environment or from a
malicious individual who finds and uses this always-
available external entry point into your network.
Enabling access only for the time periods needed,
and disabling it as soon as it is no longer needed,
helps prevent misuse of these connections.
Monitoring of vendor access provides assurance that
vendors are accessing only the systems necessary
and only during approved time frames.
Existence of inactive accounts allows an
unauthorized user exploit the unused account to
potentially access cardholder data.
8.1.3 Immediately revoke access for any terminated
users.
8.1.7 Set the lockout duration to a minimum of 30
minutes or until administrator enables the user ID.
If an account is locked out due to someone
continually trying to guess a password, controls to
delay reactivation of these locked accounts stops
the malicious individual from continually guessing
the password (they will have to stop for a minimum
of 30 minutes until the account is reactivated).
Additionally, if reactivation must be requested, the
admin or help desk can validate that the account
owner is the cause (from typing errors) of the
lockout.
8.1.8 If a session has been idle for more than 15
minutes, require the user to re-authenticate to re-
activate the terminal or session.
When users walk away from an open machine with
access to critical network or cardholder data, that
machine may be used by others in the users
absence, resulting in unauthorized account access
and/or account misuse.
8.1.5 Manage IDs used by vendors to access,
support, or maintain system components via remote
access as follows:
- Enabled only during the time period needed and
disabled when not in use.
- Monitored when in use.
8.1.6 Limit repeated access attempts by locking out
the user ID after not more than six attempts.
Without account-lockout mechanisms in place, an
attacker can continually attempt to guess a
password through manual or automated tools (for
example, password cracking), until they achieve
success and gain access to a users account.
Allowing vendors to have 24/7 access into your
network in case they need to support your systems
increases the chances of unauthorized access, either
from a user in the vendors environment or from a
malicious individual who finds and uses this always-
available external entry point into your network.
Enabling access only for the time periods needed,
and disabling it as soon as it is no longer needed,
helps prevent misuse of these connections.
Monitoring of vendor access provides assurance that
vendors are accessing only the systems necessary
and only during approved time frames.
8.2 In addition to assigning a unique ID, ensure
proper user-authentication management for non-
consumer users and administrators on all system
components by employing at least one of the
following methods to authenticate all users:
-Something you know, such as a password or
passphrase
-Something you have, such as a token device or
smart card
-Something you are, such as a biometric.
These authentication methods, when used in
addition to unique IDs, help protect users IDs from
being compromised, since the one attempting the
compromise needs to know both the unique ID and
the password (or other authentication used). Note
that a digital certificate is a valid option for
something you have as long as it is unique for a
particular user.
Since one of the first steps a malicious individual will
take to compromise a system is to exploit weak or
nonexistent passwords, it is important to implement
good processes for authentication management.
Many network devices and applications transmit the
user ID and unencrypted password across the
network and/or also store the passwords without
encryption. A malicious individual can easily
intercept the unencrypted or readable user ID and
password during transmission using a sniffer, or
directly access the user IDs and unencrypted
passwords in files where they are stored, and use
this stolen data to gain unauthorized access. During
transmission, the user credentials can be encrypted
or the tunnel can be encrypted
8.2.1 Using strong cryptography, render all
authentication credentials (such as
passwords/phrases) unreadable during
transmission and storage on all system
components.
8.2.2 Verify user identity before modifying any
authentication credentialfor example,
performing password resets, provisioning new
tokens, or generating new keys.
Many malicious individuals use "social
engineeringfor example, calling a help desk and
acting as a legitimate userto have a password
changed so they can utilize a user ID. Consider use of
a secret question that only the proper user can
answer to help administrators identify the user prior
to re-setting passwords. Ensure such questions are
secured properly and not shared.
Strong passwords/phrases are the first line of
defense into a network since a malicious individual
will often first try to find accounts with weak or non-
existent passwords. If passwords are short or simple
to guess, it is relatively easy for a malicious
individual to find these weak accounts and
compromise a network under the guise of a valid
user ID.
This requirement specifies that a minimum of seven
characters and both numeric and alphabetic
characters should be used for passwords/phrases.
For cases where this minimum cannot be met due to
technical limitations, entities can use equivalent
strength to evaluate their alternative. NIST SP 800-
63-1 defines entropy as a measure of the
difficulty of guessing or determining a password or
key. This document and others that discuss
password entropy can be referred to for more
information on applicable entropy value and for
understanding equivalent password strength
variability for passwords/phrases of different
formats.
8.2.3 Passwords/phrases must meet the following:
-Require a minimum length of at least seven
characters.
-Contain both numeric and alphabetic characters.
Alternatively, the passwords/phrases must have
complexity and strength at least equivalent to the
parameters specified above.
8.2.6 Set passwords for first-time use and resets to
a unique value for each user and change
immediately after the first use.
If the same password is used for every new user set
up, an internal user, former employee, or malicious
individual may know or easily discover this
password, and use it to gain access to accounts.
If password history isnt maintained, the
effectiveness of changing passwords is reduced, as
previous passwords can be reused over and over.
Requiring that passwords cannot be reused for a
period of time reduces the likelihood that passwords
that have been guessed or brute-forced will be used
in the future.
8.2.4 Change user passwords at least every 90
days.
8.2.5 Do not allow an individual to submit a new
password that is the same as any of the last four
passwords he or she has used.
Strong passwords are the first line of defense into a
network since a malicious individual will often first
try to find accounts with weak or non-existent
passwords. There is more time for a malicious
individual to find these weak accounts, and
compromise a network under the guise of a valid
user ID, if passwords are short, simple to guess, or
valid for a long time without a change. Strong
passwords can be enforced and maintained per
these requirements by enabling the password and
account security features that come with your
operating system (for example, Windows), networks,
databases and other platforms.
Two-factor authentication requires two forms of
authentication for higher-risk accesses, such as
those originating from outside your network. For
additional security, your organization can also
consider using two-factor authentication when
accessing networks of higher security from networks
of lower securityfor example, from corporate
desktops (lower security) to production
servers/databases with cardholder data (high
security).
This requirement is intended to apply to users that
have remote access to the network, where that
remote access could lead to access to the cardholder
data environment.
n this context, remote access refers to network-level
access originating from outside an entitys own
network, either from the Internet or from an
untrusted network or system, such as a third party
or an employee accessing the entitys network using
his/her mobile computer. Internal LAN-to-LAN
access (for example, between two offices via secure
VPN) is not considered remote access for the
purposes of this requirement.
If remote access is to an entitys network that has
appropriate segmentation, such that remote users
cannot access or impact the cardholder data
environment, two- factor authentication for remote
access to that network would not required by PCI
DSS. However, two-factor authentication is required
for any remote access to networks with access to
the cardholder data environment, and is
recommended for all remote access to the entitys
networks.
8.3 Incorporate two-factor authentication for
remote network access originating from outside
the network by personnel (including users and
administrators) and all third parties, (including
vendor access for support or maintenance).
8.4 Document and communicate authentication
procedures and policies to all users including:
-Guidance on selecting strong authentication
credentials
-Guidance for how users should protect their
authentication credentials
-Instructions not to reuse previously used passwords
-Instructions to change passwords if there is any
suspicion the password could be compromised.
Communicating password/authentication
procedures to all users helps those users understand
and abide by the policies.
For example, guidance on selecting strong
passwords may include suggestions to help
personnel select hard-to-guess passwords that dont
contain dictionary words, and that dont contain
information about the user (such as the user ID,
names of family members, date of birth, etc.).
Guidance for protecting authentication credentials
may include not writing down passwords or saving
them in insecure files, and being alert for malicious
individuals who may attempt to exploit their
passwords (for example, by calling an employee and
asking for their password so the caller can
troubleshoot a problem).
Instructing users to change passwords if there is a
chance the password is no longer secure can prevent
malicious users from using a legitimate password to
gain unauthorized access.
If multiple users share the same authentication
credentials (for example, user account and
password), it becomes impossible to trace system
access and activities to an individual. This in turn
prevents an entity from assigning accountability for,
or having effective logging of, an individuals actions,
since a given action could have been performed by
anyone in the group that has knowledge of the
authentication credentials.
8.5 Do not use group, shared, or generic accounts
and passwords, or other authentication methods.
8.4 Document and communicate authentication
procedures and policies to all users including:
-Guidance on selecting strong authentication
credentials
-Guidance for how users should protect their
authentication credentials
-Instructions not to reuse previously used passwords
-Instructions to change passwords if there is any
suspicion the password could be compromised.
Communicating password/authentication
procedures to all users helps those users understand
and abide by the policies.
For example, guidance on selecting strong
passwords may include suggestions to help
personnel select hard-to-guess passwords that dont
contain dictionary words, and that dont contain
information about the user (such as the user ID,
names of family members, date of birth, etc.).
Guidance for protecting authentication credentials
may include not writing down passwords or saving
them in insecure files, and being alert for malicious
individuals who may attempt to exploit their
passwords (for example, by calling an employee and
asking for their password so the caller can
troubleshoot a problem).
Instructing users to change passwords if there is a
chance the password is no longer secure can prevent
malicious users from using a legitimate password to
gain unauthorized access.
8.5.1 Additional requirement for service providers:
Service providers with remote access to customer
premises (for example, for support of POS systems
or servers) must use a unique authentication
credential (such as a password/phrase) for each
customer.
To prevent the compromise of multiple customers
through the use of a single set of credentials,
vendors with remote access accounts to customer
environments should use a different authentication
credential for each customer.
Technologies, such as two-factor mechanisms, that
provide a unique credential for each connection (for
example, via a single-use password) could also meet
the intent of this requirement.
8.6 Where other authentication mechanisms are
used (for example, physical or logical security
tokens, smart cards, certificates, etc.), use of these
mechanisms must be assigned as follows:
-Authentication mechanisms must be assigned to an
individual account and not shared among multiple
accounts.
-Physical and/or logical controls must be in place to
ensure only the intended account can use that
mechanism to gain access.
If user authentication mechanisms such as tokens,
smart cards, and certificates can be used by multiple
accounts, it may be impossible to identify the
individual using the authentication mechanism.
Having physical and/or logical controls (for example,
a PIN, biometric data, or a password) to uniquely
identify the user of the account will prevent
unauthorized users from gaining access through use
of a shared authentication mechanism.
Without user authentication for access to databases
and applications, the potential for unauthorized or
malicious access increases, and such access cannot
be logged since the user has not been authenticated
and is therefore not known to the system. Also,
database access should be granted through
programmatic methods only (for example, through
stored procedures), rather than via direct access to
the database by end users (except for DBAs, who
may need direct access to the database for their
administrative duties).
8.7 All access to any database containing cardholder
data (including access by applications,
administrators, and all other users) is restricted as
follows:
- All user access to, user queries of, and user actions
on databases are through programmatic methods.
-Only database administrators have the ability to
directly access or query databases.
- Application IDs for database applications can only
be used by the applications (and not by individual
users or other non-application processes).
8.8 Ensure that security policies and operational
procedures for identification and authentication are
documented, in use, and known to all affected
parties.
Personnel need to be aware of and following
security policies and operational procedures for
managing identification and authorization on a
continuous basis.
Without user authentication for access to databases
and applications, the potential for unauthorized or
malicious access increases, and such access cannot
be logged since the user has not been authenticated
and is therefore not known to the system. Also,
database access should be granted through
programmatic methods only (for example, through
stored procedures), rather than via direct access to
the database by end users (except for DBAs, who
may need direct access to the database for their
administrative duties).
8.7 All access to any database containing cardholder
data (including access by applications,
administrators, and all other users) is restricted as
follows:
- All user access to, user queries of, and user actions
on databases are through programmatic methods.
-Only database administrators have the ability to
directly access or query databases.
- Application IDs for database applications can only
be used by the applications (and not by individual
users or other non-application processes).
Go To Req 9 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
8.1.a Review procedures and confirm they define processes for each of the
items below at 8.1.1 through 8.1.8
8.1.b Verify that procedures are implemented for user identification
management, by performing the following:
8.1.1 Interview administrative personnel to confirm that all users are assigned a
unique ID for access to system components or cardholder data.
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
C12.7
Major Observations from the 2014 Verizon PCI Compliance report:
-According to our RISK teams assessments, only 24.2% of organizations that suffered a security breach were compliant with Requirement 8 at the time of their breach.
-Average compliance with Requirement 8: 84,1%
-Seven of the subcontrols (8.5.10.b, 8.5.12.b, 8.5.13.b, 8.5.9.b, 8.4.b, 8.5.11.b, 8.5.7) are met with over 90% compliance.
-But a mere 57.4% of organizations complied with 8.5.1, which governs the addition, deletion, and modification of IDs and credentials.
-62.4% of organizations complied with 8.5.15, which specifies that idle sessions expire after no more than 15 minutes
-62.4% of organizations complied with 8.5.13.a, which requires that users are locked out after no more than six failed login attempts
-55.4% complied with both (8.5.15 and 8.5.13.a ), 13.9% with just one, and 30.7% with neither.
C16.9
8.1.2 For a sample of privileged user IDs and general user IDs, examine
associated authorizations and observe system settings to verify each user ID and
privileged user ID has been implemented with only the privileges specified on
the documented approval.
8.1.3.a Select a sample of users terminated in the past six months, and review
current user access listsfor both local and remote accessto verify that their
IDs have been deactivated or removed from the access lists.
8.1.3.b Verify all physical authentication methodssuch as, smart cards, tokens,
etc.have been returned or deactivated.
8.1.5.a Interview personnel and observe processes for managing accounts used by
vendors to access, support, or maintain system components to verify that accounts
used by vendors for remote access are:
Disabled when not in use
Enabled only when needed by the vendor, and disabled when not in use.
C16.5 8.1.4 Observe user accounts to verify that any inactive accounts over 90 days old are
either removed or disabled.
C16.3
8.1.5.b Interview personnel and observe processes to verify that vendor remote access
accounts are monitored while being used.
C16.8 8.1.6.a For a sample of system components, obtain and inspect system configuration
settings to verify that authentication parameters are set to require that a users
account be locked out after not more than six invalid logon attempts.
8.1.6.b Additional testing procedure for service providers: Review internal
processes and customer/user documentation, and observe implemented
processes to verify that non- consumer user accounts are temporarily locked-
out after not more than six invalid access attempts.
C16.8.1 8.1.7 For a sample of system components, obtain and inspect system configuration
settings to verify that password parameters are set to require that once a user account
is locked out, it remains locked for a minimum of 30 minutes or until a system
administrator resets the account.
C16.4 8.1.8 For a sample of system components, obtain and inspect system configuration
settings to verify that system/session idle time out features have been set to 15
minutes or less.
8.2 To verify that users are authenticated using unique ID and additional authentication
(for example, a password/phrase) for access to the cardholder data environment,
perform the following:
Examine documentation describing the authentication method(s) used.
For each type of authentication method used and for each type of system
component, observe an authentication to verify authentication is functioning
consistent with documented authentication method(s).
8.2.1.a Examine vendor documentation and system configuration settings to
verify that passwords are protected with strong cryptography during
transmission and storage.
8.2.1.b For a sample of system components, examine password files to verify
that passwords are unreadable during storage.
8.2.1.c For a sample of system components, examine data transmissions to verify that
passwords are unreadable during transmission.
8.2.1.d Additional testing procedure for service providers: Observe password files to
verify that customer passwords are unreadable during storage.
8.2.1.e Additional testing procedure for service providers: Observe data transmissions
to verify that customer passwords are unreadable during transmission.
C12.5
NC
8.2.2 Examine authentication procedures for modifying authentication
credentials and observe security personnel to verify that, if a user requests a
reset of an authentication credential by phone, e-mail, web, or other non-face-
to-face method, the users identity is verified before the authentication
credential is modified.
8.2.3a For a sample of system components, inspect system configuration settings to
verify that user password parameters are set to require at least the following
strength/complexity:
-Require a minimum length of at least seven characters.
-Contain both numeric and alphabetic characters.
8.2.3.b Additional testing procedure for service providers: Review internal processes
and customer/user documentation to verify that non-consumer user passwords are
required to meet at least the following strength/complexity:
-Require a minimum length of at least seven characters.
-Contain both numeric and alphabetic characters.
8.2.4.a For a sample of system components, obtain and inspect system configuration
settings to verify that user password parameters are set to require users to change
passwords at least every 90 days.
8.2.4.b Additional testing procedure for service providers: Review internal processes
and customer/user documentation to verify that:
Non-consumer user passwords are required to change periodically; and
Non-consumer users are given guidance as to when, and under what circumstances,
passwords must change.
8.2.5.a For a sample of system components, obtain and inspect system configuration
settings to verify that password parameters are set to require that new passwords
cannot be the same as the four previously used passwords.
8.2.5.b Additional testing procedure for service providers: Review internal
processes and customer/user documentation to verify that new non-
consumer user passwords cannot be the same as the previous four passwords.
NC 8.2.6 Examine password procedures and observe security personnel to verify that
first-time passwords for new users, and reset passwords for existing users, are set to
a unique value for each user and changed after first use.
C12.8
C1.7.3
C12.3
C16.7.2
8.3.a Examine system configurations for remote access servers and systems to verify
two-factor authentication is required for:
All remote access by personnel
All third-party/vendor remote access (including access to
applications and system components for support or maintenance purposes).
8.3.b Observe a sample of personnel (for example, users and administrators)
connecting remotely to the network and verify that at least two of the three
authentication methods are used.
8.4.a Examine procedures and interview personnel to verify that authentication
procedures and policies are distributed to all users.
C10.6
C13.7
8.4.b Review authentication procedures and policies that are distributed to users and
verify they include:
Guidance on selecting strong authentication credentials
Guidance for how users should protect their authentication
credentials.
Instructions for users not to reuse previously used passwords
Instructions to change passwords if there is any suspicion the
password could be compromised.
8.4.c Interview a sample of users to verify that they are familiar with authentication
procedures and policies.
8.5.a For a sample of system components, examine user ID lists to verify the following:
-Generic user IDs are disabled or removed.- Shared user IDs for system administration
activities and other critical functions do not exist.
-Shared and generic user IDs are not used to administer any system components.
8.5.b Examine authentication policies/procedures to verify that use of group and
shared IDs and/or passwords or other authentication methods are explicitly prohibited.
8.5.c Interview system administrators to verify that group and shared IDs and/or
passwords or other authentication methods are not distributed, even if requested.
8.5.1 Additional testing procedure for service providers: Examine authentication
policies and procedures and interview personnel to verify that different authentication
are used for access to each customer.
8.6.a Examine authentication policies and procedures to verify that procedures for
using authentication mechanisms such as physical security tokens, smart cards, and
certificates are defined and include:
Authentication mechanisms are assigned to an individual account and not shared
among multiple accounts.
Physical and/or logical controls are defined to ensure only the intended account can
use that mechanism to gain access.
8.6.b Interview security personnel to verify authentication mechanisms are assigned to
an account and not shared among multiple accounts.
8.6.c Examine system configuration settings and/or physical controls, as applicable, to
verify that controls are implemented to ensure only the intended account can use that
mechanism to gain access.
8.7.a Review database and application configuration settings and verify that all users
are authenticated prior to access.
8.7.b Examine database and application configuration settings to verify that all user
access to, user queries of, and user actions on (for example, move, copy, delete), the
database are through programmatic methods only (for example, through stored
procedures).
8.7.c Examine database access control settings and database application configuration
settings to verify that user direct access to or queries of databases are restricted to
database administrators.
8.7.d Examine database access control settings, database application configuration
settings, and the related application IDs to verify that application IDs can only be used
by the applications (and not by individual users or other processes).
8.8 Examine documentation interview personnel to verify that security policies and
operational procedures for identification and authentication are:
-Documented,
-In use, and
-Known to all affected parties.
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A
Identify the written procedures for user identification management examined
to verify processes are defined for each of the items below at 8.1.1 through
8.1.8:
components or cardholder data.
other identifier objects.
components via remote access as follows:
- Enabled only during the time period
needed and disabled when not in use.
- Monitored when in use.
than six attempts.
administrator enables the user ID.
authenticate to re-activate the terminal or session.
4 0
Left empty by PCIco 4 0
Identify the responsible administrative personnel interviewed for this testing
procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed to confirm that all users
are assigned a unique ID for access to system components or cardholder data.
<Report Findings Here>
4 0
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
Major Observations from the 2014 Verizon PCI Compliance report:
-According to our RISK teams assessments, only 24.2% of organizations that suffered a security breach were compliant with Requirement 8 at the time of their breach.
-Average compliance with Requirement 8: 84,1%
-Seven of the subcontrols (8.5.10.b, 8.5.12.b, 8.5.13.b, 8.5.9.b, 8.4.b, 8.5.11.b, 8.5.7) are met with over 90% compliance.
-But a mere 57.4% of organizations complied with 8.5.1, which governs the addition, deletion, and modification of IDs and credentials.
-62.4% of organizations complied with 8.5.15, which specifies that idle sessions expire after no more than 15 minutes
-62.4% of organizations complied with 8.5.13.a, which requires that users are locked out after no more than six failed login attempts
-55.4% complied with both (8.5.15 and 8.5.13.a ), 13.9% with just one, and 30.7% with neither.
Selected Merchant Type:
Identify the sample of privileged user IDs selected for this testing procedure.
<Report Findings Here>
Identify the sample of general user IDs selected for this testing procedure.
<Report Findings Here>
Describe how observed system settings and the associated authorizations
documented for the user IDs were compared to verify that each ID has been
implemented with only the privileges specified on the documented approval:
For the sample of privileged user IDs.
<Report Findings Here>
For the sample of general user IDs.
<Report Findings Here>
4 0
Identify the sample of users terminated in the past six months selected.
<Report Findings Here>
Describe how the current user access lists for local access were reviewed to verify that
the sampled user IDs have been deactivated or removed from the access lists.
<Report Findings Here>
Describe how the current user access lists for remote access were reviewed to verify
that the sampled user IDs have been deactivated or removed from the access lists.
<Report Findings Here>
4 0
For the sample of users terminated in the past six months at 8.1.3.a, describe how it
was determined which, if any, physical authentication methods, the terminated users
had access to prior to termination.
<Report Findings Here>
Describe how the physical authentication method(s) for the terminated employees
were verified to have been returned or deactivated.
<Report Findings Here>
4 0
Identify the personnel interviewed who confirm that accounts used by vendors for
remote access are:
<Report Findings Here>
Describe how processes for managing accounts used by vendors to access, support,
or maintain system components were observed to verify that accounts used by
vendors for remote access are:
Disabled when not in use.
Enabled only when needed by the vendor, and disabled when not in use.
<Report Findings Here>
4 0
0 4 Describe how user accounts were observed to verify that any inactive accounts over
90 days old are either removed or disabled.
<Report Findings Here>
Identify the personnel interviewed who confirm that accounts used by vendors for
remote access are monitored while being used.
<Report Findings Here>
Describe how processes for managing accounts used by vendors to access, support,
or maintain system components were observed to verify that vendor remote access
accounts are monitored while being used.
<Report Findings Here>
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected to verify that authentication parameters are set to require that user
accounts be locked after not more than six invalid logon attempts.
<Report Findings Here>
4 0
For service providers only, identify the documented internal processes and
customer/user documentation reviewed to verify that non-consumer user accounts
are temporarily locked-out after not more than six invalid access attempts.
<Report Findings Here>
Describe the implemented processes that were observed to verify that non-consumer
user accounts are temporarily locked-out after not more than six invalid access
attempts.
<Report Findings Here>
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected to verify that password parameters are set to require that once a user
account is locked out, it remains locked for a minimum of 30 minutes or until a
system administrator resets the account.
<Report Findings Here>
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected to verify that system/session idle time out features have been set to 15
minutes or less.
<Report Findings Here>
4 0
Identify the document describing the authentication method(s) used that was
reviewed to verify that the methods require users to be authenticated using a unique
ID and additional authentication for access to the cardholder data environment.
<Report Findings Here>
Describe the authentication methods used (for example, a password or passphrase, a
token device or smart card, a biometric, etc.) for each type of system component.
<Report Findings Here>
For each type of authentication method used and for each type of system
component, describe how the authentication method was observed to be:
Used for access to the cardholder data environment.
Functioning consistently with the documented authentication method(s).
<Report Findings Here>
4 0
Identify the vendor documentation reviewed for this testing procedure.
<Report Findings Here>
Identify the sample of system components selected.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
examined to verify that passwords are protected with strong cryptography during
transmission.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
examined to verify that passwords are protected with strong cryptography during
storage.
<Report Findings Here>
4 0
For each item in the sample at 8.2.1.a, describe how password files were examined to
verify that passwords are unreadable during storage.
<Report Findings Here>
4 0
For each item in the sample at 8.2.1.a, describe how password files were examined to
verify that passwords are unreadable during transmission.
<Report Findings Here>
4 0
Additional procedure for service providers: for each item in the sample at 8.2.1.a,
describe how password files were examined to verify that customer passwords are
unreadable during storage.
<Report Findings Here>
4 0
Additional procedure for service providers: for each item in the sample at 8.2.1.a,
describe how password files were examined to verify that customer passwords are
unreadable during transmission.
<Report Findings Here>
4 0
Identify the document examined to verify that authentication procedures for
modifying authentication credentials define that if a user requests a reset of an
authentication credential by a non-face-to-face method, the users identity is verified
before the authentication credential is modified.
<Report Findings Here>
Describe the non-face-to-face methods used for requesting password resets.
<Report Findings Here>
Describe how security personnel were observed to verify that if a user requests a
reset of an authentication credential by a non-face-to- face method, the users
identity is verified before the authentication credential is modified.
<Report Findings Here>
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected to verify that user password parameters are set to require at least the
following strength/complexity:
Require a minimum length of at least seven characters.
Contain both numeric and alphabetic characters.
<Report Findings Here>
4 0
For service providers only: Identify the documented internal processes and
customer/user documentation reviewed to verify that non-consumer user passwords
are required to meet at least the following strength/complexity:
characters.
<Report Findings Here>
Describe how internal processes were reviewed to verify that non-consumer user
passwords are required to meet at least the following strength/complexity:
A minimum length of at least seven characters.
Non-consumer user passwords are required to contain both numeric and alphabetic
characters
<Report Findings Here>.
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected to verify that user password parameters are set to require users to change
passwords at least every 90 days.
<Report Findings Here>
4 0
For service providers only, identify the documented internal processes and
customer/user documentation reviewed to verify that:
passwords must change.
<Report Findings Here>
Describe how internal processes were reviewed to verify that:
Non-consumer user passwords are required to change periodically; and
Non-consumer users are given guidance as to when, and under what circumstances,
passwords must change.
<Report Findings Here>
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected to verify that password parameters are set to require that new passwords
cannot be the same as the four previously used passwords.
<Report Findings Here>
4 0
For service providers only, identify the documented internal processes and
customer/user documentation reviewed to verify that new non-consumer user
passwords cannot be the same as the previous four passwords.
<Report Findings Here>
Describe how internal processes were reviewed to verify that new non-consumer
user passwords cannot be the same as the previous four passwords.
<Report Findings Here>
4 0
Identify the documented password procedures examined to verify the procedures
define that:
<Report Findings Here>
Describe how security personnel were observed to:
Set first-time passwords to a unique value for each new user.
Set first-time passwords to be changed after first use.
<Report Findings Here>
4 0
Describe how system configurations for remote access servers and systems were
examined to verify two-factor authentication is required for:
All remote access by personnel.
All third-party/vendor remote access (including access to applications and system
components for support or maintenance purposes).
<Report Findings Here>
4 0
Identify the sample of personnel observed connecting remotely to the network
selected.
<Report Findings Here>
For each item in the sample, describe how two- factor authentication was observed
to be required for remote access to the network.
<Report Findings Here>
Identify which two factors are used:
<Report Findings Here>
4 0
Identify the documented procedures examined to verify authentication procedures
define that authentication procedures and policies are distributed to all users.
<Report Findings Here>
Identify the personnel interviewed who confirm that authentication procedures and
policies are distributed to all users.
<Report Findings Here>
4 0
Identify the documented authentication procedures and policies that are distributed
to users reviewed to verify they include:
compromised.
<Report Findings Here>
4 0
Identify the sample of users interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify that the
sampled users are familiar with authentication procedures and policies.
<Report Findings Here>
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how user ID lists for the sample of system
components were examined to verify that:
Generic user IDs are disabled or removed.
Shared user IDs for system administration activities and other critical functions do
not exist.
Shared and generic user IDs are not used to administer any system components.
<Report Findings Here>
4 0
Identify the documented policies/procedures examined to verify authentication
policies/procedures define that use of group and shared IDs and/or passwords or
other authentication methods are explicitly prohibited.
<Report Findings Here>
4 0
Identify the system administrators interviewed who confirm that group and shared
IDs and/or passwords or other authentication methods are not distributed, even if
requested.
4 0
For service providers only, indicate whether this ROC is being completed prior to June
30, 2015. (yes/no)
<Report Findings Here>
If yes AND the assessed entity does not have this in place ahead of the
requirements effective date, mark this as Not Applicable.
If no OR if the assessed entity has this in place ahead of the requirements effective
date, complete the following:
Identify the documented procedures examined to verify that different authentication
is used for access to each customer.
<Report Findings Here>
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed to confirm that different
authentication is used for access to each customer.
<Report Findings Here>
4 0
Identify the documented authentication policies and procedures examined to verify
the procedures for using authentication mechanisms define that:
among multiple accounts.
can use that mechanism to gain access.
<Report Findings Here>
4 0
Identify the security personnel interviewed who confirm that authentication
mechanisms are assigned to an account and not shared among multiple accounts.
<Report Findings Here>
4 0
Identify the sample of system components selected for this testing procedure.
<Report Findings Here>
For each item in the sample, describe how system configuration settings and/or
physical controls, as applicable, were examined to verify that controls are
implemented to ensure only the intended account can use that mechanism to gain
access.
<Report Findings Here>
4 0
Identify all databases containing cardholder data.
<Report Findings Here>
Describe how authentication is managed (for example, via application and/or
database interfaces).
<Report Findings Here>
Describe how database and/or application configuration settings were observed to
verify that all users are authenticated prior to access.
4 0
For each database from 8.7.a:
Describe how the database and application configuration settings were examined to
verify that only programmatic methods are used for:
All user access to the database
All use queries of the database
All user actions on the database
<Report Findings Here>
Describe the process observed to verify that only programmatic methods are used
for:
All user access to the database
All use queries of the database
All user actions on the database
<Report Findings Here>
4 0
For each database from 8.7.a, describe how database application configuration
settings were examined to verify that the following are restricted to only database
administrators:
User direct access to databases
Queries of databases
<Report Findings Here>
4 0
For each database from 8.7.a:
Identify applications with access to the database.
<Report Findings Here>
Describe the implemented methods for ensuring that application IDs can only be used
by the applications.
<Report Findings Here>
Describe how database access control settings, database application configuration
settings and related application IDs were examined together to verify that application
IDs can only be used by the applications.
<Report Findings Here>
4 0
Identify the document reviewed to verify that security policies and operational
procedures for identification and authentication are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for identification and authentication are:
<Report Findings Here>
6
0
170 0
A-EP PE2P B B-IP C-VT C D S In Place? Severity
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
N 3
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
D Selected Merchant Type:
0 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
Y 0
1 0 0 1 0 1 1 1
N 3
0 0 0 0 1
Y
0 1
0
0
1 0 0 1 0 1 1 1
N 3
1 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 0 1
N 0
1 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 0 1
N 0
0 0 0 0 0 0 0 1
N 0
0 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 0 1
N 0
1 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 0 1
N 0
1 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 0 1
N 0
1 0 0 0 0 0 1 1
N 3
1 0 0 1 0 1 1 1
N 3
1 0 0 1 0 1 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
1 0 0 1 0 0 1 1
N 3
1 0 0 1 0 0 1 1
N 3
1 0 0 1 0 0 1 1
N 3
0 0 0 0 0 0 0 1
N 0
1 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
N 3
1 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 1
21 0 0 7 0 4 37 44 Y 97
N
C
NT
NA
Proofs /
Documentation links
Stage of implementation Remediation plan
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
Estimated date for completion Comments Owner
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
Return to Table of content Go to requriement 8
PCI DSS Requirement Guidance
9.1 Use appropriate facility entry controls to limit
and monitor physical access to systems in the
cardholder data environment.
Without physical access controls, unauthorized
persons could potentially gain access to the building
and to sensitive information, and could alter system
configurations, introduce vulnerabilities into the
network, or destroy or steal equipment.
Major Observations from the 2014 Verizon Compliance Report:
Five of Requirement 9s subcontrols (9.1.3, 9.1.2, 9.3.3, 9.3.1 and 9.3.2.b) make it into our Top 20. These refer to restricting physical access to network hardware, and making sure all visitors are authorized (with specific controls before entering areas where CHD is processed or maintained). These achieve
between 86.1% and 91.1% compliance, showing that organizations are generally pretty strong on controlling physical access.
Just 66.3% of organizations were compliant with 9.9.1 *Properly maintain inventory logs of all media and conduct media inventories at least annually+. This low level of compliance could be because organizations see logging as a resource-intensive task that adds little value we disagree and organizations
that do maintain logs may forget about backups or USB devices containing CHD.
But surprisingly, 74.3% of organizations were compliant with 9.8 [Destroy media when it is no longer needed for business or legal reasons].
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entitys premises. A visitor refers to a vendor, guest of any onsite personnel, service workers, or
Requirement 9: Restrict physical access to cardholder data
9.1.1 Use video cameras and/or access control
mechanisms to monitor individual physical access to
sensitive areas. Review collected data and correlate
with other entries. Store for at least three months,
unless otherwise restricted by law.
Note: Sensitive areas refers to any data center,
server room or any area that houses systems that
store, process, or transmit cardholder data. This
excludes the areas where only point-of-sale
terminals are present, such as the cashier areas in a
retail store.
When investigating physical breaches, these controls
can help identify individuals that physically access
those sensitive areas storing cardholder data.
Examples of sensitive areas include corporate
database server rooms, back-end server room of a
retail location that stores cardholder data, and
storage areas for large quantities of cardholder data,
9.1.2 Implement physical and/or logical controls to
restrict access to publicly accessible network jacks.
Restricting access to network jacks will prevent
malicious individuals from plugging into readily
available network jacks that may allow them access
into internal network resources. Consider turning off
network jacks while not in use, and reactivating
them only while needed. In public areas such as
conference rooms, establish private networks to
allow vendors and visitors to access Internet only so
that they are not on your internal network.
9.1.3 Restrict physical access to wireless access
points, gateways, handheld devices,
networking/communications hardware, and
telecommunication lines.
Without security over access to wireless
components and devices, malicious users could use
your organizations unattended wireless devices to
access your network resources, or even connect
their own devices to your wireless network to gain
unauthorized access. Additionally, securing
networking and communications hardware prevents
malicious users from intercepting network traffic or
physically connecting their own devices to your
wired network resources.
Consider placing wireless access points, gateways
and networking/ communications hardware in
secure storage areas, such as within locked closets
or server rooms. For wireless networks, ensure
strong encryption is enabled. Also consider enabling
automatic device lockout on wireless handheld
devices after a long idle period, and set your devices
to require a password when powering on.
Without badge systems and door controls,
unauthorized and malicious users can easily gain
access to your facility to steal, disable, disrupt, or
destroy critical systems and cardholder data. For
optimum control, consider implementing badge or
card access system in and out of work areas that
contain cardholder data.
Identifying authorized visitors so they are easily
distinguished from onsite personnel prevents
unauthorized visitors from being granted access to
areas containing cardholder data.
9.2 Develop procedures to easily distinguish
between onsite personnel and visitors, especially in
areas where cardholder data is accessible.
9.1.1 Use video cameras and/or access control
mechanisms to monitor individual physical access to
sensitive areas. Review collected data and correlate
with other entries. Store for at least three months,
unless otherwise restricted by law.
Note: Sensitive areas refers to any data center,
server room or any area that houses systems that
store, process, or transmit cardholder data. This
excludes the areas where only point-of-sale
terminals are present, such as the cashier areas in a
retail store.
When investigating physical breaches, these controls
can help identify individuals that physically access
those sensitive areas storing cardholder data.
Examples of sensitive areas include corporate
database server rooms, back-end server room of a
retail location that stores cardholder data, and
storage areas for large quantities of cardholder data,
9.4 Implement procedures to identify and authorize
visitors. Procedures should include the following:
Without badge systems and door controls,
unauthorized and malicious users can easily gain
access to your facility to steal, disable, disrupt, or
destroy critical systems and cardholder data. For
optimum control, consider implementing badge or
card access system in and out of work areas that
contain cardholder data.
Identifying authorized visitors so they are easily
distinguished from onsite personnel prevents
unauthorized visitors from being granted access to
areas containing cardholder data.
9.2 Develop procedures to easily distinguish
between onsite personnel and visitors, especially in
areas where cardholder data is accessible.
9.4.1 Visitors are authorized before entering, and
escorted at all times within, areas where cardholder
data is processed or maintained.
Visitor controls are important to reduce the ability
of unauthorized and malicious persons to gain
access to facilities (and potentially, to cardholder
data).
Visitor controls ensure visitors are identifiable as
visitors so personnel can monitor their activities,
and that their access is restricted to just the duration
of their legitimate visit.
Ensuring that visitor badges are returned upon
expiry or completion of the visit prevents malicious
persons from using a previously authorized pass to
gain physical access into the building after the visit
has ended.
A visitor log documenting minimum information on
the visitor is easy and inexpensive to maintain and
will assist in identifying physical access to a building
or room, and potential access to cardholder data.
9.3 Control physical access for onsite personnel to
the sensitive areas as follows:

-Access must be authorized and based on individual
job function.
-Access is revoked immediately upon termination,
and all physical access mechanisms, such as keys,
access cards, etc., are returned or disabled.
Controlling physical access to the CDE helps ensure
that only authorized personnel with a legitimate
business need are granted access.
When personnel leave the organization, all physical
access mechanisms should be returned or disabled
promptly (as soon as possible) upon their departure,
to ensure personnel cannot gain physical access to
the CDE once their employment has ended.
9.4.3 Visitors are asked to surrender the badge or
identification before leaving the facility or at the
date of expiration.
9.5 Physically secure all media.
9.4.2 Visitors are identified and given a badge or
other identification that expires and that visibly
distinguishes the visitors from onsite personnel.
9.4.1 Visitors are authorized before entering, and
escorted at all times within, areas where cardholder
data is processed or maintained.
Visitor controls are important to reduce the ability
of unauthorized and malicious persons to gain
access to facilities (and potentially, to cardholder
data).
Visitor controls ensure visitors are identifiable as
visitors so personnel can monitor their activities,
and that their access is restricted to just the duration
of their legitimate visit.
Ensuring that visitor badges are returned upon
expiry or completion of the visit prevents malicious
persons from using a previously authorized pass to
gain physical access into the building after the visit
has ended.
A visitor log documenting minimum information on
the visitor is easy and inexpensive to maintain and
will assist in identifying physical access to a building
or room, and potential access to cardholder data.
Controls for physically securing media are intended
to prevent unauthorized persons from gaining
access to cardholder data on any type of media.
Cardholder data is susceptible to unauthorized
viewing, copying, or scanning if it is unprotected
while it is on removable or portable media, printed
out, or left on someones desk.
9.4.4 A visitor log is used to maintain a physical audit
trail of visitor activity to the facility as well as
computer rooms and data centers where cardholder
data is stored or transmitted.
Document the visitors name, the firm represented,
and the onsite personnel authorizing physical access
on the log. Retain this log for a minimum of three
months, unless otherwise restricted by law.
9.5.1 Store media backups in a secure location,
preferably an off-site facility, such as an alternate or
backup site, or a commercial storage facility. Review
the locations security at least annually.
9.6 Maintain strict control over the internal or
external distribution of any kind of media, including
the following:
Procedures and processes help protect cardholder
data on media distributed to internal and/or
external users. Without such procedures data can be
lost or stolen and used for fraudulent purposes.
9.6.1 Classify media so the sensitivity of the data can
be determined.
It is important that media be identified such that its
classification status can be easily discernable. Media
not identified as confidential may not be adequately
protected or may be lost or stolen
9.6.3 Ensure management approves any and all
media that is moved from a secured area (including
when media is distributed to individuals).
Without a firm process for ensuring that all media
movements are approved before the media is
removed from secure areas, the media would not be
tracked or appropriately protected, and its location
would be unknown, leading to lost or stolen media.
9.7 Maintain strict control over the storage and
accessibility of media.
Without careful inventory methods and storage
controls, stolen or missing media could go unnoticed
for an indefinite amount of time.
Media may be lost or stolen if sent via a non-
trackable method such as regular postal mail. Use
the services of a secure courier to deliver any media
that contains cardholder data, so that you can use
their tracking systems to maintain inventory and
location of shipments.
9.6.2 Send the media by secured courier or other
delivery method that can be accurately tracked.
Controls for physically securing media are intended
to prevent unauthorized persons from gaining
access to cardholder data on any type of media.
Cardholder data is susceptible to unauthorized
viewing, copying, or scanning if it is unprotected
while it is on removable or portable media, printed
out, or left on someones desk.
9.5.1 Store media backups in a secure location,
preferably an off-site facility, such as an alternate or
backup site, or a commercial storage facility. Review
the locations security at least annually.
9.7.1 Properly maintain inventory logs of all media
and conduct media inventories at least annually.
If media is not inventoried, stolen or lost media may
not be noticed for a long time or at all.
9.8 Destroy media when it is no longer needed for
business or legal reasons as follows:
9.8.2 Render cardholder data on electronic media
unrecoverable so that cardholder data cannot be
reconstructed.
If steps are not taken to destroy information
contained on hard disks, portable drives, CD/DVDs,
or paper prior to disposal, malicious individuals may
be able to retrieve information from the disposed
media, leading to a data compromise. For example,
malicious individuals may use a technique known as
dumpster diving, where they search through trash
cans and recycle bins looking for information they
can use to launch an attack.
Examples of methods for securely destroying
electronic media include secure wiping, degaussing,
or physical destruction (such as grinding or
shredding hard disks).
9.8.1 Shred, incinerate, or pulp hardcopy materials
so that cardholder data cannot be reconstructed.
9.9 Protect devices that capture payment card data
via direct physical interaction with the card from
tampering and substitution.
Criminals attempt to steal cardholder data by
stealing and/or manipulating card-reading devices
and terminals. For example, they will try to steal
devices so they can learn how to break into them,
and they often try to replace legitimate devices with
fraudulent devices that send them payment card
information every time a card is entered. Criminals
will also try to add skimming components to the
outside of devices, which are designed to capture
payment card details before they even enter the
devicefor example, by attaching an additional card
reader on top of the legitimate card reader so that
the payment card details are captured twice: once
by the criminals component and then by the
devices legitimate component. In this way,
transactions may still be completed without
interruption while the criminal is skimming the
payment card information during the process.
This requirement is recommended, but not required,
for manual key-entry components such as computer
keyboards and POS keypads.
Additional best practices on skimming prevention
are available on the PCI SSC website.
9.9.1 Maintain an up-to-date list of devices. The list
should include the following:
-Make, model of device
-Location of device (for example, the address of the
site or facility where the device is located)
-Device serial number or other method of unique
identification.
Keeping an up-to-date list of devices helps an
organization keep track of where devices are
supposed to be, and quickly identify if a device is
missing or lost.
The method for maintaining a list of devices may be
automated (for example, a device-management
system) or manual (for example, documented in
electronic or paper records). For on-the-road
devices, the location may include the name of the
personnel to whom the device is assigned.
Regular inspections of devices will help
organizations to more quickly detect tampering or
replacement of a device, and thereby minimize the
potential impact of using fraudulent devices.
The type of inspection will depend on the device
for example, photographs of devices that are known
to be secure can be used to compare a devices
current appearance with its original appearance to
see whether it has changed. Another option may be
to use a secure marker pen, such as a UV light
marker, to mark device surfaces and device openings
so any tampering or replacement will be apparent.
Criminals will often replace the outer casing of a
device to hide their tampering, and these methods
may help to detect such activities. Device vendors
may also be able to provide security guidance and
how to guides to help determine whether the
device has been tampered with.
The frequency of inspections will depend on factors
such as location of device and whether the device is
attended or unattended. For example, devices left in
public areas without supervision by the
organizations personnel may have more frequent
inspections than devices that are kept in secure
areas or are supervised when they are accessible to
the public. The type and frequency of inspections is
determined by the merchant, as defined by their
annual risk-assessment process.
9.9.2 Periodically inspect device surfaces to detect
tampering (for example, addition of card skimmers
to devices), or substitution (for example, by checking
the serial number or other device characteristics to
verify it has not been swapped with a fraudulent
device).
Criminals will often pose as authorized maintenance
personnel in order to gain access to POS devices. All
third parties requesting access to devices should
always be verified before being provided accessfor
example, by checking with management or phoning
the POS maintenance company (such as the vendor
or acquirer) for verification. Many criminals will try
to fool personnel by dressing for the part (for
example, carrying toolboxes and dressed in work
wear), and could also be knowledgeable about
locations of devices, so its important personnel are
trained to follow procedures at all times.
Another trick criminals like to use is to send a new
POS system with instructions for swapping it with a
legitimate system and returning the legitimate
system to a specified address. The criminals may
even provide return postage as they are very keen to
get their hands on these devices. Personnel always
verify with their manager or supplier that the device
is legitimate and came from a trusted source before
installing it or using it for business.
9.9.3 Provide training for personnel to be aware of
attempted tampering or replacement of devices.
Training should include the following:
Verify the identity of any third-party persons
claiming to be repair or maintenance personnel,
prior to granting them access to modify or
troubleshoot devices.
Do not install, replace, or return devices without
verification.
Be aware of suspicious behavior around devices
(for example, attempts by unknown persons to
unplug or open devices).
Report suspicious behavior and indications of
device tampering or substitution to appropriate
personnel (for example, to a manager or security
officer).
9.10 Ensure that security policies and operational
procedures for restricting physical access to
cardholder data are documented, in use, and known
to all affected parties.
Personnel need to be aware of and following
security policies and operational procedures for
restricting physical access to cardholder data
and CDE systems on a continuous basis.
Criminals will often pose as authorized maintenance
personnel in order to gain access to POS devices. All
third parties requesting access to devices should
always be verified before being provided accessfor
example, by checking with management or phoning
the POS maintenance company (such as the vendor
or acquirer) for verification. Many criminals will try
to fool personnel by dressing for the part (for
example, carrying toolboxes and dressed in work
wear), and could also be knowledgeable about
locations of devices, so its important personnel are
trained to follow procedures at all times.
Another trick criminals like to use is to send a new
POS system with instructions for swapping it with a
legitimate system and returning the legitimate
system to a specified address. The criminals may
even provide return postage as they are very keen to
get their hands on these devices. Personnel always
verify with their manager or supplier that the device
is legitimate and came from a trusted source before
installing it or using it for business.
9.9.3 Provide training for personnel to be aware of
attempted tampering or replacement of devices.
Training should include the following:
Verify the identity of any third-party persons
claiming to be repair or maintenance personnel,
prior to granting them access to modify or
troubleshoot devices.
Do not install, replace, or return devices without
verification.
Be aware of suspicious behavior around devices
(for example, attempts by unknown persons to
unplug or open devices).
Report suspicious behavior and indications of
device tampering or substitution to appropriate
personnel (for example, to a manager or security
officer).
Go to requriement 10 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
NC Verify the existence of physical security controls for each computer room, data center,
and other physical areas with systems in the cardholder data environment.
- Verify that access is controlled with badge readers or other devices including
authorized badges and lock and key.
- Observe a system administrators attempt to log into consoles for randomly selected
systems in the cardholder environment and verify that they are locked to prevent
unauthorized use.
NC 9.1.1.a Verify that video cameras and/or access control mechanisms are in place to
monitor the entry/exit points to sensitive areas.
9.1.1.b Verify that video cameras and/or access control mechanisms are protected
from tampering or disabling.
Major Observations from the 2014 Verizon Compliance Report:
Five of Requirement 9s subcontrols (9.1.3, 9.1.2, 9.3.3, 9.3.1 and 9.3.2.b) make it into our Top 20. These refer to restricting physical access to network hardware, and making sure all visitors are authorized (with specific controls before entering areas where CHD is processed or maintained). These achieve
between 86.1% and 91.1% compliance, showing that organizations are generally pretty strong on controlling physical access.
Just 66.3% of organizations were compliant with 9.9.1 *Properly maintain inventory logs of all media and conduct media inventories at least annually+. This low level of compliance could be because organizations see logging as a resource-intensive task that adds little value we disagree and organizations
that do maintain logs may forget about backups or USB devices containing CHD.
But surprisingly, 74.3% of organizations were compliant with 9.8 [Destroy media when it is no longer needed for business or legal reasons].
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entitys premises. A visitor refers to a vendor, guest of any onsite personnel, service workers, or
Requirement 9: Restrict physical access to cardholder data
9.1.1.c Verify that video cameras and/or access control mechanisms are monitored and
that data from cameras or other mechanisms is stored for at least three months.
NC 9.1.2 Interview responsible personnel and observe locations of publicly accessible
network jacks to verify that physical and/or logical controls are in place to restrict
access to publicly accessible network jacks.
NC 9.1.3 Verify that physical access to wireless access points, gateways, handheld devices,
networking/communications hardware, and telecommunication lines is appropriately
restricted.
9.2.a Review processes and procedures for assigning badges to onsite personnel and
visitors, and verify these processes include the following:
- Granting new badges,
- Changing access requirements, and
- Revoking terminated onsite personnel and expired visitor badges
9.2.b Verify that access to the badge system is limited to authorized personnel.
NC
9.2.c Examine badges in use to verify that they clearly identify visitors and it is easy to
distinguish between onsite personnel and visitors.
9.2.d Examine identification methods (such as ID badges) in use to verify that they
clearly identify visitors and it is easy to distinguish between onsite personnel and
visitors.
NC 9.3.a For a sample of onsite personnel with physical access to the CDE, interview
responsible personnel and observe access control lists to verify that:
-Access to the CDE is authorized.
-Access is required for the individuals job function.
9.3.b Observe personnel access the CDE to verify that all personnel are authorized
before being granted access.

9.3.c Select a sample of recently terminated employees and review access control lists
to verify the personnel do not have physical access to the CDE.
NC 9.4 Verify that visitor authorization and access controls are in place as follows:
9.4.1.a Observe procedures and interview personnel to verify that visitors must be
authorized before they are granted access to, and escorted at all times within, areas
where cardholder data is processed or maintained.
NC
NC
9.4.1.b Observe the use of visitor badges or other identification to verify that a physical
token badge does not permit unescorted access to physical areas where cardholder
data is processed or maintained.
9.4.2.a Observe people within the facility to verify the use of visitor badges or other
identification, and that visitors are easily distinguishable from onsite personnel.
9.4.2.b Verify that visitor badges or other identification expire.
NC
9.4.3 Observe visitors leaving the facility to verify visitors are asked to surrender their
badge or other identification upon departure or expiration.
9.4.4.a Verify that a visitor log is in use to record physical access to the facility as well as
computer rooms and data centers where cardholder data is stored or transmitted.
9.4.4.b Verify that the log contains:
-The visitors name,
- The firm represented, and
- The onsite personnel authorizing physical access.
9.4.4.c Verify that the log is retained for at least three months.
9.5 Verify that procedures for protecting cardholder data include controls for physically
securing all media (including but not limited to computers, removable electronic media,
paper receipts, paper reports, and faxes).
9.5.1.a Observe the storage locations physical security to confirm that backup media
storage is secure.
NC
NC
NC
C8.4
9.5.1.b Verify that the storage location security is reviewed at least annually.
9.6 Verify that a policy exists to control distribution of media, and that the policy covers
all distributed media including that distributed to individuals.
C8.4 9.6.1 Verify that all media is classified so the sensitivity of the data can be determined.
9.6.2.a Interview personnel and examine records to verify that all media sent
outside the facility is logged and sent via secured courier or other delivery
method that can be tracked.
9.6.2.b Select a recent sample of several days of offsite tracking logs for all media,
and verify tracking details are documented.
9.6.3 Select a recent sample of several days of offsite tracking logs for all media. From
examination of the logs and interviews with responsible personnel, verify proper
management authorization is obtained whenever media is moved from a secured area
(including when media is distributed to individuals).
NC 9.7 Verify that all media sent outside the facility is logged and authorized by
management and sent via secured courier or other delivery method that can be tracked.
NC
C8.4
NC 9.7.1 Select a recent sample of several days of offsite tracking logs for all media, and
verify the presence in the logs of tracking details and proper management
authorization.
NC 9.8 Examine the periodic media destruction policy and verify that it covers all media
and defines requirements for the following:
-Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there
is reasonable assurance the hard- copy materials cannot be reconstructed.
-Storage containers used for materials that are to be destroyed must be secured.
-Cardholder data on electronic media must be rendered unrecoverable via a secure
wipe program (in accordance with industry-accepted standards for secure deletion), or
by physically destroying the media.
NC 9.8.1.a Interview personnel and examine procedures to verify that hard-copy materials
are crosscut shredded, incinerated, or pulped such that there is reasonable assurance
the hard-copy materials cannot be reconstructed.
NC
9.8.1.b Examine storage containers used for materials that contain information
to be destroyed to verify that the containers are secured.
NC 9.8.2 Verify that cardholder data on electronic media is rendered unrecoverable via a
secure wipe program in accordance with industry-accepted standards for secure
deletion, or otherwise physically destroying the media).
9.9 Examine documented policies and procedures to verify they include:
-Maintaining a list of devices
-Periodically inspecting devices to look for tampering or substitution
- Training personnel to be aware of suspicious behavior and to report tampering or
substitution of devices
9.9.1.a Examine the list of devices to verify it includes:
-Make, model of device
-Location of device (for example, the address of the site or facility where the device is
located)
-Device serial number or other method of unique identification.
9.9.1.b Select a sample of devices from the list and observe device locations to verify
that the list is accurate and up to date.
9.9.1.c Interview personnel to verify the list of devices is updated when devices are
added, relocated, decommissioned, etc.
9.9.2.a Examine documented procedures to verify processes are defined to include the
following:
-Procedures for inspecting devices
-Frequency of inspections.
9.9.2.b Interview responsible personnel and observe inspection processes to verify:
-Personnel are aware of procedures for inspecting devices.
-All devices are periodically inspected for evidence of tampering and substitution.
9.9.3.a Review training materials for personnel at point-of-sale locations to verify they
include training in the following:
-Verifying the identity of any third-party persons claiming to be repair or maintenance
personnel, prior to granting them access to modify or troubleshoot devices
-Not to install, replace, or return devices without verification
-Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices)
-Reporting suspicious behavior and indications of device tampering or substitution to
appropriate personnel (for example, to a manager or security officer).
9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they have
received training and are aware of the procedures for the following:
-Verifying the identity of any third-party persons claiming to be repair or maintenance
personnel, prior to granting them access to modify or troubleshoot devices
-Not to install, replace, or return devices without verification
-Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices)
-Reporting suspicious behavior and indications of device tampering or substitution to
appropriate personnel (for example, to a manager or security officer).
9.10 Examine documentation and interview personnel to verify that security policies
and operational procedures for restricting physical access to cardholder data are:
-Documented,
-In use, and
-Known to all affected parties.
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A
Identify and briefly describe all of the following with systems in the cardholder data
environment:
All computer rooms
All data centers
Any other physical areas
<Report Findings Here>
For each area identified (add rows as needed), complete the following:
Describe the physical security controls to be in place, including authorized badges and
lock and key.
<Report Findings Here>
Identify the randomly selected systems in the cardholder environment for which a
system administrator login attempt was observed.
<Report Findings Here>
Describe how consoles for the randomly selected systems were observed to verify
that they are locked when not in use to prevent unauthorized use.
<Report Findings Here>
2
0
Describe the video cameras and/or access control mechanisms observed to monitor
the entry/exit points to sensitive areas.
<Report Findings Here>
2
0
Describe how the video cameras and/or access control mechanisms were observed to
be protected from tampering and/or disabling.
<Report Findings Here>
2
0
Major Observations from the 2014 Verizon Compliance Report:
Five of Requirement 9s subcontrols (9.1.3, 9.1.2, 9.3.3, 9.3.1 and 9.3.2.b) make it into our Top 20. These refer to restricting physical access to network hardware, and making sure all visitors are authorized (with specific controls before entering areas where CHD is processed or maintained). These achieve
between 86.1% and 91.1% compliance, showing that organizations are generally pretty strong on controlling physical access.
Just 66.3% of organizations were compliant with 9.9.1 *Properly maintain inventory logs of all media and conduct media inventories at least annually+. This low level of compliance could be because organizations see logging as a resource-intensive task that adds little value we disagree and organizations
that do maintain logs may forget about backups or USB devices containing CHD.
But surprisingly, 74.3% of organizations were compliant with 9.8 [Destroy media when it is no longer needed for business or legal reasons].
Selected Merchant Type:
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entitys premises. A visitor refers to a vendor, guest of any onsite personnel, service workers, or
Requirement 9: Restrict physical access to cardholder data
Describe how the video cameras and/or access control mechanisms were observed to
be monitored.
<Report Findings Here>
Describe how data from the cameras and/or access control mechanisms was
observed to be stored for at least three months.
<Report Findings Here>
2
0
Identify responsible personnel interviewed who confirm that physical and/or logical
controls are in place to restrict access to publicly accessible network jacks.
<Report Findings Here>
Describe the physical and/or logical controls observed at the locations of publicly
accessible network jacks to verify the controls are in place restrict access.
<Report Findings Here>
2
0
Describe how physical access was observed to be restricted to the following:
Wireless access points
Wireless gateways
Wireless handheld devices
Network/communications hardware
Telecommunication lines
<Report Findings Here>
2
0
Identify the documented processes reviewed to verify that procedures are defined
for identifying and distinguishing between onsite personnel and visitors, including the
following:
badges).
<Report Findings Here>
5 0
Describe how processes for identifying and distinguishing between onsite personnel
and visitors were observed to verify that:
Visitors are clearly identified, and
It is easy to distinguish between onsite personnel and visitors.
<Report Findings Here>
5 0
Identify the document that defines that access to the identification process is limited
to authorized personnel.
<Report Findings Here>
Describe how access to the identification process was observed to be limited to
authorized personnel.
<Report Findings Here>
5 0
Briefly describe the identification method in use for onsite personnel and visitors.
<Report Findings Here>
Describe how the identification methods were examined to verify that:
The identification method(s) clearly identify visitors.
It is easy to distinguish between onsite personnel and visitors.
<Report Findings Here>
5 0
Identify the sample of onsite personnel with physical access to the CDE interviewed
for this testing procedure.
<Report Findings Here>
For all items in the sample, describe how responsible personnel were interviewed and
access control lists observed to verify that:
Access to the CDE is authorized.
Access is required for the individuals job function.
<Report Findings Here>
5 0
Describe how personnel accessing the CDE were observed to verify that all personnel
are authorized before being granted access.
<Report Findings Here>
5 0
Identify the sample of users recently terminated.
<Report Findings Here>
For all items in the sample, provide the name of the assessor who attests that the
access control lists were reviewed to verify the personnel do not have physical access
to the CDE.
<Report Findings Here>
5 0
Not Provided by PCIco 5 0
Describe how visitor authorization processes were observed to verify that visitors:
is processed or maintained.
maintained.
<Report Findings Here>
Identify personnel interviewed who confirm that visitor authorization processes are
in place so that visitors must be authorized before they are granted access to, and
escorted at all times within, areas where cardholder data is processed or maintained.
<Report Findings Here>
5 0
Describe how the use of visitor badges or other identification was observed to verify
that a physical token badge does not permit unescorted access to physical areas
where cardholder data is processed or maintained.
<Report Findings Here>
5 0
Describe how people within the facility were observed to use visitor badges or other
identification.
<Report Findings Here>
Describe how visitors within the facility were observed to be easily distinguishable
from onsite personnel.
<Report Findings Here>
5 0
Describe how visitor badges or other identification were verified to expire
<Report Findings Here>
5 0
Describe how visitors leaving the facility were observed to verify they are asked to
surrender their badge or other identification upon departure or expiration.
<Report Findings Here>
5 0
Describe how it was verified that a visitor log is in use to record physical access to:
The facility.
Computer rooms and data centers where cardholder data is stored or transmitted.
<Report Findings Here>
5 0
Provide the name of the assessor who attests that the visitor log contains:
<Report Findings Here>
5 0
Identify the defined retention period for visitor logs.
<Report Findings Here>
Describe how visitor logs were observed to be retained for at least three months.
<Report Findings Here>
5 0
Identify the documented procedures for protecting cardholder data reviewed to
verify controls for physically securing all media are defined.
<Report Findings Here>
For all types of media used, describe the controls for physically securing the media
used.
<Report Findings Here>
5 1
Identify all locations where backup media is stored.
<Report Findings Here>
Describe how it was observed that backup media storage is stored in a secure
location.
<Report Findings Here>
5 0
Identify the document reviewed to verify that the storage location must be reviewed
at least annually.
<Report Findings Here>
Describe how processes were observed to verify that reviews of the security of each
storage location are performed at least annually.
<Report Findings Here>
5 0
Identify the documented policy to control distribution of media that was reviewed to
verify the policy covers all distributed media, including that distributed to individuals.
<Report Findings Here>
Describe how media distribution is controlled, including distribution to individuals.
<Report Findings Here>
5 1
Identify the documented policy reviewed to verify policy defines how media is
classified.
<Report Findings Here>
Describe how the classifications were observed to be implemented so the sensitivity
of the data can be determined.
<Report Findings Here>
5 1
Identify the personnel interviewed who confirm that all media sent outside the
facility is logged and sent via secured courier or other delivery method that can be
tracked.
<Report Findings Here>
Identify the record examined for this testing procedure.
<Report Findings Here>
Describe how offsite tracking records were examined to verify that all media is logged
and sent via secured courier or other delivery method that can be tracked.
<Report Findings Here>
5 1
Identify the sample of recent offsite tracking logs for all media selected.
<Report Findings Here>
For each item in the sample, describe how the offsite tracking logs were reviewed to
verify that tracking details are documented.
<Report Findings Here>
5 1
Identify responsible personnel interviewed who confirm that proper management
authorization is obtained whenever media is moved from a secured area (including
when media is distributed to individuals).
<Report Findings Here>
For each item in the sample in 9.6.2.b, describe how offsite tracking logs were
examined to verify proper management authorization is obtained whenever media is
moved from a secured area (including when media is distributed to individuals).
<Report Findings Here>
5 1
Identify the documented policy for controlling storage and maintenance of all media
that was reviewed to verify that the policy defines required periodic media
inventories.
<Report Findings Here>
5 1
Identify the media inventories logs reviewed.
<Report Findings Here>
Describe how the media inventory logs were reviewed to verify that:
<Report Findings Here>
Media inventory logs of all media were observed to be maintained.
Media inventories are performed at least annually.
<Report Findings Here>
5 1
Identify the policy document for periodic media destruction that was examined to
verify it covers all media and defines requirements for the following:
Hard-copy materials must be crosscut shredded, incinerated, or pulped such that
there is reasonable assurance the hard- copy materials cannot be reconstructed.
Storage containers used for materials that are to be destroyed must be secured.
Cardholder data on electronic media must be rendered unrecoverable via a secure
wipe program (in accordance with industry- accepted standards for secure deletion),
or by physically destroying the media.
<Report Findings Here>
5 1
IIdentify personnel interviewed who confirm that hard-copy materials are crosscut
shredded, incinerated, or pulped such that there is reasonable assurance the hard-
copy materials cannot be reconstructed.
<Report Findings Here>
Describe how the procedures were examined to verify that hard-copy materials are
crosscut shredded, incinerated, or pulped such that there is reasonable assurance
that hardcopy materials cannot be reconstructed.
<Report Findings Here>
5 1
Describe how the storage containers used for materials to be destroyed are secured.
<Report Findings Here> 1
1
Describe how cardholder data on electronic media is rendered unrecoverable, via
secure wiping of media and/or physical destruction of media.
<Report Findings Here>
If data is rendered unrecoverable via secure deletion or a secure wipe program,
identify the industry-accepted standards used.
<Report Findings Here>
1
0
Indicate whether this ROC is being completed prior to June 30, 2015. (yes/no)
<Report Findings Here>
If yes AND the assessed entity does not have this in place ahead of the
requirements effective date, mark 9.9 9.9.9.3.b as Not Applicable.
If not OR if the assessed entity has this in place ahead of the requirements effective
date, complete the following:
Identify the documented policies and procedures examined to verify they include:
tampering or substitution.
substitution of POS devices.
<Report Findings Here>
5
0
If yes at 9.9 AND the assessed entity does not have this in place ahead of the
requirements effective date, mark 9.9.1.a - 9.9.1.c as Not Applicable.
If not OR if the assessed entity has this in place ahead of the requirements effective
date, complete the following:
Identify the documented up-to-date list of devices examined to verify it includes:
is located).
<Report Findings Here>
5
0
Identify the sample of devices from the list selected for this testing procedure.
<Report Findings Here>
For all items in the sample, describe how the device locations for the sample of
devices was observed to verify that the list is accurate and up-to-date.
<Report Findings Here>
5
0
Identify personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify the list of
devices is updated when devices are added, relocated, decommissioned, etc.
<Report Findings Here>
5
0
If yes at 9.9 AND the assessed entity does not have this in place ahead of the
requirements effective date, mark 9.9.2.a - 9.9.2.b as Not Applicable.
If not OR if the assessed entity has this in place ahead of the requirements effective
date, complete the following:
Identify the documented procedures examined to verify that processes are defined to
include the following:
<Report Findings Here>
5 0
Identify responsible personnel interviewed who confirm that:
<Report Findings Here>
Describe how inspection processes were observed to verify that:
All devices are periodically inspected for evidence of tampering.
All devices are periodically inspected for evidence of substitution.
<Report Findings Here>
5 0
If yes at 9.9 AND the assessed entity does not have this in place ahead of the
requirements effective date, mark 9.9.3.a - 9.9.3.b as Not Applicable.
If not OR if the assessed entity has this in place ahead of the requirements effective
date, complete the following:
Identify the training materials for personnel at point-of-sale locations that were
reviewed to verify the materials include training in the following:
maintenance personnel, prior to granting them access to modify or troubleshoot
devices.
unknown persons to unplug or open devices).
or security officer).
<Report Findings Here>
5 0
Identify the sample of personnel at point-of- sale locations interviewed to verify they
have received training.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify interviewees
are aware of the procedures for the following:
Verifying the identity of any third-party persons claiming to be repair or maintenance
personnel, prior to granting them access to modify or troubleshoot devices.
<Report Findings Here>
Not to install, replace, or return devices without verification.
<Report Findings Here>
Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices).
<Report Findings Here>
Reporting suspicious behavior and indications of device tampering or substitution to
appropriate personnel (for example, to a manager or security officer).
<Report Findings Here>
5 0
Identify the document reviewed to verify that security policies and operational
procedures for restricting physical access to cardholder data are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for restricting physical access to
cardholder data are:
In use
Known to all affected parties
<Report Findings Here>
6 0
200 11
A-EP PE2P B B-IP C-VT C D S In Place? Severity
1 0 0 0 0 0 1 1
N 5
0 0 0 0 0 0 1 1
N 5
0 0 0 0 0 0 1 1
N 5
Selected Merchant Type: D
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entitys premises. A visitor refers to a vendor, guest of any onsite personnel, service workers, or
Requirement 9: Restrict physical access to cardholder data
0 0 0 0 0 0 1 1
N 5
0 0 0 1 0 1 1 1
N 5
0 0 0 0 0 0 1 1
N 5
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1
N 2
1 1 1 1 1 1 1 1
N 2
0 0 1 1 0 0 1 1
N 2
0 0 1 1 0 0 1 1
N 2
1 0 1 1 1 1 1 1
N 2
1 0 1 1 1 1 1 1
N 2
1 0 1 1 1 1 1 1
N 2
1 0 1 1 1 1 1 1
N 2
1 0 1 1 1 1 1 1
N 2
1 0 1 1 1 1 1 1
N 2
0 0 1 0 1 1 1 1
N 2
1 1 1 1 1 1 1 1
N 2
1 1 1 1 1 1 1 1
N 2
1 0 1 1 1 1 1 1
N 6
0 0 0 0 0 1 1 1
N 6
0 1 1 1 0 1 1 1
NT 2
0 1 1 1 0 1 1 1
NT 2
0 1 1 1 0 1 1 1
Y 0
0 1 1 1 0 1 1 1
Y 0
0 1 1 1 0 1 1 1
C 0
0 1 1 1 0 1 1 1
Y 0
0 1 1 1 0 1 1 1
Y 0
0 1 1 1 0 1 1 1
Y 0
0 1 0 0 0 0 1 1
Y 0
11 12 21 21 11 21 45 45 Y 102
N
C
NT
NA
Proofs /
Documentation links
Stage of implementation Remediation plan
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entitys premises. A visitor refers to a vendor, guest of any onsite personnel, service workers, or
Requirement 9: Restrict physical access to cardholder data
Estimated date for completion Comment
s
Owner
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entitys premises. A visitor refers to a vendor, guest of any onsite personnel, service workers, or
Requirement 9: Restrict physical access to cardholder data
Return to Table of content Go to requirement 9
PCI DSS Requirement Guidance
10.1 Implement audit trails to link all access to
system components to each individual user.
It is critical to have a process or system that links
user access to system components accessed. This
system generates audit logs and provides the
ability to trace back suspicious activity to a specific
user.
Major Observations from the 2014 Verizon PCI Compliance Report:
Organizations generally find enterprise log management hard, in terms of generating logs (covered in controls 10.1 and 10.2), protecting them (10.5), reviewing them (10.6), and archiving them (10.7). Furthermore, many of the controls within Requirement 10 are interdependent, and failing to comply with one
can have a knock-on effect on compliance with several others. But the trends are promising: in 2013 the average rose to 82.2% and 60.0% of organizations were fully compliant.
One of the most challenging parts of Requirement 10 appears to be control 10.4. This specifies that access to time data is restricted, external time signals are properly used, and that changes to time settings are logged, monitored, and reviewed. We found that just 49.5% of organizations were compliant with
all parts of this control between 2011 and 2013.
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
10.2 Implement automated audit trails for all system
components to reconstruct the following events:
Generating audit trails of suspect activities alerts
the system administrator, sends data to other
monitoring mechanisms (like intrusion detection
systems), and provides a history trail for post-
incident follow-up. Logging of the following events
enables an organization to identify and trace
potentially malicious activities.
10.2.1 All individual accesses to cardholder data Malicious individuals could obtain knowledge of a
user account with access to systems in the CDE, or
they could create a new, unauthorized account in
order to access cardholder data. A record of all
individual accesses to cardholder data can identify
which accounts may have been compromised or
misused.
10.2.2 All actions taken by any individual with root
or administrative privileges
Accounts with increased privileges, such as the
administrator or root account, have the
potential to greatly impact the security or
operational functionality of a system. Without a
log of the activities performed, an organization is
unable to trace any issues resulting from an
administrative mistake or misuse of privilege back
to the specific action and individual.
10.2.3 Access to all audit trails Malicious users often attempt to alter audit logs to
hide their actions, and a record of access allows an
organization to trace any inconsistencies or
potential tampering of the logs to an individual
account,
10.2.4 Invalid logical access attempts Malicious individuals will often perform multiple
access attempts on targeted systems. Multiple
invalid login attempts may be an indication of an
unauthorized users attempts to brute force or
guess a password.
10.2.6 Initialization of the audit logs Turning the audit logs off prior to performing illicit
activities is a common goal for malicious users
wishing to avoid detection. Initialization of audit
logs could indicate that the log function was
disabled by a user to hide their actions.
10.2.7 Creation and deletion of system-level
objects
Malicious software, such as malware, often
creates or replaces system level objects on the
target system in order to control a particular
function or operation on that system.
Please refer to the PCI DSS and PA-DSS Glossary of
Terms, Abbreviations, and Acronyms for
definitions of system-level objects.
10.3 Record at least the following audit trail entries
for all system components for each event:
10.3.1 User identification
10.3.2 Type of event
By recording these details for the auditable events
at 10.2, a potential compromise can be quickly
identified, and with sufficient detail to know who,
what, where, when, and how.
Without knowing who was logged on at the time
of an incident, it is impossible to identify the
accounts which may be used. Additionally,
malicious users may attempt to manipulate the
authentication controls with the intent of
bypassing them or impersonating a valid account.
Activities including, but not limited to, escalation
of privilege or changes to access permissions may
indicate unauthorized use of a systems
authentication mechanisms.
10.2.5 Use of identification and authentication
mechanisms including but not limited to
creation of new accounts and elevation of
privilegesand all changes, additions, or deletions
to accounts with root or administrative privileges
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system
component, or resource.
10.4 Using time-synchronization technology,
synchronize all critical system clocks and times and
ensure that the following is implemented for
acquiring, distributing, and storing time.
Note: One example of time synchronization
technology is Network Time Protocol (NTP).
By recording these details for the auditable events
at 10.2, a potential compromise can be quickly
identified, and with sufficient detail to know who,
what, where, when, and how.
10.4.1 Critical systems have the correct and
consistent time.
Time synchronization technology is used to
synchronize clocks on multiple systems. When
properly deployed, this technology can
synchronize clocks on large numbers of systems to
within a fraction of a second of each other. Some
problems that can occur when clocks are not
properly synchronized include but are not limited
to, making it difficult if not impossible to compare
log files from different systems and establish an
exact sequence of event (crucial for forensic
analysis in the event of a breach), and preventing
cryptographic protocols such as SSH that rely on
absolute time from functioning properly. For post-
incident forensics teams, the accuracy and
consistency of time across all systems and the
time of each activity is critical in determining how
the systems were compromised.
Note:
One example of time synchronization technology
is Network Time Protocol (NTP).
If a malicious individual has entered the network,
they will often attempt to change the time stamps
of their actions within the audit logs to prevent
detection of their activity. A malicious individual
may also try to directly change the clock on a
system component to hide their presence for
example, by changing the system clock to an
earlier time. For these reasons, it is important that
time is accurate on all systems and that time data
is protected against unauthorized access and
changes. Time data includes the parameters and
methods used to set each systems clock.
More information on NTP can be found at
www.ntp.org, including information about time,
time standards, and servers.
10.4.1 Critical systems have the correct and
consistent time.
10.4.2 Time data is protected.
Time synchronization technology is used to
synchronize clocks on multiple systems. When
properly deployed, this technology can
synchronize clocks on large numbers of systems to
within a fraction of a second of each other. Some
problems that can occur when clocks are not
properly synchronized include but are not limited
to, making it difficult if not impossible to compare
log files from different systems and establish an
exact sequence of event (crucial for forensic
analysis in the event of a breach), and preventing
cryptographic protocols such as SSH that rely on
absolute time from functioning properly. For post-
incident forensics teams, the accuracy and
consistency of time across all systems and the
time of each activity is critical in determining how
the systems were compromised.
Note:
One example of time synchronization technology
is Network Time Protocol (NTP).
If a malicious individual has entered the network,
they will often attempt to change the time stamps
of their actions within the audit logs to prevent
detection of their activity. A malicious individual
may also try to directly change the clock on a
system component to hide their presence for
example, by changing the system clock to an
earlier time. For these reasons, it is important that
time is accurate on all systems and that time data
is protected against unauthorized access and
changes. Time data includes the parameters and
methods used to set each systems clock.
More information on NTP can be found at
www.ntp.org, including information about time,
time standards, and servers.
10.4.3 Time settings are received from industry-
accepted time sources.
10.4.2 Time data is protected.
Time synchronization technology is used to
synchronize clocks on multiple systems. When
properly deployed, this technology can
synchronize clocks on large numbers of systems to
within a fraction of a second of each other. Some
problems that can occur when clocks are not
properly synchronized include but are not limited
to, making it difficult if not impossible to compare
log files from different systems and establish an
exact sequence of event (crucial for forensic
analysis in the event of a breach), and preventing
cryptographic protocols such as SSH that rely on
absolute time from functioning properly. For post-
incident forensics teams, the accuracy and
consistency of time across all systems and the
time of each activity is critical in determining how
the systems were compromised.
Note:
One example of time synchronization technology
is Network Time Protocol (NTP).
If a malicious individual has entered the network,
they will often attempt to change the time stamps
of their actions within the audit logs to prevent
detection of their activity. A malicious individual
may also try to directly change the clock on a
system component to hide their presence for
example, by changing the system clock to an
earlier time. For these reasons, it is important that
time is accurate on all systems and that time data
is protected against unauthorized access and
changes. Time data includes the parameters and
methods used to set each systems clock.
More information on NTP can be found at
www.ntp.org, including information about time,
time standards, and servers.
10.5 Secure audit trails so they cannot be altered. Often a malicious individual who has entered the
network will attempt to edit the audit logs in order
to hide their activity. Without adequate protection
of audit logs, their completeness, accuracy, and
integrity cannot be guaranteed, and the audit logs
can be rendered useless as an investigation tool
after a compromise.
10.5.1 Limit viewing of audit trails to those with a
job-related need.
10.5.2 Protect audit trail files from unauthorized
modifications.
10.5.3 Promptly back up audit trail files to a
centralized log server or media
that is difficult to alter.
Adequate protection of the audit logs includes
strong access control (limit access to logs based on
need to know only) and use of internal
segregation (to make the logs harder to find and
modify). By writing logs from external-facing
technologies such as wireless, firewalls, DNS, and
mail servers, the risk of those logs being lost or
altered is lowered, as they are more secure within
the internal network.
10.5.4 Write logs for external-facing technologies
onto a log server on the internal LAN.
By writing logs from external-facing technologies
such as wireless, firewalls, DNS, and mail servers,
the risk of those logs being lost or altered is
lowered, as they are more secure within the
internal network.
Logs may be written directly, or offloaded or
copied from external systems, to the secure
internal system or media.
10.5.5 Use file-integrity monitoring or 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).
File-integrity monitoring systems check for
changes to critical files, and notify when such
changes are noted. For file-integrity monitoring
purposes, an entity usually monitors files that
dont regularly change, but when changed indicate
a possible compromise. For log files (which do
change frequently) what should be monitored are,
for example, when a log file is deleted, suddenly
grows or shrinks significantly, and any other
indicators that a malicious individual has
tampered with a log file. There are both off-the-
shelf and open source tools available for file-
integrity monitoring.
10.6.1 Review the following at least daily:
All security events
Logs of all system components that store,
process, or transmit CHD and/or SAD, or that
could impact the security of CHD and/or SAD
Logs of all critical system components
Logs of all servers and system components that
perform security functions (for example, firewalls,
intrusion-detection systems/intrusion-prevention
systems (IDS/IPS), authentication servers, e-
commerce redirection servers, etc.).
Many breaches occur over days or months before
being detected. Checking logs daily minimizes the
amount of time and exposure of a potential
breach.
Daily review of security eventsfor example,
notifications or alerts that identify suspicious or
anomalous activitiesas well as logs from critical
system components, and logs from systems that
perform security functions, such as firewalls,
IDS/IPS, file-integrity monitoring (FIM) systems,
etc. is necessary to identify potential issues. Note
that the determination of security event will
vary for each organization and may include
consideration for the type of technology, location,
and function of the device. Organizations may also
wish to maintain a baseline of normal traffic to
help identify anomalous behavior.
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
accounting protocol (AAA) servers (for example,
RADIUS).
Note: Log harvesting, parsing, and alerting tools
may be used to meet compliance with Requirement
10.6.
Many breaches occur over days or months before
being detected. Checking logs daily minimizes the
amount of time and exposure of a potential
breach.
Regular log reviews by personnel or automated
means can identify and proactively address
unauthorized access to the cardholder data
environment.
The log review process does not have to be
manual. The use of log harvesting, parsing, and
alerting tools can help facilitate the process by
identifying log events that need to be reviewed.
Logs for all other system components should also
be periodically reviewed to identify indications of
potential issues or attempts to gain access to
sensitive systems via less-sensitive systems. The
frequency of the reviews should be determined by
an entitys annual risk assessment.
10.6.2 Review logs of all other system components
periodically based on the organizations policies
and risk management strategy, as determined by
the organizations annual risk assessment.
10.6.1 Review the following at least daily:
All security events
Logs of all system components that store,
process, or transmit CHD and/or SAD, or that
could impact the security of CHD and/or SAD
Logs of all critical system components
Logs of all servers and system components that
perform security functions (for example, firewalls,
intrusion-detection systems/intrusion-prevention
systems (IDS/IPS), authentication servers, e-
commerce redirection servers, etc.).
Many breaches occur over days or months before
being detected. Checking logs daily minimizes the
amount of time and exposure of a potential
breach.
Daily review of security eventsfor example,
notifications or alerts that identify suspicious or
anomalous activitiesas well as logs from critical
system components, and logs from systems that
perform security functions, such as firewalls,
IDS/IPS, file-integrity monitoring (FIM) systems,
etc. is necessary to identify potential issues. Note
that the determination of security event will
vary for each organization and may include
consideration for the type of technology, location,
and function of the device. Organizations may also
wish to maintain a baseline of normal traffic to
help identify anomalous behavior.
10.7 Retain audit trail history for at least one year,
with a minimum of three months immediately
available for analysis (for example, online, archived,
or restorable from back-up).
Retaining logs for at least a year allows for the fact
that it often takes a while to notice that a
compromise has occurred or is occurring, and
allows investigators sufficient log history to better
determine the length of time of a potential breach
and potential system(s) impacted. By having three
months of logs immediately available, an entity
can quickly identify and minimize impact of a data
breach. Storing back-up tapes off-site may result in
longer time frames to restore data, perform
analysis, and identify impacted systems or data.
If exceptions and anomalies identified during the log-
review process are not investigated, the entity may
be unaware of unauthorized and potentially
malicious activities that are occurring within their
own network.
10.6.3 Follow up exceptions and anomalies
identified during the review process.
10.8 Ensure that security policies and operational
procedures for monitoring all access to network
resources and cardholder data are documented, in
use, and known to all affected parties.
Personnel need to be aware of and following
security policies and daily operational procedures
for monitoring all access to network resources and
cardholder data on a continuous basis.
Go to requirement 11 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
C17.2 10.1 Verify, through observation and interviewing the system administrator, that:
-Audit trails are enabled and active for system components.
-Access to system components is linked to individual users.
Major Observations from the 2014 Verizon PCI Compliance Report:
Organizations generally find enterprise log management hard, in terms of generating logs (covered in controls 10.1 and 10.2), protecting them (10.5), reviewing them (10.6), and archiving them (10.7). Furthermore, many of the controls within Requirement 10 are interdependent, and failing to comply with one
can have a knock-on effect on compliance with several others. But the trends are promising: in 2013 the average rose to 82.2% and 60.0% of organizations were fully compliant.
One of the most challenging parts of Requirement 10 appears to be control 10.4. This specifies that access to time data is restricted, external time signals are properly used, and that changes to time settings are logged, monitored, and reviewed. We found that just 49.5% of organizations were compliant with
all parts of this control between 2011 and 2013.
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
C14.1
C14.6
10.2 Through interviews, examination of audit logs, and examination of audit log
settings, perform the following:
C.14.3 10.2.1 Verify all individual access to cardholder data is logged.
C12.9
C12.10
10.2.2 Verify actions taken by any individual with root or administrative privileges are
logged.
NC 10.2.3 Verify access to all audit trails is logged.
C14.3 10.2.4 Verify invalid logical access attempts are logged.
10.2.5 Verify use of identification and authentication mechanisms is logged.
10.2.5.b Verify all elevation of privileges is logged.
10.2.5.c Verify all changes, additions, or deletions to any account with root or
administrative privileges are logged.
NC 10.2.6 Verify initialization of audit logs is logged.
C.14.3 10.2.7 Verify creation and deletion of system level objects are logged.
C14.1 10.3 Through interviews and observation, for each auditable event (from 10.2),
perform the following:
NC 10.3.1 Verify user identification is included in log entries.
NC 10.3.2 Verify type of event is included in log entries.
NC
NC 10.3.3 Verify date and time stamp is included in log entries.
C14.3 10.3.4 Verify success or failure indication is included in log entries.
NC 10.3.5 Verify origination of event is included in log entries.
NC 10.3.6 Verify identity or name of affected data, system component, or resources is
included in log entries.
C.14.5 10.4 Examine configuration standards and processes to verify that time-
synchronization technology is implemented and kept current per PCI DSS Requirements
6.1 and 6.2.
C6.5 10.4.1.a Examine the process for acquiring, distributing and storing the correct time
within the organization to verify that:
-Only the designated central time server(s) receives time signals from external sources,
and time signals from external sources are based on International Atomic Time or UTC.
-Where there is more than one designated time server, the time servers peer with one
another to keep accurate time,
- Systems receive time information only from designated central time server(s).
10.4.1.b Observe the time-related system-parameter settings for a sample of system
components to verify:
-Only the designated central time server(s) receives time signals from external sources,
and time signals from external sources are based on International Atomic Time or UTC.
-Where there is more than one designated time server, the designated central time
server(s) peer with one another to keep accurate time.
- Systems receive time only from designated central time server(s).
NC 10.4.2.a Examine system configurations and time- synchronization settings to verify
that access to time data is restricted to only personnel with a business need to access
time data.
10.4.2.b Examine system configurations, time synchronization settings and logs, and
processes to verify that any changes to time settings on critical systems are logged,
monitored, and reviewed.
C14.5 10.4.3 Examine systems configurations to verify that the time server(s) accept time
updates from specific, industry-accepted external sources (to prevent a malicious
individual from changing the clock). Optionally, those updates can be encrypted with a
symmetric key, and access control lists can be created that specify the IP addresses of
client machines that will be provided with the time updates (to prevent unauthorized
use of internal time servers).
C14.2.1
C14.7
10.5 Interview system administrator and examine permissions to verify that audit trails
are secured so that they cannot be altered as follows:
NC 10.5.1 Verify that only individuals who have a job-related need can view audit trail files.
C14.7 10.5.2 Verify that current audit trail files are protected from unauthorized
modifications via access control mechanisms, physical segregation, and/or network
segregation.
C14.2.1 10.5.3 Verify that current audit trail files are promptly backed up to a centralized log
server or media that is difficult to alter.
C14.7 10.5.4 Verify that logs for external-facing technologies (for example, wireless, firewalls,
DNS, mail) are offloaded or copied onto a secure centralized internal log server or
media.
NC 10.5.5 Examine system settings, monitored files, and results from monitoring activities
to verify the use of file-integrity monitoring or change-detection software on logs.
10.6.1.a Examine security policies and procedures to verify that procedures are defined
for reviewing the following at least daily, either manually or via log tools:
-All security events
-Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD
-Logs of all critical system components
-Logs of all servers and system components that perform security functions (for
example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS),
authentication servers, e-commerce redirection servers, etc.)
C14.4
C14.6
Not povided by PCIco
10.6.1.b Observe processes and interview personnel to verify that the following are
reviewed at least daily:
-All security events
-Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD
-Logs of all critical system components
-Logs of all servers and system components that perform security functions (for
example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS),
authentication servers, e-commerce redirection servers, etc.).
10.6.2.a Examine security policies and procedures to verify that procedures are defined
for reviewing logs of all other system components periodicallyeither manually or via
log toolsbased on the organizations policies and risk management strategy.
10.6.2.b Examine the organizations risk-assessment documentation and interview
personnel to verify that reviews are performed in accordance with organizations
policies and risk management strategy.
10.6.3.a Examine security policies and procedures to verify that procedures are defined
for following up on exceptions and anomalies identified during the review process.
10.6.3.b Observe processes and interview personnel to verify that follow-up to
exceptions and anomalies is performed.
10.7.a Examine security policies and procedures to verify that they define the following:
-Audit log retention policies
- Procedures for retaining audit logs for at least one year, with a minimum of three
months immediately available online.
10.7.b Interview personnel and examine audit logs to verify that audit logs are available
for at least one year.
10.7.c Interview personnel and observe processes to verify that at least the last three
months logs can be immediately restored for analysis.
NC
10.8 Examine documentation interview personnel to verify that security policies and
operational procedures for monitoring all access to network resources and cardholder
data are:
-Documented,
- In use, and
-Known to all affected parties.
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priority A A-EP
Identify the system administrator(s) interviewed who confirm that:
Audit trails are enabled and active for system components.
Access to system components is linked to individual users.
<Report Findings Here>
Describe how audit trails were observed to verify the following:
Audit trails are enabled and active for system components.
Access to system components is linked to individual users.
<Report Findings Here>
4
0 0
Major Observations from the 2014 Verizon PCI Compliance Report:
Organizations generally find enterprise log management hard, in terms of generating logs (covered in controls 10.1 and 10.2), protecting them (10.5), reviewing them (10.6), and archiving them (10.7). Furthermore, many of the controls within Requirement 10 are interdependent, and failing to comply with one
can have a knock-on effect on compliance with several others. But the trends are promising: in 2013 the average rose to 82.2% and 60.0% of organizations were fully compliant.
One of the most challenging parts of Requirement 10 appears to be control 10.4. This specifies that access to time data is restricted, external time signals are properly used, and that changes to time settings are logged, monitored, and reviewed. We found that just 49.5% of organizations were compliant with
all parts of this control between 2011 and 2013.
Selected Merchant Type
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
Identify the responsible personnel interviewed who confirm the following from
10.2.1-10.2.7 are logged:
All individual access to cardholder data.
All actions taken by any individual with root or administrative privileges.
Access to all audit trails.
All actions taken by any individual with root or administrative privileges.
Use of identification and authentication mechanisms.
All elevation of privileges.
All changes, additions, or deletions to any
account with root or administrative privileges.
Initialization of audit logs.
Stopping or pausing of audit logs.
Creation and deletion of system level objects.
<Report Findings Here>
Identify the sample of audit logs observed to verify the following from 10.2.1-10.2.7
are logged:
All individual access to cardholder data.
All actions taken by any individual with root or administrative privileges.
Access to all audit trails.
All actions taken by any individual with root or administrative privileges.
Use of identification and authentication mechanisms.
All elevation of privileges.
All changes, additions, or deletions to any
account with root or administrative privileges.
Initialization of audit logs.
Stopping or pausing of audit logs.
Creation and deletion of system level objects.
<Report Findings Here>
4
0 1
For all items in the sample at 10.2, describe how configuration settings were
observed to verify all individual access to cardholder data is logged.
<Report Findings Here>
4
0 0
For all items in the sample at 10.2, describe how configuration settings were
observed to verify all actions taken by any individual with root or administrative
privileges are logged.
<Report Findings Here>
4
0 1
For all items in the sample at 10.2, describe how configuration settings were
observed to verify access to all audit trails is logged.
<Report Findings Here>
4
0 0
For all items in the sample at 10.2, describe how configuration settings were
observed to verify invalid logical access attempts are logged.
<Report Findings Here>
4
0 1
For all items in the sample at 10.2, describe how configuration settings were
observed to verify use of identification and authentication mechanisms is logged.
<Report Findings Here>
4
0 1
For all items in the sample at 10.2, describe how configuration settings were
observed to verify all elevation of privileges is logged.
<Report Findings Here>
4
0 1
For all items in the sample at 10.2, describe how configuration settings were
observed to verify all changes, additions, or deletions to any account with root or
administrative privileges are logged.
<Report Findings Here>
4
0 1
For all items in the sample at 10.2, describe how configuration settings were
observed to verify initialization of audit logs is logged.
<Report Findings Here>
4
0 0
For all items in the sample at 10.2, describe how configuration settings were
observed to verify creation and deletion of system level objects are logged.
<Report Findings Here>
4
0 0
Identify the responsible personnel interviewed who confirm that for each auditable
event from 10.2.1-10.2.7, the following are included in log entries:
User identification
Type of event
Date and time
Success or failure indication
Origination of event
<Report Findings Here>
Identify the sample of audit logs from 10.2.1- 10.2.7 observed to verify the following
are included in log entries:
<Report Findings Here>
4
0 1
For all logs in the sample at 10.3, describe how the audit logs were observed to verify
user identification is included in log entries.
<Report Findings Here>
4
0 1
For all logs in the sample at 10.3, describe how the audit logs were observed to verify
type of event is included in log entries.
<Report Findings Here>
4
0 1
For all logs in the sample at 10.3, describe how the audit logs were observed to verify
date and time stamp is included in log entries.
<Report Findings Here> 4
0 1
For all logs in the sample at 10.3, describe how the audit logs were observed to verify
success or failure indication is included in log entries.
<Report Findings Here>
4
0 1
For all logs in the sample at 10.3, describe how event is included in log entries. the
audit logs were observed to verify origination of event is included in log entries.
<Report Findings Here>
4
0 1
For all logs in the sample at 10.3, describe how the audit logs were observed to verify
the identity or name of affected data, system component, or resource is included in
log entries.
<Report Findings Here>
4
0 1
Identify the time synchronization technologies in use. (If NTP, include version)
<Report Findings Here>
Identify the documented time-synchronization process that defines processes for
ensuring the time synchronization technologies are kept current per PCI DSS
Requirements 6.1 and 6.2.
<Report Findings Here>
Describe how processes were examined to verify that time synchronization
technologies are:
Implemented.
Kept current, per the documented process.
<Report Findings Here>
4
0 0
Identify the documented process for acquiring, distributing, and storing the correct
time within the organization examined to verify that the process defines the
following:
Only the designated central time server(s) receive time signals from external sources,
and time signals from external sources are based on International Atomic Time or
UTC.
Where there is more than one designated time server, the time servers peer with one
another to keep accurate time.
Systems receive time information only from designated central time server(s).
<Report Findings Here>
4
0 0
Identify the sample of system components selected for 10.4.1.b-10.4.2.b
<Report Findings Here>
For all items in the sample, describe how the time-related system-parameter settings
for the sample of system components were observed to verify:
Only the designated central time server(s) receive time signals from external sources,
and time signals from external sources are based on International Atomic Time or
UTC.
<Report Findings Here>
Where there is more than one designated time server, the designated central time
server(s) peer with one another to keep accurate time.
<Report Findings Here>
Systems receive time only from designated central time server(s).
<Report Findings Here>
4
0 0
Identify the documented time-synchronization procedures examined to verify
procedures define that:
Access to time data is restricted to only personnel with a business need to access
time data.
Define which personnel have a business need to access time data.
<Report Findings Here>
Identify the authorized personnel interviewed who confirm that personnel with
access to time data have a business need to access time data.
<Report Findings Here>
For all items in the sample from 10.4.1, describe how configuration settings were
examined to restrict access to time data to only personnel with a documented need.
<Report Findings Here>
4
0 0
Identify the documented time-synchronization procedures examined to verify
procedures define that changes to time settings on critical systems must be:
Logged
Monitored
Reviewed
<Report Findings Here>
For all items in the sample from 10.4.1, describe how configuration settings on the
sampled system components were examined to log any changes to time settings on
critical systems.
<Report Findings Here>
For all items in the sample from 10.4.1, describe how logs were examined to log any
changes to time settings on critical systems.
<Report Findings Here>
Describe how time synchronization processes were examined to verify changes to
time settings on critical systems are:
Logged
Monitored
Reviewed
<Report Findings Here>
4
0 0
Identify the document reviewed to verify it defines that:
Time settings are configured to either accept time updates from specific, industry-
accepted time sources; OR
The updates are encrypted with a symmetric key and access control lists specify the
IP addresses of client machines that will be provided with the time updates.
<Report Findings Here>
Identify the sample of time servers selected.
<Report Findings Here>
For all items in the sample, describe how configuration settings were examined to
verify either of the following:
<Report Findings Here>
That the time servers receive time updates from specific, industry-accepted external
sources. OR
<Report Findings Here>
That time updates are encrypted with a symmetric key, and access control lists
specify the IP addresses of client machines.
<Report Findings Here>
Identify the industry-accepted time source indicated (if applicable).
<Report Findings Here>
4
0 0
Identify the system administrators interviewed who confirm that audit trails are
secured so that they cannot be altered as follows (from 10.5.1- 10.5.5):
Only individuals who have a job-related need can view audit trail files.
Current audit trail files are protected from unauthorized modifications via access
control mechanisms, physical segregation, and/or network segregation.
Current audit trail files are promptly backed up to a centralized log server or media
that is difficult to alter, including:
That current audit trail files are promptly backed up to the centralized log server or
media
The frequency that audit trail files are backed up
That the centralized log server or media is difficult to alter
Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are
written onto a secure, centralized, internal log server or media.
Use file-integrity monitoring or change- detection software on logs to ensure that
existing log data cannot be changed without generating alerts.
<Report Findings Here>
Identify the sample of system components selected for this testing procedure from
10.5.1- 10.5.5.
<Report Findings Here>
4
0 0
For each item in the sample at 10.5, describe how system configurations and
permissions were examined to verify they restrict viewing of audit trail files to only
individuals who have a documented job-related need.
<Report Findings Here>
4
0 0
For each item in the sample at 10.5, describe how system configurations and
permissions were examined to verify that current audit trail files are protected from
unauthorized modifications. (e.g., via access control mechanisms, physical
segregation, and/or network segregation).
<Report Findings Here>
4
0 0
For each item in the sample at 10.5, describe how system configurations and
permissions were examined to verify that current audit trail files are promptly backed
up to a centralized log server or media that is difficult to alter.
<Report Findings Here>
Identify and briefly describe the following:
The centralized log server or media to which audit trail files are backed up.
<Report Findings Here>
How frequently the audit trail files are backed up, and how the frequency is
appropriate.
<Report Findings Here>
How the centralized log server or media is difficult to alter.
<Report Findings Here>
4
0 0
For each item in the sample at 10.5, describe how system configurations and
permissions were examined to verify that logs for external- facing technologies are
written onto a secure, centralized, internal log server or media.
<Report Findings Here>
Describe how logs for external-facing technologies are written onto a secure
centralized internal log server or media
<Report Findings Here>.
4
0 1
For each item in the sample at 10.5, describe how the following were examined to
verify the use of file-integrity monitoring or change-detection software on logs:
System settings
Monitored files
Results from monitoring activities
Identify the file-integrity monitoring (FIM) or change-detection software verified to
be in use.
<Report Findings Here>
4
0 0
Identify the documented security policies and procedures examined to verify that
procedures define reviewing the following at least daily, either manually or via log
tools:
All security events.
Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD.
Logs of all critical system components.
Logs of all servers and system components that perform security functions.
<Report Findings Here>
Describe the manual or log tools used for daily review of logs.
<Report Findings Here>
4
0 0
1 Not provided by PCIco
4
0
Identify the personnel interviewed who confirm that the following are reviewed at
least daily:
All security events.
Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD.
Logs of all critical system components.
Logs of all servers and system components that perform security functions.
<Report Findings Here>
Describe how processes were observed to verify that the following are reviewed at
least daily:
All security events.
<Report Findings Here>
Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD.
<Report Findings Here>
Logs of all critical system components.
<Report Findings Here>
Logs of all servers and system components that perform security functions.
<Report Findings Here>
4
0 1
Identify the documented security policies and procedures examined to verify that
procedures define reviewing logs of all other system components periodicallyeither
manually or via log toolsbased on the organizations policies and risk management
strategy.
<Report Findings Here>
Describe the manual or log tools defined for periodic review of logs of all other
system components.
<Report Findings Here>
4
0 0
Identify the organizations risk assessment documentation examined to verify that
reviews are performed in accordance with the organizations policies and risk
management strategy.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify that reviews
are performed in accordance with the organizations policies and risk management
strategy.
<Report Findings Here>
4
0 1
Identify the documented security policies and procedures examined to verify that
procedures define following up on exceptions and anomalies identified during the
review process.
<Report Findings Here>
4
0 0
Describe how processes were observed to verify that follow-up to exceptions and
anomalies is performed.
<Report Findings Here>
Identify the personnel interviewed who confirm that follow-up to exceptions and
anomalies is performed.
<Report Findings Here>
4
0 0
Identify the documented security policies and procedures examined to verify that
procedures define the following:
Audit log retention policies.
Procedures for retaining audit logs for at least one year, with a minimum of three
months immediately available online.
<Report Findings Here>
4
0 0
Identify the personnel interviewed who confirm that audit logs are available for at
least one year.
<Report Findings Here>
Describe how the audit logs were examined to verify that audit logs are available for
at least one year.
<Report Findings Here>
4
0 1
Identify the personnel interviewed who confirm that at least the last three months
logs can be immediately restored for analysis.
<Report Findings Here>
Describe the processes observed to verify that at least the last three months logs can
be immediately restored for analysis.
<Report Findings Here>
4
0 1
Identify the document reviewed to verify that security policies and operational
procedures for monitoring all access to network resources and cardholder data are
documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for monitoring all access to network
resources and cardholder data are:
In use
Known to all affected parties
<Report Findings Here>
6
0 0
166 0 19
PE2P B B-IP C-VT C D S In Place? Severity Proofs /
Documentation links
0 0 0 0 0 1 1
NA 0
Selected Merchant Type D
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
0 0 0 0 1 1 1
NA 0
0 0 0 0 0 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 0 1 1
N 3
0 0 0 0 1 1 1
Y 0
0 0 1 1
N 3
0 0 1
0 0 0 0 1 1 1
Y 0
0 0 0 0 1 1 1
Y 0
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
NT 3
0 0 0 0 1 1 1
NA 0
0 0 0 0 0 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 1 0 1 0 1 1
NT 1
0 1 0 1 22 41 41 Y 103
N
C
NT
NA
Stage of implementation Remediation plan
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
Estimated date for completion Comments Owner
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
Return to Table of content Go to requriement 10
PCI DSS Requirement Guidance
Implementation and/or exploitation of wireless
technology within a network is one of the most
common paths for malicious users to gain access to
the network and cardholder data. If a wireless device
or network is installed without a companys
knowledge, it can allow an attacker to easily and
invisibly enter the network.
Unauthorized wireless devices may be hidden within
or attached to a computer or other system
component, or be attached directly to a network
port or network device, such as a switch or router.
Any such unauthorized device could result in an
unauthorized access point into the environment.
Due to the ease with which a wireless access point
can be attached to a network, the difficulty in
detecting their presence, and the increased risk
presented by unauthorized wireless devices, these
processes must be performed even when a policy
exists prohibiting the use of wireless technology.
The size and complexity of a particular environment
will dictate the appropriate tools and processes to
be used to provide sufficient assurance that a rogue
wireless access point has not been installed in the
environment.
For example: In the case of a single standalone retail
kiosk in a shopping mall, where all communication
components are contained within tamper-resistant
and tamper-evident casings, performing a detailed
physical inspection of the kiosk itself may be
sufficient to provide assurance that a rogue wireless
access point has not been attached or installed.
However, in an environment with multiple nodes
(such as in a large retail store, call centre, server
room or data center), it becomes more difficult to
perform a detailed physical inspection due to the
number of system components and network points
where a rogue wireless access device could be
installed or hidden. In this case, multiple methods
may be combined to meet the requirement, such as
performing physical system inspections in
conjunction with the results of a wireless analyzer.
Network access control (NAC) solutions can perform
device authentication and configuration
management to prevent unauthorized systems
connecting to the network, or unauthorized devices
connecting to authorized systems on the network.
An organization should have, as part of its incident
response plan, documented procedures to follow in
the event an unauthorized wireless access point is
detected. A wireless IDS/IPS should be configured to
automatically generate an alert, but the plan must
also document response procedures if an
unauthorized device is detected during a manual
wireless scan.
Requirement 11: Regularly test security systems and processes.
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment
11.1 Implement processes to test for the presence of
wireless access points (802.11), and detect and
identify all authorized and unauthorized wireless
access points on a quarterly basis.
Note: Methods that may be used in the process
include but are not limited to wireless network
scans, physical/logical inspections of system
components and infrastructure, network access
control (NAC), or wireless IDS/IPS. Whichever
methods are used, they must be sufficient to detect
and identify any unauthorized devices.
Major observations from the 2014 Verizon PCI Compliance Report:
Requirement 11 was the least complied-with requirement in our study. Just 23.8% of companies met all the controls between 2011 and 2013.
Controls and subcontrols where we saw the lowest compliance between 2011 and 2013 were:
11.3.a*Examinetheresultsfromthemostrecentpenetrationtesttoverifythatpenetration
testing is performed at least annually], 39.6%
11.3.b*Verifythatnotedexploitablevulnerabilitieswerecorrectedandtestingrepeated+,43.6% 11.2.1.a*Reviewthescanreportsandverifythatfourquarterlyinternalscanswereperformedin
the most recent 12-month period], 45.5%
11.1.1 Maintain an inventory of authorized
wireless access points including a documented
business justification.
11.2 Run internal and external network vulnerability
scans at least quarterly and after any significant
change in the network (such as new system
A vulnerability scan is an automated tool run against
external and internal network devices and servers,
designed to expose potential vulnerabilities in
11.1.2 Implement incident response procedures in
the event unauthorized wireless access points are
detected.
Implementation and/or exploitation of wireless
technology within a network is one of the most
common paths for malicious users to gain access to
the network and cardholder data. If a wireless device
or network is installed without a companys
knowledge, it can allow an attacker to easily and
invisibly enter the network.
Unauthorized wireless devices may be hidden within
or attached to a computer or other system
component, or be attached directly to a network
port or network device, such as a switch or router.
Any such unauthorized device could result in an
unauthorized access point into the environment.
Due to the ease with which a wireless access point
can be attached to a network, the difficulty in
detecting their presence, and the increased risk
presented by unauthorized wireless devices, these
processes must be performed even when a policy
exists prohibiting the use of wireless technology.
The size and complexity of a particular environment
will dictate the appropriate tools and processes to
be used to provide sufficient assurance that a rogue
wireless access point has not been installed in the
environment.
For example: In the case of a single standalone retail
kiosk in a shopping mall, where all communication
components are contained within tamper-resistant
and tamper-evident casings, performing a detailed
physical inspection of the kiosk itself may be
sufficient to provide assurance that a rogue wireless
access point has not been attached or installed.
However, in an environment with multiple nodes
(such as in a large retail store, call centre, server
room or data center), it becomes more difficult to
perform a detailed physical inspection due to the
number of system components and network points
where a rogue wireless access device could be
installed or hidden. In this case, multiple methods
may be combined to meet the requirement, such as
performing physical system inspections in
conjunction with the results of a wireless analyzer.
Network access control (NAC) solutions can perform
device authentication and configuration
management to prevent unauthorized systems
connecting to the network, or unauthorized devices
connecting to authorized systems on the network.
An organization should have, as part of its incident
response plan, documented procedures to follow in
the event an unauthorized wireless access point is
detected. A wireless IDS/IPS should be configured to
automatically generate an alert, but the plan must
also document response procedures if an
unauthorized device is detected during a manual
wireless scan.
11.2.1 Perform quarterly internal vulnerability
scans.
11.1 Implement processes to test for the presence of
wireless access points (802.11), and detect and
identify all authorized and unauthorized wireless
access points on a quarterly basis.
Note: Methods that may be used in the process
include but are not limited to wireless network
scans, physical/logical inspections of system
components and infrastructure, network access
control (NAC), or wireless IDS/IPS. Whichever
methods are used, they must be sufficient to detect
and identify any unauthorized devices.
An established process for identifying vulnerabilities
on internal systems within the CDE requires that
vulnerability scans be conducted quarterly.
Identifying and addressing vulnerabilities in a timely
manner reduces the likelihood of a vulnerability
being exploited and potential compromise of a
system component or cardholder data.
Vulnerabilities posing the greatest risk to the
environment (for example, ranked High per
Requirement 6.2) should be resolved with the
highest priority.
As internal networks may be constantly changing
during the year, it is possible that an entity may not
have consistently clean internal vulnerability scans.
The intent is for an entity to have a robust
vulnerability management program in place to
resolve noted vulnerabilities in a reasonable
timeframe. At minimum, High vulnerabilities must
be addressed in a timely fashion.
Internal vulnerability scans can be performed by
qualified, internal staff that are reasonably
independent of the system component(s) being
scanned (for example, a firewall administrator
should not be responsible for scanning the firewall),
or an entity may choose to have internal
vulnerability scans performed by a PCI SSC Approved
Scanning Vendor (ASV), QSA or other firm
specializing in vulnerability scanning.
11.2.2 Perform quarterly external vulnerability
scans via an Approved Scanning Vendor (ASV),
approved by the Payment Card Industry Security
Standards Council (PCI SSC).
Note: Quarterly external vulnerability scans must
be performed by an Approved Scanning Vendor
(ASV), approved by the Payment Card Industry
Security Standards Council (PCI SSC). Scans
conducted after
network changes may be performed by internal
staff.
11.2.1 Perform quarterly internal vulnerability
scans.
An established process for identifying vulnerabilities
on internal systems within the CDE requires that
vulnerability scans be conducted quarterly.
Identifying and addressing vulnerabilities in a timely
manner reduces the likelihood of a vulnerability
being exploited and potential compromise of a
system component or cardholder data.
Vulnerabilities posing the greatest risk to the
environment (for example, ranked High per
Requirement 6.2) should be resolved with the
highest priority.
As internal networks may be constantly changing
during the year, it is possible that an entity may not
have consistently clean internal vulnerability scans.
The intent is for an entity to have a robust
vulnerability management program in place to
resolve noted vulnerabilities in a reasonable
timeframe. At minimum, High vulnerabilities must
be addressed in a timely fashion.
Internal vulnerability scans can be performed by
qualified, internal staff that are reasonably
independent of the system component(s) being
scanned (for example, a firewall administrator
should not be responsible for scanning the firewall),
or an entity may choose to have internal
vulnerability scans performed by a PCI SSC Approved
Scanning Vendor (ASV), QSA or other firm
specializing in vulnerability scanning.
As external networks are at greater risk of
compromise, quarterly external vulnerability
scanning must be performed by a PCI SSC Approved
Scanning Vendor (ASV).
ASVs are required to follow a set of scanning and
reporting criteria set forth by the PCI SSC in the
Approved Scanning Vendor Program Guide
List of approved scanning vendors
11.2.2 Perform quarterly external vulnerability
scans via an Approved Scanning Vendor (ASV),
approved by the Payment Card Industry Security
Standards Council (PCI SSC).
Note: Quarterly external vulnerability scans must
be performed by an Approved Scanning Vendor
(ASV), approved by the Payment Card Industry
Security Standards Council (PCI SSC). Scans
conducted after
network changes may be performed by internal
staff.
11.2.3 Perform internal and external scans after
any significant change.
Note: Scans conducted after changes may be
performed by internal staff.
As external networks are at greater risk of
compromise, quarterly external vulnerability
scanning must be performed by a PCI SSC Approved
Scanning Vendor (ASV).
ASVs are required to follow a set of scanning and
reporting criteria set forth by the PCI SSC in the
Approved Scanning Vendor Program Guide
List of approved scanning vendors
Scanning an environment after any significant
changes are made ensures that changes were
completed appropriately such that the security of
the environment was not compromised as a result of
the change. It may not be necessary to scan the
entire environment after a change. However, all
system components affected by the change will
need to be scanned.
11.3 Implement a methodology for penetration
testing that includes the following:
-Is based on industry-accepted penetration testing
approaches (for example, NIST SP800-115)
-Includes coverage for the entire CDE perimeter and
critical systems
-Includes testing from both inside and outside the
network
-Includes testing to validate any segmentation and
scope-reduction controls
-Defines application-layer penetration tests to
include, at a minimum, the vulnerabilities listed in
Requirement 6.5
-Defines network-layer penetration tests to include
components that support network functions as well
as operating systems
-Includes review and consideration of threats and
vulnerabilities experienced in the last 12 months
-Specifies retention of penetration testing results
and remediation activities results.
The intent of a penetration test is to simulate a real-
world attack situation with a goal of identifying how
far an attacker would be able to penetrate into an
environment. This allows an entity to gain a better
understanding of their potential exposure and
develop a strategy to defend against attacks.
A penetration test differs from a vulnerability scan,
as a penetration test is an active process that may
include exploiting identified vulnerabilities.
Conducting a vulnerability scan may be one of the
first steps a penetration tester will perform in order
to plan the testing strategy, although it is not the
only step. Even if a vulnerability scan does not
detect known vulnerabilities, the penetration tester
will often gain enough knowledge about the system
to identify possible security gaps.
Penetration testing is generally a highly manual
process. While some automated tools may be used,
the tester uses their knowledge of systems to
penetrate into an environment. Often the tester will
chain several types of exploits together with a goal
of breaking through layers of defenses. For example,
if the tester finds a means to gain access to an
application server, they will then use the
compromised server as a point to stage a new attack
based on the resources the server has access to. In
this way, a tester is able to simulate the methods
performed by an attacker to identify areas of
potential weakness in the environment.
Penetration testing conducted on a regular basis and
after significant changes to the environment is a
proactive security measure that helps minimize
potential access to the CDE by malicious individuals.
The determination of what constitutes a significant
upgrade or modification is highly dependent on the
configuration of a given environment. If an upgrade
or modification could allow access to cardholder
data or affect the security of the cardholder data
environment, then it could be considered significant.
Performing penetration tests after network
upgrades and modifications provides assurance that
the controls assumed to be in place are still working
effectively after the upgrade or modification.
11.3.1 Perform external penetration testing at
least annually and after any significant
infrastructure or application upgrade or
modification (such as an operating system
upgrade, a sub-network added to the
environment, or a web server added to the
environment).
11.3 Implement a methodology for penetration
testing that includes the following:
-Is based on industry-accepted penetration testing
approaches (for example, NIST SP800-115)
-Includes coverage for the entire CDE perimeter and
critical systems
-Includes testing from both inside and outside the
network
-Includes testing to validate any segmentation and
scope-reduction controls
-Defines application-layer penetration tests to
include, at a minimum, the vulnerabilities listed in
Requirement 6.5
-Defines network-layer penetration tests to include
components that support network functions as well
as operating systems
-Includes review and consideration of threats and
vulnerabilities experienced in the last 12 months
-Specifies retention of penetration testing results
and remediation activities results.
The intent of a penetration test is to simulate a real-
world attack situation with a goal of identifying how
far an attacker would be able to penetrate into an
environment. This allows an entity to gain a better
understanding of their potential exposure and
develop a strategy to defend against attacks.
A penetration test differs from a vulnerability scan,
as a penetration test is an active process that may
include exploiting identified vulnerabilities.
Conducting a vulnerability scan may be one of the
first steps a penetration tester will perform in order
to plan the testing strategy, although it is not the
only step. Even if a vulnerability scan does not
detect known vulnerabilities, the penetration tester
will often gain enough knowledge about the system
to identify possible security gaps.
Penetration testing is generally a highly manual
process. While some automated tools may be used,
the tester uses their knowledge of systems to
penetrate into an environment. Often the tester will
chain several types of exploits together with a goal
of breaking through layers of defenses. For example,
if the tester finds a means to gain access to an
application server, they will then use the
compromised server as a point to stage a new attack
based on the resources the server has access to. In
this way, a tester is able to simulate the methods
performed by an attacker to identify areas of
potential weakness in the environment.
11.3.2 Perform internal penetration testing at
least annually and after any significant
infrastructure or application upgrade or
modification (such as an operating system
upgrade, a sub-network added to the
environment, or a web server added to the
environment).
Penetration testing conducted on a regular basis and
after significant changes to the environment is a
proactive security measure that helps minimize
potential access to the CDE by malicious individuals.
The determination of what constitutes a significant
upgrade or modification is highly dependent on the
configuration of a given environment. If an upgrade
or modification could allow access to cardholder
data or affect the security of the cardholder data
environment, then it could be considered significant.
Performing penetration tests after network
upgrades and modifications provides assurance that
the controls assumed to be in place are still working
effectively after the upgrade or modification.
11.3.1 Perform external penetration testing at
least annually and after any significant
infrastructure or application upgrade or
modification (such as an operating system
upgrade, a sub-network added to the
environment, or a web server added to the
environment).
11.3.3 Exploitable vulnerabilities found during
penetration testing are corrected and testing is
repeated to verify the corrections.
11.3.2 Perform internal penetration testing at
least annually and after any significant
infrastructure or application upgrade or
modification (such as an operating system
upgrade, a sub-network added to the
environment, or a web server added to the
environment).
Penetration testing conducted on a regular basis and
after significant changes to the environment is a
proactive security measure that helps minimize
potential access to the CDE by malicious individuals.
The determination of what constitutes a significant
upgrade or modification is highly dependent on the
configuration of a given environment. If an upgrade
or modification could allow access to cardholder
data or affect the security of the cardholder data
environment, then it could be considered significant.
Performing penetration tests after network
upgrades and modifications provides assurance that
the controls assumed to be in place are still working
effectively after the upgrade or modification.
Penetration testing is an important tool to confirm
that any segmentation in place to isolate the CDE
from other networks is effective. The penetration
testing should focus on the segmentation controls,
both from outside the entitys network and from
inside the network but outside of the CDE, to
confirm that they are not able to get through the
segmentation controls to access the CDE. For
example, network testing and/or scanning for open
ports, to verify no connectivity between in-scope
and out-of-scope networks.
11.3.4 If segmentation is used to isolate the CDE
from other networks, perform penetration tests at
least annually and after any changes to
segmentation controls/methods to verify that the
segmentation methods are operational and
effective, and isolate all out-of-scope systems
from in-scope systems.
Penetration testing is an important tool to confirm
that any segmentation in place to isolate the CDE
from other networks is effective. The penetration
testing should focus on the segmentation controls,
both from outside the entitys network and from
inside the network but outside of the CDE, to
confirm that they are not able to get through the
segmentation controls to access the CDE. For
example, network testing and/or scanning for open
ports, to verify no connectivity between in-scope
and out-of-scope networks.
11.3.4 If segmentation is used to isolate the CDE
from other networks, perform penetration tests at
least annually and after any changes to
segmentation controls/methods to verify that the
segmentation methods are operational and
effective, and isolate all out-of-scope systems
from in-scope systems.
11.4 Use intrusion-detection systems, and/or
intrusion-prevention systems to monitor all traffic at
the perimeter of the cardholder data environment
as well as at critical points inside of the cardholder
data environment, and alert personnel to suspected
compromises.
Keep all intrusion-detection and prevention engines,
baselines, and signatures up-to-date.
Intrusion detection and/or intrusion prevention
systems (IDS/IPS) compare the traffic coming into
the network with known signatures and/or
behaviors of thousands of compromise types
(hacker tools, Trojans and other malware), and send
alerts and/or stop the attempt as it happens.
Without a proactive approach to unauthorized
activity detection via these tools, attacks on (or
misuse of) computer resources could go unnoticed
in real time. Security alerts generated by these tools
should be monitored, so that the attempted
intrusions can be stopped.
IDS/IPS devices should be implemented such that
they monitor inbound and outbound traffic at the
perimeter of the CDE as well as at critical points
within the CDE. Critical points inside the CDE may
include database servers storing cardholder data,
cryptographic key storage locations, processing
networks, or other sensitive system components, as
determined by an entitys environment and as
documented in their risk assessment.
While many IDS/IPS devices today are able to
monitor multiple points inside of the CDE via one
device, it is important to remember the increased
exposure that may occur as a result of a failure in
that single device. Thus, it is important to
incorporate appropriate redundancy in the IDS/IPS
infrastructure.
There are thousands of compromise types, with
more being discovered on a daily basis. Stale
signatures and scanning engines on IDS/IPS devices
will not have the ability to identify new
vulnerabilities that could lead to an undetected
breach. Vendors of these products provide frequent,
often daily, updates that should be evaluated and
applied on a regular basis.
11.5.1 Implement a process to respond to any alerts
generated by the change- detection solution.
11.4 Use intrusion-detection systems, and/or
intrusion-prevention systems to monitor all traffic at
the perimeter of the cardholder data environment
as well as at critical points inside of the cardholder
data environment, and alert personnel to suspected
compromises.
Keep all intrusion-detection and prevention engines,
baselines, and signatures up-to-date.
Change-detection solutions such as file-integrity
monitoring (FIM) tools check for changes to critical
files, and notify when such changes are detected. If
not implemented properly and the output of the
change-detection solution monitored, a malicious
individual could alter configuration file contents,
operating system programs, or application
executables. Unauthorized changes, if undetected,
could render existing security controls ineffective
and/or result in cardholder data being stolen with no
perceptible impact to normal processing.
Intrusion detection and/or intrusion prevention
systems (IDS/IPS) compare the traffic coming into
the network with known signatures and/or
behaviors of thousands of compromise types
(hacker tools, Trojans and other malware), and send
alerts and/or stop the attempt as it happens.
Without a proactive approach to unauthorized
activity detection via these tools, attacks on (or
misuse of) computer resources could go unnoticed
in real time. Security alerts generated by these tools
should be monitored, so that the attempted
intrusions can be stopped.
IDS/IPS devices should be implemented such that
they monitor inbound and outbound traffic at the
perimeter of the CDE as well as at critical points
within the CDE. Critical points inside the CDE may
include database servers storing cardholder data,
cryptographic key storage locations, processing
networks, or other sensitive system components, as
determined by an entitys environment and as
documented in their risk assessment.
While many IDS/IPS devices today are able to
monitor multiple points inside of the CDE via one
device, it is important to remember the increased
exposure that may occur as a result of a failure in
that single device. Thus, it is important to
incorporate appropriate redundancy in the IDS/IPS
infrastructure.
There are thousands of compromise types, with
more being discovered on a daily basis. Stale
signatures and scanning engines on IDS/IPS devices
will not have the ability to identify new
vulnerabilities that could lead to an undetected
breach. Vendors of these products provide frequent,
often daily, updates that should be evaluated and
applied on a regular basis.
11.5 Deploy a change-detection mechanism (for
example, file-integrity monitoring tools) to alert
personnel to unauthorized modification of critical
system files, configuration files, or content files; and
configure the software to perform critical file
comparisons at least weekly.
11.6 Ensure that security policies and operational
procedures for security monitoring and testing are
documented, in use, and known to all affected
parties
Personnel need to be aware of and following
security policies and operational procedures for
security monitoring and testing on a continuous
basis.
NA
Go to requirement 12 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
11.1.a Examine policies and procedures to verify processes are defined for detection
and identification of both authorized and unauthorized wireless access points on a
quarterly basis.
11.1.b Verify that the methodology is adequate to detect and identify any unauthorized
wireless access points, including at least the following:
- WLAN cards inserted into system components
- Portable wireless devices connected to system components (for example, by USB, etc.)
- Wireless devices attached to a network port or network device
11.1.c Examine output from recent wireless scans to verify that:
-Authorized and unauthorized wireless access points are identified, and-
The scan is performed at least quarterly for all system components and facilities.
C1.2
C13.9
C7.1
C7.3
C7.9
Requirement 11: Regularly test security systems and processes.
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment
Major observations from the 2014 Verizon PCI Compliance Report:
Requirement 11 was the least complied-with requirement in our study. Just 23.8% of companies met all the controls between 2011 and 2013.
Controls and subcontrols where we saw the lowest compliance between 2011 and 2013 were:
11.3.a*Examinetheresultsfromthemostrecentpenetrationtesttoverifythatpenetration
testing is performed at least annually], 39.6%
11.3.b*Verifythatnotedexploitablevulnerabilitieswerecorrectedandtestingrepeated+,43.6% 11.2.1.a*Reviewthescanreportsandverifythatfourquarterlyinternalscanswereperformedin
the most recent 12-month period], 45.5%
11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.),
verify the configuration will generate alerts to personnel.
11.1.1 Examine documented records to verify that an inventory of authorized wireless
access points is maintained and a business justification is documented for all authorized
wireless access points.
11.1.2.a Examine the organizations incident response plan (Requirement 12.10) to
verify it defines and requires a response in the event that an unauthorized wireless
access point is detected.
11.1.2.b Interview responsible personnel and/or inspect recent wireless scans and
related responses to verify action is taken when unauthorized wireless access points
are found.
C1.2
C13.9
C6.4
11.2 Examine scan reports and supporting documentation to verify that internal and
external vulnerability scans are performed as follows:
11.2.1.a Review the scan reports and verify that four quarterly internal scans occurred
in the most recent 12-month period.
C1.2
C13.9
C7.1
C7.3
C7.9
C4.1
C11.2
11.2.1.b Review the scan reports and verify that the scan process includes rescans until
passing results are obtained, or all High vulnerabilities as defined in PCI DSS
Requirement 6.2 are resolved.
11.2.1.c Interview personnel to verify that the scan was performed by a qualified
internal resource(s) or qualified external third party, and if applicable, organizational
independence of the tester exists (not required to be a QSA or ASV).
C4.1
11.2.2.a Review output from the four most recent quarters of external vulnerability
scans and verify that four quarterly scans occurred in the most recent 12-month period.
11.2.2.b Review the results of each quarterly scan to ensure that they satisfy the ASV
Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0 by
the CVSS and no automatic failures).
For each of the four internal quarterly scans indicated at 11.2.2.a, identify whether a
rescan was necessary. (yes/no)
If yes, describe how the results of the rescan were reviewed to verify that the ASV
Program Guide requirements for a passing scan have been met.
If yes, describe how the results of the rescan were reviewed to verify that the ASV
Program Guide requirements for a passing scan have been met.
C4.1
C11.2
11.2.2.c Review the scan reports to verify that the scans were completed by a PCI SSC
Approved Scanning Vendor (ASV).
11.2.3.a Inspect and correlate change control documentation and scan reports to verify
that system components subject to any significant change were scanned.
11.2.3.b Review scan reports and verify that the scan process includes rescans until:
For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.
For internal scans, all high- risk vulnerabilities as defined in PCI DSS Requirement
6.1 are resolved.
11.2.3.c Validate that the scan was performed by a qualified internal resource(s) or
qualified
external third party, and if applicable, organizational independence of the tester exists
(not required to be a QSA or ASV).
C6.4
C4.1
C11.2
11.3 Examine penetration- testing methodology and interview responsible personnel to
verify a methodology is implemented and includes at least the following:
Is based on industry- accepted penetration testing approaches.
Includes coverage for the entire CDE perimeter and critical systems.
Includes testing from both inside and outside the network.
Includes testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the vulnerabilities
listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
Includes review and consideration of threats and vulnerabilities experienced in the
last 12 months.
Specifies retention of penetration testing results and remediation activities results.
11.3.1.a Examine the scope of work and results from the most recent external
penetration test to verify that penetration testing is performed as follows:
Per the defined methodology
At least annually
After any significant changes to the environment.
C13.9
C20.1
11.3 Examine penetration- testing methodology and interview responsible personnel to
verify a methodology is implemented and includes at least the following:
Is based on industry- accepted penetration testing approaches.
Includes coverage for the entire CDE perimeter and critical systems.
Includes testing from both inside and outside the network.
Includes testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the vulnerabilities
listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
Includes review and consideration of threats and vulnerabilities experienced in the
last 12 months.
Specifies retention of penetration testing results and remediation activities results.
11.3.1.b Verify that the test was performed by a qualified internal resource or
qualified external third party, and if applicable, organizational independence of
the tester exists (not required to be a QSA or ASV).
11.3.2.a Examine the scope of work and results from the most recent internal
penetration test to verify that penetration testing is performed at least annually and
after any significant changes to the environment.
Per the defined methodology
At least annually
After any significant changes
to the environment
C13.9
C20.1
11.3.2.b Verify that the test was performed by a qualified internal resource or qualified
external third party, and if applicable, organizational independence of the tester exists
(not required to be a QSA or ASV).
11.3.3 Examine penetration testing results to verify that noted exploitable
vulnerabilities were corrected and that repeated testing confirmed the vulnerability
was corrected.
11.3.4.a Examine segmentation controls and review penetration-testing methodology
to verify that penetration- testing procedures are defined to test all segmentation
methods to confirm they are operational and effective, and isolate all out-of-scope
systems from in-scope systems.
11.3.4.b Examine the results from the most recent penetration test to verify that
penetration testing to verify segmentation controls:
-Is performed at least annually and after any changes to segmentation
controls/methods.
-Covers all segmentation controls/methods in use.
-Verifies that segmentation methods are operational and effective, and isolate all out-
of-scope systems from in- scope systems.
11.4.a Examine system configurations and network diagrams to verify that techniques
(such as intrusion-detection systems and/or intrusion-prevention systems) are in place
to monitor all traffic:
-At the perimeter of the cardholder data environment
-At critical points in the cardholder data environment.
11.4.b Examine system configurations and interview responsible personnel to
confirm intrusion-detection and/or intrusion-prevention techniques alert
personnel of suspected compromises.
C13.2
C13.3
C5.1.2
11.4.c Examine IDS/IPS configurations and vendor documentation to verify
intrusion-detection and/or intrusion- prevention techniques are configured,
maintained, and updated per vendor instructions to ensure optimal protection.
11.5.a Verify the use of a change-detection mechanism within the cardholder data
environment by observing system settings and monitored files, as well as reviewing
results from monitoring activities.
Examples of files that should be monitored:
System executables
Application executables
Configuration and parameter files
Centrally stored, historical or archived, log and audit files
Additional critical files determined by entity (for example, through risk assessment or
other means).
11.5.b Verify the mechanism is configured to alert personnel to unauthorized
modification of critical files, and to perform critical file comparisons at least weekly.
11.5.1 Interview personnel to verify that all alerts are investigated and resolved.
C3.9
C13.2
C13.3
C5.1.2
11.6 Examine documentation interview personnel to verify that security policies and
operational procedures for security monitoring and testing are:
-Documented,
- In use, and
-Known to all affected parties.
NA
Validation Instructions for QSA/ISA
(For In-Place Requirements)
Priotity A A-EP
Identify the documented policies and procedures examined to verify processes are
defined for detection and identification of authorized and unauthorized wireless
access points on a quarterly basis.
<Report Findings Here>
4 0 0
Describe how the methodology/processes were verified to be adequate to detect and
identify unauthorized wireless access points, including the following:
<Report Findings Here>
WLAN cards inserted into system components.
<Report Findings Here>
Portable or mobile devices attached to system components to create a wireless
access point.
<Report Findings Here>
Wireless devices attached to a network port or network device.
<Report Findings Here>
Any other unauthorized wireless access point.
<Report Findings Here>
4 0 0
Identify/describe the output from recent wireless scans examined to verify that:
Authorized wireless access points are identified.
Unauthorized wireless access points are identified.
The scan is performed at least quarterly.
The scan covers all system components.
The scan covers all facilities.
<Report Findings Here>
4 0 0
Selected Merchant Type
Requirement 11: Regularly test security systems and processes.
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment
Major observations from the 2014 Verizon PCI Compliance Report:
Requirement 11 was the least complied-with requirement in our study. Just 23.8% of companies met all the controls between 2011 and 2013.
Controls and subcontrols where we saw the lowest compliance between 2011 and 2013 were:
11.3.a*Examinetheresultsfromthemostrecentpenetrationtesttoverifythatpenetration
testing is performed at least annually], 39.6%
11.3.b*Verifythatnotedexploitablevulnerabilitieswerecorrectedandtestingrepeated+,43.6% 11.2.1.a*Reviewthescanreportsandverifythatfourquarterlyinternalscanswereperformedin
the most recent 12-month period], 45.5%
Identify whether automated monitoring is utilized. (yes/no)
<Report Findings Here>
If no, mark the remainder of 11.1.d as Not Applicable. If yes, complete the
following:
<Report Findings Here>
Identify and describe any automated monitoring technologies in use.
<Report Findings Here>
For each monitoring technology in use, describe how the technology generates alerts
to personnel.
<Report Findings Here>
4 0 0
Identify the documented inventory records of authorized wireless access points
examined to verify that an inventory of authorized wireless access points is
maintained and a business justification is documented for all authorized wireless
access points.
<Report Findings Here>
4 0 0
Identify the Incident Response Plan document examined that defines and requires
response in the event that an unauthorized wireless access point is detected.
<Report Findings Here>
4 0 0
Identify the responsible personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed that verify that action is
taken when unauthorized wireless access points are found.
<Report Findings Here>
And/or:
Identify the recent wireless scans inspected for this testing procedure.
<Report Findings Here>
Describe how the recent wireless scans and related responses were inspected to
verify that action is taken when unauthorized wireless access points are found.
<Report Findings Here>
4 0 0
Not provided by PCIco
<Report Findings Here>
4 0 0
Identify the internal vulnerability scan reports and supporting documentation
reviewed.
<Report Findings Here>
Provide the name of the assessor who attests that four quarterly internal scans
were verified to have occurred in the most recent 12-month period.
<Report Findings Here>
2
0 0
Identify the documented process for quarterly internal scanning to verify the
process defines performing rescans as part of the quarterly internal scan process.
<Report Findings Here>
For each of the four internal quarterly scans indicated at 11.2.1.a, identify whether
a rescan was required. (yes/no)
<Report Findings Here>

If yes, describe how rescans were verified to be performed until either:


<Report Findings Here>
Passing results are obtained, or
<Report Findings Here>
All High vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.
<Report Findings Here>
2
0 0
Identifytheresponsiblepersonnelinterviewed who confirm that the scan was
performed by a qualified internal resource(s) or qualified external third party.
<Report Findings Here>
Identify whether a qualified internal resource performs the scan. (yes/no)
<Report Findings Here>
If no, mark the remainder of 11.2.1.c as Not Applicable.
If yes, complete the following:
Describe how the personnel who perform the scans demonstrated they are
qualified to perform the scans.
<Report Findings Here>
Describe how organizational independence of the tester was observed to exist.
<Report Findings Here>
2
0 0
Identify the external network vulnerability scan reports and supporting
documentation reviewed.
<Report Findings Here>
Provide the name of the assessor who attests that four quarterly external
vulnerability scans were verified to have occurred in the most recent 12-month
period.
<Report Findings Here>
2
0 1
Describe how the results of each quarterly scan were reviewed to verify that the
ASV Program Guide requirements for a passing scan have been met.
<Report Findings Here>
For each of the four internal quarterly scans indicated at 11.2.2.a, identify whether
a rescan was necessary. (yes/no)
<Report Findings Here>
2
0 1
Provide the name of the assessor who attests that the external scan reports were
reviewed and verified to have been completed by a PCI SSC-Approved Scanning
Vendor (ASV).
<Report Findings Here>
2
0 1
Identify the document reviewed to verify processes are defined for performing
internal and external scans after any significant change.
<Report Findings Here>
dentify the change control documentation and scan reports reviewed for this testing
procedure.
<Report Findings Here>
Describe how the change control documentation and scan reports were inspected
and correlated to verify that all system components subject to significant change
were scanned after the change.
<Report Findings Here>
2
0 1
For all scans reviewed in 11.2.3.a, identify whether a rescan was required. (yes/no)
<Report Findings Here>
If yes for external scans, describe how rescans were performed until no
vulnerabilities with a CVSS score greater than 4.0 exist.
<Report Findings Here>
If yes for internal scans, describe how rescans were performed until either
passing results were obtained or all high-risk vulnerabilities as defined in PCI DSS
Requirement 6.1 were resolved.
<Report Findings Here>
2
0 1
Describe how it was validated that the scan was performed by a qualified internal
resource(s) or qualified external third party.
<Report Findings Here>
Identify whether an internal resource performed the scans. (yes/no)
If no, mark the remainder of 11.2.3.c as Not Applicable.
If yes, complete the following:
<Report Findings Here>
Describe how the personnel who perform the scans demonstrated they are
qualified to perform the scans.
<Report Findings Here>
Describe how organizational independence of the tester was observed to exist.
<Report Findings Here>
2
0 1
2
0 1 Identify the documented penetration-testing methodology examined to verify a
methodology is implemented that includes at least the following:
Based on industry-accepted penetration testing approaches.
Coverage for the entire CDE perimeter and critical systems.
Testing from both inside and outside the network.
Testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
Retention of penetration testing results and remediation activities results.
<Report Findings Here>
Identify the responsible personnel interviewed who confirm the penetrationtesting
methodology implemented includes at least the following:
Based on industry-accepted penetration testing approaches.
Coverage for the entire CDE perimeter and critical systems.
Testing from both inside and outside the network.
Testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
Retention of penetration testing results and remediation activities results.
<Report Findings Here>
Describe how the penetration-testing methodology was examined to verify that the
implemented methodology includes at least the following:
Based on industry-accepted penetration testing approaches.
<Report Findings Here>
Coverage for the entire CDE perimeter and critical systems.
<Report Findings Here>
Testing from both inside the network, and from outside of the network attempting to
get in.
<Report Findings Here>
Testing to validate any segmentation and scope-reduction controls.
<Report Findings Here>
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
<Report Findings Here>
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
<Report Findings Here>
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
<Report Findings Here>
Retention of penetration testing results and remediation activities results.
<Report Findings Here>
Identify the documented external penetration test results reviewed to verify that
external penetration testing is performed:
Per the defined methodology
At least annually
<Report Findings Here>
Describe how the scope of work was reviewed to verify that external penetration
testing is performed:
Per the defined methodology
At least annually
<Report Findings Here>
Identify whether any significant external infrastructure or application upgrade or
modification occurred during the past 12 months.
<Report Findings Here>
Identify the documented penetration test results reviewed to verify that external
penetration tests are performed after significant external infrastructure or
application upgrade.
<Report Findings Here>
2
0 1
2
0 1 Identify the documented penetration-testing methodology examined to verify a
methodology is implemented that includes at least the following:
Based on industry-accepted penetration testing approaches.
Coverage for the entire CDE perimeter and critical systems.
Testing from both inside and outside the network.
Testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
Retention of penetration testing results and remediation activities results.
<Report Findings Here>
Identify the responsible personnel interviewed who confirm the penetrationtesting
methodology implemented includes at least the following:
Based on industry-accepted penetration testing approaches.
Coverage for the entire CDE perimeter and critical systems.
Testing from both inside and outside the network.
Testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
Retention of penetration testing results and remediation activities results.
<Report Findings Here>
Describe how the penetration-testing methodology was examined to verify that the
implemented methodology includes at least the following:
Based on industry-accepted penetration testing approaches.
<Report Findings Here>
Coverage for the entire CDE perimeter and critical systems.
<Report Findings Here>
Testing from both inside the network, and from outside of the network attempting to
get in.
<Report Findings Here>
Testing to validate any segmentation and scope-reduction controls.
<Report Findings Here>
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
<Report Findings Here>
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
<Report Findings Here>
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
<Report Findings Here>
Retention of penetration testing results and remediation activities results.
<Report Findings Here>
Describe how it was validated that the test was performed by a qualified internal
resource(s) or qualified external third party.
<Report Findings Here>
Identify whether an internal resource performed the test. (yes/no)
If no, mark the remainder of 11.3.1.b as Not Applicable.
If yes, complete the following:
Describe how the personnel who perform the scans demonstrated they are qualified
to perform the scans.
<Report Findings Here>
Describe how organizational independence of the tester was observed to exist.
<Report Findings Here>
2
0 1
Identify the documented internal penetration test results reviewed to verify that
internal penetration tests are performed after significant internal infrastructure or
application upgrade.
<Report Findings Here>
Describe how the scope of work was reviewed to verify that internal penetration
testing is performed:
Per the defined methodology
At least annually
<Report Findings Here>
Identify whether any significant internal infrastructure or application upgrade or
modification occurred during the past 12 months. (yes/no)
<Report Findings Here>
Identify the documented internal penetration test results reviewed to verify that
internal penetration tests are performed after significant internal infrastructure or
application upgrade.
<Report Findings Here>
2
0 0
Describe how it was validated that the test was performed by a qualified internal
resource(s) or qualified external third party.
<Report Findings Here>
Identify whether an internal resource performed the test. (yes/no)
If no, mark the remainder of 11.3.2.b as Not Applicable.
If yes, complete the following:
Describe how the personnel who perform the scans demonstrated they are qualified
to perform the scans
<Report Findings Here>
Describe how organizational independence of the tester was observed to exist.
<Report Findings Here>
Describe how the personnel who perform the scans demonstrated they are qualified
to perform the scans
<Report Findings Here>
Describe how organizational independence of the tester was observed to exist.
<Report Findings Here>
2
0 0
Identify the documented penetration testing results examined to verify that noted
exploitable vulnerabilities were corrected and that repeated testing confirmed the
vulnerability was corrected.
<Report Findings Here>
2
0 1
Identify whether segmentation is used to isolate the CDE from other networks.
(yes/no)
<Report Findings Here>
If no, mark the remainder of 11.3.4.a and 11.3.4.b as Not Applicable.
If yes:
Describe segmentation controls examined for this testing procedure.
<Report Findings Here>
Describe how the segmentation controls and penetration-testing methodology were
examined to verify that penetration testing procedures are defined to:
<Report Findings Here>
Test all segmentation methods to confirm they are operational and effective.
<Report Findings Here>
Isolate all out-of-scope systems from in-scope systems.
<Report Findings Here>
2
0 1
Identify the documented results from the most recent penetration test to verify that
penetration testing to verify segmentation controls:
Is performed at least annually and after any changes to segmentation
controls/methods. Covers all segmentation controls/methods in use.
Verifies that segmentation methods are operational and effective, and isolate all out-
of-scope systems from in-scope systems.
<Report Findings Here>
2
0 1
Identify the network diagrams examined to verify that techniques are in place to
monitor all traffic:
At the perimeter of the cardholder data environment.
At critical points in the cardholder data environment.
<Report Findings Here>
Identify the techniques observed to be in place to monitor all traffic:
At the perimeter of the cardholder data environment.
At critical points in the cardholder data environment.
<Report Findings Here>
Describe how system configurations were examined to verify that techniques are in
place to monitor all traffic:
<Report Findings Here>
At the perimeter of the cardholder data environment.
<Report Findings Here>
At critical points in the cardholder data environment.
<Report Findings Here>
2
0 0
Describe how system configurations for intrusion-detection, and/or intrusion-
prevention techniques were examined to verify they are configured to alert
personnel of suspected compromises.
<Report Findings Here>
Describe how alerts to personnel are generated.
<Report Findings Here>
Identify the responsible personnel interviewed who confirm that the generated alerts
are received as intended.
<Report Findings Here>
2
0 0
Identify the vendor document(s) examined to verify defined vendor instructions for
intrusion- detection and/or intrusion-prevention techniques
<Report Findings Here>
Describe how IDS/IPS configurations were examined and compared to vendor
documentation to verify intrusion-detection, and/or intrusion-prevention techniques
are:
Configured per vendor instructions to ensure optimal protection.
<Report Findings Here>
Maintained per vendor instructions to ensure optimal protection.
<Report Findings Here>
Updated per vendor instructions to ensure optimal protection.
<Report Findings Here>
2
0 0
Describe the change-detection mechanism deployed.
<Report Findings Here>
Identify the results from monitored files reviewed.
<Report Findings Here>
Describe how change-detection mechanism settings and results from monitored files
were observed to monitor changes to:
Critical system files
<Report Findings Here>
Critical configuration files
<Report Findings Here>
Critical content files
<Report Findings Here>
4 0 1
Describe how it was verified that the change-detection mechanism is configured to:
Alert personnel to unauthorized modification of critical files.
<Report Findings Here>
Perform critical file comparisons at least weekly.
<Report Findings Here>
4 0 1
Identify the personnel interviewed for this testing procedure.
<Report Findings Here>
For the interview, summarize details of the interview that verify that all alerts are
investigated and resolved.
<Report Findings Here>
4 0 1
Identify the document reviewed to verify that security policies and operational
procedures for security monitoring and testing are documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for security monitoring and testing are:
In use
Known to all affected parties
<Report Findings Here>
6 0 0
90 0 15
NA
PE2P B B-IP C-VT C D S In Place? Severity
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
Selected Merchant Type D
Requirement 11: Regularly test security systems and processes.
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 5
0 0 0 0 1 1 1
N 5
0 0 0 0 1 1 1
N 5
0 0 1 0 1 1 1
N 5
0 0 1 0 1 1 1
N 5
0 0 1 0 1 1 1
N 5
0 0 0 0 1 1 1
N 5
0 0 0 0 1 1 1
N 5
0 0 0 0 1 1 1
N 5
1 0 0 0 1
5
0 0
N
0 0 0 0 0 1 1
N 5
1 0 0 0 1
5
0 0
N
0 0 0 0 0 1 1
N 5
0 0 0 0 0 1 1
N 5
0 0 0 0 0 1 1
N 5
0 0 0 0 0 1 1
N 5
0 0 0 0 1 1 1
N 5
0 0 0 0 1 1 1
NT 5
0 0 0 0 0 1 1
N 5
0 0 0 0 0 1 1
N 5
0 0 0 0 0 1 1
N 5
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
N 3
0 0 0 0 1 1 1
C 0
0 1 0 1 0 1 1
Y 0
0 1 3 1 22 32 32 Y 130
N
C
NT
NA
Proofs /
Documentation links
Stage of implementation Remediation plan
Requirement 11: Regularly test security systems and processes.
Estimated date for
completion
Comments Owner
Requirement 11: Regularly test security systems and processes.
Return to Table of content Go to Requirement 11
PCI DSS Requirement Guidance
12.1 Establish, publish, maintain, and disseminate a
security policy.
A company's information security policy creates the
roadmap for implementing security measures to
protect its most valuable assets. A strong security
policy sets the security tone for the whole company,
and lets personnel know what is expected of them.
All personnel should be aware of the sensitivity of
data and their responsibilities for protecting it.
12.1.1 Review the security policy at least annually
and updates when the environment changes.
Security threats and protection methods evolve
rapidly throughout the year. Without updating the
security policy to reflect relevant changes, new
protection measures to fight against these threats
are not addressed.
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environment.
12.2 Implement a risk-assessment process that:
-Is performed at least annually and upon significant
changes to the environment (for example,
acquisition, merger, relocation, etc.),
-Identifies critical assets, threats, and vulnerabilities,
and
-Results in a formal risk assessment.
A risk assessment enables an organization to identify
threats and the associated vulnerabilities which have
the potential to negatively impact their business.
Resources can then be effectively allocated to
implement controls that reduce the likelihood
and/or the potential impact of the threat being
realized.
Performing risk assessments at least annually allows
the organization to keep up to date with
organizational changes and evolving threats, trends
and technologies,
Major Observations from the 2014 Verizon PCI Compliance Report:
Organizations found control 12.4 *Ensure that the security policy and procedures clearly define information security responsibilities for all personnel+ easiest to comply with 83.2% of organizations fulfilled all the subcontrols.
79.2% and 74.3% of organizations respectively were compliant with all the subcontrols of 12.7 [Screen potential personnel prior to hire to minimize the risk of attacks from internal sources] and 12.5 [Assign to an individual or team the following information security management responsibilities].
Only 53.5% of organizations complied. with 12.1.2.b [Perform and document risk assessments at least annually.
And only 55.4% of organizations complied with 12.9.4 [Regularly train staff with security responsibilities]. Clearly, once the initial policy-setting activities are done, organizations are failing to translate compliance effort into business-as-usual activities such as training.
12.3 Develop usage policies for critical technologies
(for example, remote- access technologies, wireless
technologies, removable electronic media, laptops,
tablets, personal data/digital assistants (PDAs), e-
mail usage and Internet usage) and define proper
use of these technologies. Ensure these usage
policies require the following:
Personnel usage policies can either prohibit use of
certain devices and other technologies if that is
company policy, or provide guidance for personnel
as to correct usage and implementation. If usage
policies are not in place, personnel may use the
technologies in violation of company policy, thereby
allowing malicious individuals to gain access to
critical systems and cardholder data. An example
can be unknowingly setting up wireless networks
with no security. To ensure that company standards
are followed and only approved technologies are
implemented, consider confining implementation to
operations teams only and not allowing
unspecialized/general personnel install these
technologies.
12.3.1 Explicit approval by authorized parties Without requiring proper approval for
implementation of these technologies, individual
personnel may innocently implement a solution to a
perceived business need, but also open a huge hole
that subjects critical systems and data to malicious
individuals.
12.3.2 Authentication for use of the technology If technology is implemented without proper
authentication (user IDs and passwords, tokens,
VPNs, etc.), malicious individuals may easily use this
unprotected technology to access critical systems
and cardholder data.
12.2 Implement a risk-assessment process that:
-Is performed at least annually and upon significant
changes to the environment (for example,
acquisition, merger, relocation, etc.),
-Identifies critical assets, threats, and vulnerabilities,
and
-Results in a formal risk assessment.
A risk assessment enables an organization to identify
threats and the associated vulnerabilities which have
the potential to negatively impact their business.
Resources can then be effectively allocated to
implement controls that reduce the likelihood
and/or the potential impact of the threat being
realized.
Performing risk assessments at least annually allows
the organization to keep up to date with
organizational changes and evolving threats, trends
and technologies,
12.3.3 A list of all such devices and personnel with
access
Malicious individuals may breach physical security
and place their own devices on the network as a
back door. Personnel may also bypass procedures
and install devices. An accurate inventory with
proper device labeling allows for quick identification
of non-approved installations.
12.3.4 A method to accurately and readily
determine owner, contact information, and
purpose (for example, labeling, coding, and/or
inventorying of devices)
Malicious individuals may breach physical security
and place their own devices on the network as a
back door. Personnel may also bypass procedures
and install devices. An accurate inventory with
proper device labeling allows for quick identification
of non-approved installations. Consider establishing
an official naming convention for devices, and log all
devices with established inventory controls. Logical
labeling may be employed with information such as
12.3.5 Acceptable uses of the technology
12.3.6 Acceptable network locations for the
technologies
12.3.7 List of company-approved products
Remote-access technologies are frequent "back
doors" to critical resources and cardholder data. By
disconnecting remote-access technologies when not
in use (for example, those used to support your
systems by your POS vendor, other vendors, or
business partner), access and risk to networks is
minimized. Consider using controls to disconnect
devices after 15 minutes of inactivity. Please also see
Requirement 8.5.6 for more on this topic.
12.3.8 Automatic disconnect of sessions for
remote-access technologies after a specific period
of inactivity
By defining acceptable business use and location of
company-approved devices and technology, the
company is better able to manage and control gaps
in configurations and operational controls, to ensure
a back door is not opened for a malicious
individual to gain access to critical systems and
cardholder data.
12.3.9 Activation of remote-access technologies
for vendors and business partners only when
needed by vendors and business partners, with
immediate deactivation after use
12.5 Assign to an individual or team the following
information security management responsibilities:
12.5.1 Establish, document, and distribute security
policies and procedures.
12.3.10 For personnel accessing cardholder data
via remote-access technologies, prohibit copy,
move, and storage of cardholder data onto local
hard drives and removable electronic media,
unless explicitly authorized for a defined business
need.
Remote-access technologies are frequent "back
doors" to critical resources and cardholder data. By
disconnecting remote-access technologies when not
in use (for example, those used to support your
systems by your POS vendor, other vendors, or
business partner), access and risk to networks is
minimized. Consider using controls to disconnect
devices after 15 minutes of inactivity. Please also see
Requirement 8.5.6 for more on this topic.
To ensure all personnel are aware of their
responsibilities to not store or copy cardholder data
onto their local personal computer or other media,
your policy should clearly prohibit such activities
except for personnel that have been explicitly
authorized to do so. Any such authorized personnel
are responsible for ensuring that cardholder data in
their possession is handled in accordance with all PCI
DSS requirements, as that remote personnels
environment is now considered a part of the
organizations cardholder data environment.
12.4 Ensure that the security policy and procedures
clearly define information security responsibilities
for all personnel.
Without clearly defined security roles and
responsibilities assigned, there could be inconsistent
interaction with the security group, leading to
unsecured implementation of technologies or use of
outdated or unsecured technologies.
Each person or team with responsibilities for
information security management should be clearly
aware of their responsibilities and related tasks,
through specific policy. Without this accountability,
gaps in processes may open access into critical
resources or cardholder data.
12.5.2 Monitor and analyze security alerts and
information, and distribute to appropriate
personnel.
12.5.3 Establish, document, and distribute security
incident response and escalation procedures to
ensure timely and effective handling of all
situations.
12.5.4 Administer user accounts, including
additions, deletions, and modifications
12.5.5 Monitor and control all access to data.
12.6 Implement a formal security awareness
program to make all personnel aware of the
importance of cardholder data security.
12.6.1 Educate personnel upon hire and at least
annually.
Note: Methods can vary depending on the role of
the personnel and their level of access to the
cardholder data.
If the security awareness program does not include
periodic refresher sessions, key security processes
and procedures may be forgotten or bypassed,
resulting in exposed critical resources and
cardholder data. The focus and depth of the initial
and refresher training can vary depending on the
role of the personnel, and should be tailored as
appropriate for the particular audience. For
example, sessions for database administrators may
be focused on specific technical controls and
processes, while training for retail cashiers may
focus on secure transaction procedures
Consider including ongoing awareness updates to
keep employees up to date with current policies and
procedures. The method of delivery may also vary to
suit the particular audience or training being
delivered. For example, initial and annual training
may be delivered via a formal hands-on or computer-
based training session, while ongoing periodic
updates may be delivered via e-mails, posters,
newsletters, etc.
Each person or team with responsibilities for
information security management should be clearly
aware of their responsibilities and related tasks,
through specific policy. Without this accountability,
gaps in processes may open access into critical
resources or cardholder data.
If personnel are not educated about their security
responsibilities, security safeguards and processes
that have been implemented may become
ineffective through errors or intentional actions.
12.6.2 Require personnel to acknowledge at least
annually that they have read and understood the
security policy and procedures.
Requiring an acknowledgement by personnel in
writing or electronically helps ensure that they have
read and understood the security
policies/procedures, and that they have made and
will continue to make a commitment to comply with
these policies.
12.7 Screen potential personnel prior to hire to
minimize the risk of attacks from internal sources.
(Examples of background checks include previous
employment history, criminal record, credit history,
and reference checks.)
Note: For those potential personnel to be hired for
certain positions such as store cashiers who only
have access to one card number at a time when
facilitating a transaction, this requirement is a
recommendation only.
Performing thorough background investigations
prior to hiring potential personnel who are expected
to be given access to cardholder data reduces the
risk of unauthorized use of PANs and other
cardholder data by individuals with questionable or
criminal backgrounds. It is expected that a company
would have a policy and process for background
checks, including their own decision process for
which background check results would have an
impact on their hiring decisions (and what that
impact would be).
To be effective, the level of background checking
should be appropriate for the particular position. For
example, positions requiring greater responsibility or
that have administrative access to critical data or
systems may warrant more detailed background
checks than positions with less responsibility and
access. It may also be appropriate for the process to
cover internal transfers, where personnel in lower
risk positions, and who have not already undergone
a detailed background check, are promoted or
transferred to positions of greater responsibility or
access.
12.6.1 Educate personnel upon hire and at least
annually.
Note: Methods can vary depending on the role of
the personnel and their level of access to the
cardholder data.
If the security awareness program does not include
periodic refresher sessions, key security processes
and procedures may be forgotten or bypassed,
resulting in exposed critical resources and
cardholder data. The focus and depth of the initial
and refresher training can vary depending on the
role of the personnel, and should be tailored as
appropriate for the particular audience. For
example, sessions for database administrators may
be focused on specific technical controls and
processes, while training for retail cashiers may
focus on secure transaction procedures
Consider including ongoing awareness updates to
keep employees up to date with current policies and
procedures. The method of delivery may also vary to
suit the particular audience or training being
delivered. For example, initial and annual training
may be delivered via a formal hands-on or computer-
based training session, while ongoing periodic
updates may be delivered via e-mails, posters,
newsletters, etc.
12.8 Maintain and implement policies and
procedures to manage service providers, to include
the following:
If a merchant or service provider shares cardholder
data with a service provider, then certain
requirements apply to ensure continued protection
of this data will be enforced by such service
providers.
12.8.1 Maintain a list of service providers. Keeping track of all service providers identifies
where potential risk extends to outside of the
organization.

12.8.2 Maintain a written agreement that includes


an acknowledgement that the service providers
are responsible for the security of cardholder data
the service providers possess or otherwise store,
process or transmit on behalf of the customer, or
to the extent that they could impact the security
The acknowledgement of the service providers
evidences their commitment to maintaining proper
security of cardholder data that it obtains from its
clients, and thus holds them accountable.
12.8.3 Ensure there is an established process for
engaging service providers including proper due
diligence prior to engagement.
The process ensures that any engagement of a
service provider is thoroughly vetted internally by an
organization, which should include a risk analysis
prior to establishing a formal relationship with the
service provider.
12.8.4 Maintain a program to monitor service
providers PCI DSS compliance status at least
annually.
12.8.5 Maintain information about which PCI DSS
requirements are managed by each service
provider, and which are managed by the entity.
Knowing your service providers PCI DSS compliance
status provides assurance that they comply with the
same requirements that your organization is subject
to.
If the service provider offers a variety of services,
this requirement applies only to those services
actually delivered to the client, and only those
services in scope for the clients PCI DSS assessment.
For example, if a provider offers firewall/IDS and ISP
services, a client who utilizes only the firewall/IDS
service would only include that service in the scope
of their PCI DSS assessment.
12.9 Additional requirement for service providers:
Service providers acknowledge in writing to
customers that they are responsible for the security
of cardholder data the service provider possesses or
otherwise stores, processes, or transmits on behalf
of the customer, or to the extent that they could
impact the security of the customers cardholder
data environment.
This requirement applies when the entity being
assessed is a service provider. In conjunction with
Requirement 12.8.2, this requirement is intended to
promote a consistent level of understanding
between service providers and their customers
about their applicable PCI DSS responsibilities. The
acknowledgement of the service providers
evidences their commitment to maintaining proper
security of cardholder data that it obtains from its
clients.
The method by which the service provider provides
written acknowledgment should be agreed between
the provider and their customers.
12.10 Implement an incident response plan. Be
prepared to respond immediately to a system
breach.
Without a thorough security incident response plan
that is properly disseminated, read, and understood
by the parties responsible, confusion and lack of a
unified response could create further downtime for
the business, unnecessary public media exposure, as
well as new legal liabilities.
12.10.2 Test the plan at least annually. Without proper testing, key steps may be missed
which could result in increased exposure during an
incident.
If within the last year the incident response plan was
The incident response plan should be thorough and
contain all the key elements to allow your company
to respond effectively in the event of a breach that
could impact cardholder data.
12.10.1 Create the incident response plan to be
implemented in the event of system breach.
Ensure the plan addresses the following, at a
minimum:
- Roles, responsibilities, and communication and
contact strategies in the event of a compromise
including notification of the payment brands, at a
minimum
- Specific incident response procedures
- Business recovery and continuity procedures
- Data back-up processes
- Analysis of legal requirements for reporting
compromises
- Coverage and responses of all critical system
components
- Reference or inclusion of incident response
procedures from the payment brands
12.10.3 Designate specific personnel to be
available on a 24/7 basis to respond to alerts.
12.10.4 Provide appropriate training to staff with
security breach response responsibilities.
12.10.5 Include alerts from intrusion- detection,
intrusion-prevention, and file- integrity monitoring
systems.
These monitoring systems are designed to focus on
potential risk to data, are critical in taking quick
action to prevent a breach, and must be included in
the incident-response processes.
Without proper testing, key steps may be missed
which could result in increased exposure during an
incident.
If within the last year the incident response plan was
activated in its entirety, covering all components of
the plan, a detailed review of the actual incident and
its response may be sufficient to provide a suitable
test. If only some components of the plan were
recently activated, the remaining components would
still need to be tested. If no components of the plan
were activated in the last 12 months, the annual test
would need to encompass all components of the
plan.
12.10.6 Develop a process to modify and evolve
the incident response plan according to lessons
learned and to incorporate industry developments.
Incorporating lessons learned into the incident
response plan after an incident helps keep the plan
current and able to react to emerging threats and
security trends.
Go to requirement 1 Executive Summary
SANS
Top 20 Critical
Security Controls
Testing Procedure
NC 12.1 Examine the information security policy and verify that the policy is published and
disseminated to all relevant personnel (including vendors and business partners).
NC 12.1.1 Verify that the information security policy is reviewed at least annually and
updated as needed to reflect changes to business objectives or the risk environment.
12.2.a Verify that an annual risk assessment process is documented that identifies
threats, vulnerabilities, and results in a formal risk assessment.
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environment.
Major Observations from the 2014 Verizon PCI Compliance Report:
Organizations found control 12.4 *Ensure that the security policy and procedures clearly define information security responsibilities for all personnel+ easiest to comply with 83.2% of organizations fulfilled all the subcontrols.
79.2% and 74.3% of organizations respectively were compliant with all the subcontrols of 12.7 [Screen potential personnel prior to hire to minimize the risk of attacks from internal sources] and 12.5 [Assign to an individual or team the following information security management responsibilities].
Only 53.5% of organizations complied. with 12.1.2.b [Perform and document risk assessments at least annually.
And only 55.4% of organizations complied with 12.9.4 [Regularly train staff with security responsibilities]. Clearly, once the initial policy-setting activities are done, organizations are failing to translate compliance effort into business-as-usual activities such as training.
NC
12.2.b Review risk assessment documentation to verify that the risk assessment
process is performed at least annually.
NC 12.3 Examine the usage policies for critical technologies and interview responsible
personnel to verify the following policies are implemented and followed:
NC 12.3.1 Verify that the usage policies require explicit approval from authorized parties to
use the technologies.
NC 12.3.2 Verify that the usage policies require that all technology use be authenticated
with user ID and password or other authentication item (for example, token).
NC
NC 12.3.3 Verify that the usage policies require a list of all devices and personnel
authorized to use the devices.
NC 12.3.4 Verify that the usage policies define a method to accurately and readily
determine owner, contact information, and purpose (for example, labeling, coding,
and/or inventorying of devices).
NC 12.3.5 Verify that the usage policies require acceptable uses for the technology.
NC 12.3.6 Verify that the usage policies require acceptable network locations for the
technology.
NC 12.3.7 Verify that the usage policies require a list of company- approved products.
12.3.8 Verify that the usage policies require automatic disconnect of sessions for
remote-access technologies after a specific period of inactivity.
12.3.8.b Examine configurations for remote access technologies to verify that remote
access sessions will be automatically disconnected after a specific period of inactivity.
NC
NC 12.3.9 Verify that the usage policies require activation of remote- access technologies
used by vendors and business partners only when needed by vendors and business
partners, with immediate deactivation after use.
NC 12.3.10.a Verify that the usage policies prohibit copying, moving, or storing of
cardholder data onto local hard drives and removable electronic media when accessing
such data via remote-access technologies.
12.3.10.b For personnel with proper authorization, verify that usage policies require the
protection of cardholder data in accordance with PCI DSS Requirements.
NC 12.4.a Verify that information security policy and procedures clearly define information
security responsibilities for all personnel.
12.4.b Interview a sample of responsible personnel to verify they understand the
security policies.
NC 12.5 Verify the formal assignment of information security to a Chief Security Officer or
other security-knowledgeable member of management.
Obtain and examine information security policies and procedures to verify that the
following information security responsibilities are specifically and formally assigned:
NC 12.5.1 Verify that responsibility for creating and distributing security policies and
procedures is formally assigned.
NC 12.5.2 Verify that responsibility for monitoring and analyzing security alerts and
distributing information to appropriate information security and business unit
management personnel is formally assigned.
C18.1 12.5.3 Verify that responsibility for creating and distributing security incident response
and escalation procedures is formally assigned.
NC 12.5.4 Verify that responsibility for administering user account and authentication
management is formally assigned.
NC 12.5.5 Verify that responsibility for monitoring and controlling all access to data is
formally assigned.
12.6.a Verify the existence of a formal security awareness program for all personnel.
12.6.b Obtain and examine security awareness program procedures and
documentation and perform the following:
NC 12.6.1.a Verify that the security awareness program provides multiple methods of
communicating awareness and educating personnel (for example, posters, letters,
memos, web based training, meetings, and promotions).
12.6.1.b Verify that personnel attend awareness training upon hire and at least
annually.
C9.1
C9.2
NC
12.6.1.c Interview a sample of personnel to verify they have completed awareness
training and are aware of the importance of cardholder data security.
NC 12.6.2 Verify that the security awareness program requires personnel to acknowledge,
in writing or electronically, at least annually that they have read and understand the
information security policy.
NC 12.7 Inquire with Human Resource department management and verify that
background checks are conducted (within the constraints of local laws) on potential
personnel prior to hire who will have access to cardholder data or the cardholder data
environment.
NC
12.8 Through observation, review of policies and procedures, and review of supporting
documentation, verify that processes are implemented to manage service providers
with whom cardholder data is shared, or that could affect the security of cardholder
data (for example, backup tape storage facilities, managed service providers such as
web-hosting companies or security service providers, those that receive data for fraud
modeling purposes, etc.), as follows:
NC 12.8.1 Verify that a list of service providers is maintained.
C12.13 12.8.2 Observe written agreements and confirm they include an acknowledgement by
service providers that they are responsible for the security of cardholder data the
service providers possess or otherwise store, process or transmit on behalf of the
customer, or to the extent that they could impact the security of the customers
cardholder data environment.
NC 12.8.3 Verify that policies and procedures are documented and were followed including
proper due diligence prior to engaging any service provider.
NA 12.8.4 Verify that the entity maintains a program to monitor its service providers PCI
DSS compliance status at least annually.
12.8.5 Verify the entity maintains information about which PCI DSS requirements are
managed by each service provider, and which are managed by the entity.
12.9 Additional testing procedure for service providers: Review service providers
policies and procedures and observe written agreement templates to confirm the
service provider acknowledges in writing to customers that the service provider will
maintain all applicable PCI DSS requirements to the extent the service provider handles,
has access to, or otherwise stores, processes or transmits the customers cardholder
data or sensitive authentication data, or manages the customer's cardholder data
environment on behalf of a customer.
C18.1 12.10 Examine the incident response plan and related procedures to verify entity is
prepared to respond immediately to a system breach by performing the following:
12.10.1.a Verify that the incident response plan includes:
- Roles, responsibilities, and communication strategies in the event of a compromise
including notification of the payment brands, at a minimum:
- Specific incident response procedures
- Business recovery and continuity procedures
- Data back-up processes
- Analysis of legal requirements for reporting compromises (for example, California Bill
1386 which requires notification of affected consumers in the event of an actual or
suspected compromise for any business with California residents in their database)
- Coverage and responses for all critical system components
- Reference or inclusion of incident response procedures from the payment brands
12.10.1.b Interview personnel and review documentation from a sample of
previously reported incidents or alerts to verify that the documented incident
response plan and procedures were followed.
C18.2 12.10.2 Verify that the plan is tested at least annually.
C18.2
C18.4
NC 12.10.3 Verify through observation and review of policies, that designated personnel
are available for 24/7 incident response and monitoring coverage for any evidence of
unauthorized activity, detection of unauthorized wireless access points, critical IDS
alerts, and/or reports of unauthorized critical system or content file changes.
C18.5
C18.6
12.10.4 Verify through observation and review of policies that staff with responsibilities
for security breach response are periodically trained.
NC 12.1.5 Verify through observation and review of processes that monitoring and
responding to alerts from security systems including detection of unauthorized wireless
access points are covered in the Incident Response Plan.
NC 12.10.6 Verify through observation and review of policies that there is a process to
modify and evolve the incident response plan according to lessons learned and to
incorporate industry developments.
Validation Instructions for QSA/ISA
(For In-place requirements)

Priority A
Identify the documented information security policy examined.
<Report Findings Here>
Describe how the information security policy was examined to verify that it is published
and disseminated to:
All relevant personnel.
<Report Findings Here>
All relevant vendors and business partners.
<Report Findings Here>
6 0
Identify the document reviewed to verify that the information security policy is
reviewed at least annually and updated as needed to reflect changes to business
objectives or the risk environment.
<Report Findings Here>
Describe how the information security policy was verified to be:
Reviewed at least annually.
<Report Findings Here>
Updated as needed to reflect changes to business objectives or the risk environment.
<Report Findings Here>
6 0
Describe how it was verified that an annual risk process is documented and:
Identifies assets, threats and vulnerabilities.
Results in formal risk assessment.
1 0
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environment.
Major Observations from the 2014 Verizon PCI Compliance Report:
Organizations found control 12.4 *Ensure that the security policy and procedures clearly define information security responsibilities for all personnel+ easiest to comply with 83.2% of organizations fulfilled all the subcontrols.
79.2% and 74.3% of organizations respectively were compliant with all the subcontrols of 12.7 [Screen potential personnel prior to hire to minimize the risk of attacks from internal sources] and 12.5 [Assign to an individual or team the following information security management responsibilities].
Only 53.5% of organizations complied. with 12.1.2.b [Perform and document risk assessments at least annually.
And only 55.4% of organizations complied with 12.9.4 [Regularly train staff with security responsibilities]. Clearly, once the initial policy-setting activities are done, organizations are failing to translate compliance effort into business-as-usual activities such as training.
Selected Merchant Type
Identify the risk assessment result documentation reviewed to verify that:
The risk assessment process is performed at least annually.
The risk assessment is performed upon significant changes to the environment.
The documented risk assessment process was followed.
<Report Findings Here>
1 0
Identify critical technologies in use.
<Report Findings Here>
Identify the usage policies for all identified critical technologies reviewed to verify the
following policies (12.3.1-12.3.10) are defined:
Explicit approval from authorized parties to use the technologies.
All technology use to be authenticated with user ID and password or other
authentication item.
A list of all devices and personnel authorized to use the devices.
A method to accurately and readily determine owner, contact information, and
purpose.
Acceptable uses for the technology.
Acceptable network locations for the
technology.
A list of company-approved products.
Automatic disconnect of sessions for remote-access technologies after a specific period
of inactivity.
Activation of remote-access technologies used by vendors and business partners only
when needed by vendors and business partners, with immediate deactivation after use.
Prohibit copying, moving, or storing of cardholder data onto local hard drives and
removable electronic media when accessing such data via remote-access technologies.
<Report Findings Here>
Identify the responsible personnel interviewed who confirm usage policies for all
identified critical technologies are implemented and followed (for 12.3.112.3.10): see
above.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
include processes for explicit approval from authorized parties to use the technologies.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
include processes s for all technology used to be authenticated with user ID and
password or other authentication item.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
include processes define a list of all devices and personnel authorized to use the
devices.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
define a method to accurately and readily determine:
Owner
Contact Information
Purpose
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
define acceptable uses for the technology.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
define acceptable network locations for the technology.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
include a list of company-approved products.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
require automatic disconnect of sessions for remote- access technologies after a
specific period of inactivity.
<Report Findings Here>
6 0
Describe how configurations for remote access technologies were examined to verify
that remote access sessions will be automatically disconnected after a specific period
of inactivity.
<Report Findings Here>
Identify any remote access technologies in use.
<Report Findings Here>
Identify the period of inactivity specified.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
require activation of remote-access technologies used by vendors and business
partners only when needed by vendors and business partners, with immediate
deactivation after use.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
prohibit copying, moving or storing of cardholder data onto local hard drives and
removable electronic media when accessing such data via remote- access technologies.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that the usage policies were verified to
require, for personnel with proper authorization, the protection of cardholder data in
accordance with PCI DSS Requirements.
<Report Findings Here>
6 0
Identify the information security policy and procedures reviewed to verify that they
clearly define information security responsibilities for all personnel.
<Report Findings Here>
6 0
Identify the responsible personnel interviewed for this testing procedure who confirm
they understand the security policy.
<Report Findings Here>
6 0
dentify the information security policies reviewed to verify the specific and formal
assignment of the following (including 12.5.1- 12.5.5):
Information security to a Chief Security Officer or other security-knowledgeable
member of management.
Responsibility for establishing, documenting and distributing security policies and
procedures.
Monitoring and analyzing security alerts and distributing information to appropriate
information security and business unit management personnel.
Establishing, documenting, and distributing security incident response and escalation
procedures.
Administering user account and authentication management.
Monitoring and controlling all access to data.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that responsibilities were verified to be
formally assigned for:
Establishing security policies and procedures.
Documenting security policies and procedures.
Distributing security policies and procedures.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that responsibilities were verified to be
formally assigned for:
Monitoring and analyzing security alerts.
Distributing information to appropriate information security and business unit
management personnel.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that responsibilities were verified to be
formally assigned for:
Establishing security incident response and escalation procedures.
Documenting security incident response and escalation procedures.
Distributing security incident response and escalation procedures.
<Report Findings Here>
4
0
Provide the name of the assessor who attests that responsibilities were verified to be
formally assigned for administering user account and authentication management.
<Report Findings Here>
6 0
Provide the name of the assessor who attests that responsibilities were verified to be
formally assigned for:
Monitoring all access to data
Controlling all access to data
<Report Findings Here>
6 0
Identify the documented security awareness program reviewed to verify it provides
awareness to all personnel about the importance of cardholder data security.
<Report Findings Here>
6 0
Identify the documented security awareness program procedures and additional
documentation examined to verify that:
The security awareness program provides multiple methods of communicating
awareness and educating personnel.
Personnel attend security awareness training:
- Upon hire
- At least annually
Personnel acknowledge, in writing or electronically and at least annually, that they have
read and understand the information security policy.
<Report Findings Here>
6 0
Describe how the security awareness program provides multiple methods of
communicating awareness and educating personnel.
<Report Findings Here>
6 0
Describe how it was observed that all personnel attend security awareness training:
Upon hire
<Report Findings Here>
At least annually
<Report Findings Here>
6 0
Identifythesampleofpersonnelinterviewed who confirm they have completed security
awareness training.
<Report Findings Here>
For the interview, summarize details of the interview that verify their awareness of the
importance of cardholder data security.
<Report Findings Here>
6 0
Describe how it was verified that, per the security awareness program, all personnel:
Acknowledge that they have read and understand the information security policy
(including whether this is in writing or electronic).
<Report Findings Here>
Provide an acknowledgement at least annually
<Report Findings Here>
6 0
Identify the documented policy reviewed to verify requirement for background checks
to be conducted:
On potential personnel who will have access to cardholder data or the cardholder data
environment.
Prior to hiring the personnel.
<Report Findings Here>
Identify the Human Resources personnel interviewed who confirm background checks
are conducted:
On potential personnel who will have access to cardholder data or the cardholder data
environment.
Prior to hiring the personnel.
<Report Findings Here>
Describe how it was verified that background checks are conducted (within the
constraints of local laws):
<Report Findings Here>
On potential personnel who will have access to cardholder data or the cardholder data
environment.
<Report Findings Here>
Prior to hiring the personnel.
<Report Findings Here>
6 0
Identify the documented policies and procedures to manage service providers with
whom cardholder data is shared, or that could affect the security of cardholder data,
reviewed to verify policy defines the following from 12.8.112.8.5:
Maintain a list of service providers.
Maintain a written agreement that includes an acknowledgement that the service
providers will maintain all applicable PCI DSS requirements to the extent the service
provider handles, has access to, or otherwise stores, processes, or transmits the
customers cardholder data or sensitive authentication data, or manages the
customer's cardholder data environment on behalf of a customer.
Ensure there is an established process for engaging service providers including proper
due diligence prior to engagement.
Maintain a program to monitor service providers PCI DSS compliance status at least
annually.
Maintain information about which PCI DSS requirements are managed by each service
provider, and which are managed by the entity.
<Report Findings Here>
2
1
Describe how the documented list of service providers was observed to be maintained
(kept up-to-date).
<Report Findings Here>
2
1
Describe how written agreements for each service provider were observed to confirm
they include an acknowledgement by service providers that they will maintain all
applicable PCI DSS requirements to the extent the service provider handles, has access
to, or otherwise stores, processes, or transmits the customers cardholder data or
sensitive authentication data, or manages the customer's cardholder data environment
on behalf of a customer.
<Report Findings Here>
2
1
Describe how it was verified that the procedures for proper due diligence prior to
engaging a service provider are implemented, as documented in the policies and
procedures at 12.8.
<Report Findings Here>
2
1
Describe how it was verified that the entity maintains a program to monitor its service
providers PCI DSS compliance status at least annually.
<Report Findings Here>
2
1
Describe how it was observed that the entity maintains information about which PCI
DSS requirements are managed by each service provider, and which are managed by
the entity.
<Report Findings Here>
2
1
Identify whether the assessed entity is a service provider. (yes/no)
If no, mark the remainder of 12.9 as Not Applicable.
If yes:
Indicate whether this ROC is being completed prior to June 30, 2015. (yes/no)
<Report Findings Here>
If yes AND the assessed entity does not have this in place ahead of the requirements
effective date, mark the remainder of 12.9 as Not Applicable.
If no OR if the assessed entity has this in place ahead of the requirements effective
date:
<Report Findings Here>
Identify the service providers policies and procedures reviewed to verify that the
service provider acknowledges in writing to customers that the service provider will
maintain all applicable PCI DSS requirements to the extent the service provider handles,
has access to, or otherwise stores, processes, or transmits the customers cardholder
data or sensitive authentication data, or manages the customer's cardholder data
environment on behalf of a customer.
<Report Findings Here>
Describe how written agreement templates were observed to verify that the service
provider acknowledges in writing to customers that the service provider will maintain
all applicable PCI DSS requirements to the extent the service provider handles, has
access to, or otherwise stores, processes, or transmits the customers cardholder data
or sensitive authentication data, or manages the customer's cardholder data
environment on behalf of a customer.
<Report Findings Here>
2
0
Identify the documented incident response plan and related procedures examined to
verify the entity is prepared to respond immediately to a system breach, with defined
processes as follows from 12.10.112.10.6:
Create the incident response plan to be implemented in the event of system breach.
Test the plan at least annually.
Designate specific personnel to be available on a 24/7 basis to respond to alerts:
- 24/7incidentmonitoring
- 24/7incidentresponse
Provide appropriate training to staff with security breach response responsibilities.
Include alerts from security monitoring systems, including but not limited to intrusion-
detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.
Develop a process to modify and evolve the incident response plan according to lessons
learned and to incorporate industry developments.
<Report Findings Here>
4
0
Provide the name of the assessor who attests that the incident response plan was
verified to include:
Roles and responsibilities.
Communication strategies.
Requirement for notification of the payment brands.
Specific incident response procedures.
Business recovery and continuity
procedures.
Data back-up processes.
Analysis of legal requirements for reporting compromises.
Coverage for all critical system components.
Responses for all critical system components.
Reference or inclusion of incident response procedures from the payment brands.
<Report Findings Here>
4
0
Identify the sample of personnel interviewed who confirm that the documented
incident response plan and procedures are followed.
<Report Findings Here>
Identify the sample of previously reported incidents or alerts reviewed for this testing
procedure.
<Report Findings Here>
For each item in the sample, describe how documentation was reviewed to confirm
that the documented incident response plan and procedures are followed.
<Report Findings Here>
4
0
Describe how it was observed that the incident response plan is tested at least annually.
<Report Findings Here>
4
0
Identify the document requiring 24/7 incident response and monitoring coverage for:
Any evidence of unauthorized activity.
Detection of unauthorized wireless access
points.
Critical IDS alerts.
Reports of unauthorized critical system or content file changes.
<Report Findings Here>
Identify the sample of responsible personnel interviewed who confirm 24/7 incident
response and monitoring coverage for:
Any evidence of unauthorized activity.
Detection of unauthorized wireless access
points.
Critical IDS alerts.
Reports of unauthorized critical system or content file changes.
<Report Findings Here>
Describe how it was observed that designated personnel are available for 24/7 incident
response and monitoring coverage
<Report Findings Here>
Any evidence of unauthorized activity.
<Report Findings Here>
Detection of unauthorized wireless access points.
<Report Findings Here>
Critical IDS alerts.
<Report Findings Here>
Reports of unauthorized critical system or content file changes.
4
0
Identify the sample of responsible personnel interviewed who confirm that staff with
responsibilities for security breach response are periodically trained.
<Report Findings Here>
Identify the documented policy reviewed that defines that staff with responsibilities for
security breach response are periodically trained.
<Report Findings Here>
Describe how it was observed that staff with responsibilities for security breach
4
0
Describe how processes were reviewed to verify that monitoring alerts from security
monitoring systems, including detection of unauthorized wireless access points, are
covered in the Incident Response Plan.
<Report Findings Here>
Describe how processes were reviewed to verify that responding to alerts from security
monitoring systems, including detection of unauthorized wireless access points, are
covered in the Incident Response Plan.
<Report Findings Here>
4
0
Identify the documented policy reviewed to verify that processes are defined to modify
and evolve the incident response plan:
According to lessons learned.
To incorporate industry developments.
<Report Findings Here>
Identify the sample of responsible personnel interviewed who confirm that processes
are implemented to modify and evolve the incident response plan:
According to lessons learned.
To incorporate industry developments.
<Report Findings Here>
Describe how it was observed that processes are implemented to modify and evolve
the incident response plan:
<Report Findings Here>
According to lessons learned.
<Report Findings Here>
To incorporate industry developments.
<Report Findings Here>
4
0
226 6
A-EP PE2P B B-IP C-VT C D S In Place? Severity Proofs /
Documentation links
1 1 1 1 1 1 1 1
N 1
1 1 1 1 1 1 1 1
N 1
0 0 0 0 0 0 1 1
N 6
D
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environment.
Selected Merchant Type
0 0 0 0 0 0 1 1
N 6
0 0 0 1 0 0 1 1
N 1
0 0 1 0 1 1 1 1
N 1
0 0 0 0 0 1 1 1
N 1
0 0 1 1 1 1 1 1
N 1
0 0 0 0 0 0 1 1
N 1
0 0 1 1 1 1 1 1
N 1
0 0 0 0 0 1 1 1
N 1
0 0 0 0 0 0 1 1
N 1
0 0 0 0 0 1 1 1
N 1
0 0 0 0 0 1 1 1
C 0
0 0 0 1 0 1 1 1
N 1
0 0 0 0 0 0 1 1
N 1
0 0 0 0 0 0 1 1
N 1
1 1 1 1 1 1 1 1
N 1
1 1 1 1 1 1 1 1
NT 1
1 1 1 1 1 1 1 1
N 1
0 0 0 0 0 0 1 1
N 1
0 0 0 0 0 0 1 1
N 1
0 1 1 1 1 1 1 1
N 3
1 0 0 0 0 0 1 1
N 1
0 0 0 0 0 0 1 1
N 1
1 1 1 1 1 1 1 1
N 1
1 1 0 1 0 0 1 1
N 1
0 1 0 0 0 0 1 1
N 1
0 1 0 0 0 0 1 1
N 1
0 1 0 0 0 0 1 1
Y 0
0 0 0 0 0 0 1 1
N 1
0 0 0 0 0 0 1 1
N 1
1 0 1 1 1 1 1 1
N 5
1 1 1 1 1 1 1 1
N 5
1 1 1 1 1 1 1 1
N 5
1 1 1 1 1 1 1 1
N 5
1 1 1 1 1 1 1 1
N 5
1 1 0 1 0 1 1 1
Y 0
0 0 0 0 0 0 0 1
Y 0
0 0 0 0 0 0 1 1
N 3
1 1 0 1 0 1 1 1
N 3
1 0 0 1 0 1 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1
Y 0
16 17 15 20 15 23 46 47 Y 88
N
C
NT
NA
Stage of implementation Remediation plan
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environment.
Estimated date for completion Comments Owner
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environment.
IT Types
Server
Firewall & Router
Switches
Mail
DNS
Database
Application
Web application
Web server
WAP
POS
Others
Criticality
High
Medium
Low