PCI Compliance Dashboard VERSION 0

Please feel free to use this compliance dashboard spreadsheet to sustain your journe PCI compliance, to support the discussion with your internal team, QSA and acquiring b

Please send any comments, observations or suggestions to Didier_godart@rapid7.com

V0.1 V0.2 What's new? Requirements and testing procedures Add merchant type for each requirements Jan 2011 Feb 2011

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

August 2011

V0.4

Add a sheet" What is my merchant Type?" with the full description of the merchant October 2011 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 ROCQSA Reporting Instruction Manual Add Guidance for each requirements from the "Navigating PCI DSS V2.0" November 2011 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

V0.5

V0.6

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) 3. Use the compensating controls sheet to describe your controls whenever used. 4.View your compliance progress through the "Executive summary" and " Charts"

December 2011

Compliance Dashboard home page

More information PCI 30 seconds newsletter - PCI what are you talking about? PCI 30 seconds newsletter - Payment processing terminology and workflow PCI 30 seconds newsletter - Distributing roles PCI 30 seconds newsletter - Merchant levels PCI 30 seconds newsletter ) What is your type? PCI 30 seconds newsletter - PCI DSS in a nutshel PCI 30 seconds newsletter - Define the scope of an assessment PCI 30 seconds newsletter - certification program, striving for quality PCI 30 seconds newsletter- The validation toolbox PCI 30 seconds newsletter - Prioritized Approach PCI 30 seconds newsletter - Tokenization PCI 30 seconds newsletter - the gap analysis process PCI 30 seconds newsletter - Compensating controls, magic trick or mirage? PCI 30 seconds newsletter - The world is not perfect! PCI 30 seconds newsletter - Nice Look! 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

ERSION 0.5

ustain your journey to SA and acquiring banks.

dart@rapid7.com
Contributor Peter Hill Didier Godart Risk Product Manager Rapid7 +32 498787744 SkypeID Dgozone didier_godart@rapid7.co m Didier Godart Risk Product Manager Rapid7 +32 498787744 SkypeID Dgozone didier_godart@rapid7.co m Didier Godart Risk Product Manager Rapid7 +32 498787744 SkypeID Dgozone didier_godart@rapid7.co m Didier Godart Risk Product Manager Rapid7 +32 498787744 SkypeID Dgozone didier_godart@rapid7.co m

About Didier

About Rapid7

Join the community!

Didier Godart Risk Product Manager Rapid7 +32 498787744 SkypeID Dgozone didier_godart@rapid7.co m Swathy Anand Vice President - Project Management Fuze Network swathyanand@gmail.co m

About Didier

About Rapid8

Join the community!

About Swathy

About Fuze Network

ORGANIZATION NAME Merchant Type: D You MUST enter in cell B3 your Merchant type (A, B, C, C-VT, D)
# Compensating Controls 0 0 0 0 0 0 0 0 0 0 0 0

PCI-DSS REQUIREMENTS % compliance 1 2 3 4 5 6 7 8 9 10 11 12 100% 0% 5% 0% 0% 0% 0% 0% 0% 0% 0% 0%

# of Requirements 28 26 37 9 7 36 9 33 29 33 25 44

# in Place # not in Place 28 0 2 0 0 0 0 0 0 0 0 0 0 26 35 9 7 36 9 33 29 33 25 44

Severity 0 67 135 18 14 129 36 111 111 132 64 216

PCI Severity per requirements

250 216 200

150

135

129 111 111

132

100
67 50 18 0 0 14 36 64

Compliance % per requirement

120%

100%

80%

60%

40%

20%

0%

10

11

12

216

12

Name

Firstname

Email

Tel

Function

Areas of expertize Section 1 Section 2 Section 3 Section 4 Section 5 Section 6

Section 7 Section 8 Section 9 Section 10 Section 11 Section 12

What is your merchant type? - Select your merchant Type

Types A B Description Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants. Imprint-only merchants with no electronic cardholder data storage, or standalone, dial- out terminal merchants with no electronic cardholder data storage Merchants using only web-based virtual terminals, no electronic cardholder data storage Merchants with payment application systems connected to the Internet, no electronic cardholder data storage
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.

C-VT C D

Compensating Constraints Control Id # List constraints precluding compliance with the original requirement.

Objective

Identified Risk

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 Define how the compensating controls Define process and controls explain how they address the objectives of were validated and tested. in place to maintain the original control and the increased risk, compensating controls if any.

AAA

Access Control Account Data Account Number Acquirer Adware AES ANSI Anti-Virus

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. Mechanisms that limit availability of information or information-processing resources only to authorized persons or applications. Account data consists of cardholder data plus sensitive authentication data. See Cardholder Data and Sensitive Authentication Data See Primary Account Number (PAN). Also referred to as acquiring bank or acquiring financial institution. Entity that initiates and maintains relationships with merchants for the acceptance of payment cards. Type of malicious software that, when installed, forces a computer to automatically display or download advertisements. 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). Acronym for American National Standards Institute. Private, non-profit organization that administers and coordinates the U.S. voluntary standardization and conformity assessment system. 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. Includes all purchased and custom software programs or groups of programs, including both internal and external (for example, web) applications. 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. See Audit Log. Acronym for Approved Scanning Vendor. Company approved by the PCI SSC to conduct external vulnerability scanning services.

Application Audit Log

Audit Trail ASV

Authentication

Authentication Credentials Authorization

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 Combination of the user ID or account ID plus the authentication factor(s) used to authenticate an individual, device, or process, 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.

B
Backup Bluetooth Duplicate copy of data made for archiving purposes or for protecting against damage or loss. Wireless protocol using short-range communications technology to facilitate transmission of data over short distances.

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

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

CERT

CIS

Column-Level Database 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. 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. Screen and keyboard which permits access and control of a server, mainframe computer or other system type in a networked environment. Individual purchasing goods, services, or both. 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.

Compromise Console Consumer Cryptography

D
Database Database Administrator Default Accounts Structured format for organizing and maintaining easily retrievable information. Simple database examples are tables and spreadsheets. Also referred to as DBA. Individual responsible for managing and administering databases. 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. 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.

Default Password

Degaussing Disk Encryption

DMZ

DNS DSS Dual Control

Also called disk degaussing. Process or technique that demagnetizes the disk such that all data stored on the disk is permanently destroyed. 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. 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. 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. Acronym for Data Security Standard and also referred to as PCI DSS. 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.) See Stateful Inspection.

Dynamic Packet Filtering

E
ECC Egress Filtering Encryption Acronym for Elliptic Curve Cryptography. Approach to public-key cryptography based on elliptic curves over finite fields. See Strong Cryptography. Method of filtering outbound network traffic such that only explicitly allowed traffic is permitted to leave the network. 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. A sequence of mathematical instructions used for transforming unencrypted text or data to encrypted text or data, and back again. See Strong Cryptography.

Encryption Algorithm

Entity

Term used to represent the corporation, organization or business which is undergoing a PCI DSS review.

F
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. Technique or technology (either software or hardware) for encrypting the full contents of specific files. Alternatively, see Disk Encryption or Column-Level Database Encryption. 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. 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. 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. 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. File-Level Encryption FIPS Firewall

Forensics

FTP

G
GPRS

GSM

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

H
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). Main computer hardware on which computer software is resident. 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. Acronym for hypertext transfer protocol. Open internet protocol to transfer or convey information on the World Wide Web. 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 webbased logins. 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).

Host Hosting Provider

HTTP HTTPS

Hypervisor

I
ID Identifier for a particular user or application.

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. 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. A cryptographic token that replaces the PAN, based on a given index for an unpredictable value. Protection of information to insure confidentiality, integrity, and availability. Discrete set of structured data resources organized for collection, processing, maintenance, use, sharing, dissemination, or disposition of information. Method of filtering inbound network traffic such that only explicitly allowed traffic is permitted to enter the network. 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. 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. Also referred to as internet protocol address. Numeric code that uniquely identifies a particular computer on the Internet. 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. Acronym for intrusion prevention system. Beyond an IDS, an IPS takes the additional step of blocking the attempted intrusion. 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.

IETF

Index Token Information Security Information System Ingress Filtering Insecure Protocol/Service/Port

IP

IP Address IP Address Spoofing

IPS IPSEC

ISO

Issuer

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. 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. Examples of issuing services may include but are not limited to authorization and card personalization.

Issuing services

K
Key Key Management 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. 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.

L
LAN

LDAP

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. Acronym for Lightweight Directory Access Protocol. Authentication and authorization data repository utilized for querying and modifying user permissions and granting access to protected resources. See Audit Log. 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.

Log LPAR

M
MAC MAC Address Magnetic-Stripe Data Acronym for message authentication code. In cryptography, it is a small piece of information used to authenticate a message. See Strong Cryptography. Abbreviation for media access control address. Unique identifying value assigned by manufacturers to network adapters and network interface cards. 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. 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. 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. 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. 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. 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. Acronym for multi protocol label switching. Network or telecommunications mechanism designed for connecting a group of packet-switched networks.

Mainframe

Malicious Software / Malware

Masking

Merchant

Monitoring MPLS

N
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. Two or more computers connected together via physical or wireless means. 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. Include, but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. 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 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. 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. Security-scanning software that maps networks and identifies open ports in network resources. Individuals, excluding cardholders, who access system components, including but not limited to employees, administrators, and third parties. Acronym for Network Time Protocol. Protocol for synchronizing the clocks of computer systems, network devices and other system components. Network Network Administrator

Network Components Network Security Scan

Network Segmentation

NIST

NMAP Non-Consumer Users NTP

O
Off-the-Shelf Operating System / OS OWASP Description of products that are stock items not specifically customized or designed for a specific customer or user and are readily available for use. 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. 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).

P
PA-QSA PAN Acronym for Payment Application Qualified Security Assessor, company approved by the PCI SSC to conduct assessments on payment applications against the PA-DSS. 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. A string of characters that serve as an authenticator of the user. 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 A means of structuring SQL queries to limit escaping and thus prevent injection attacks. Acronym for port address translation and also referred to as network address port translation. Type of NAT that also translates the port numbers. Update to existing software to add functionality or to correct a defect. Any application that stores, processes, or transmits cardholder data as part of authorization or settlement 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. Password / Passphrase Pad

Parameterized Queries PAT Patch Payment Application Payment Cards

PCI
PDA

PED Penetration Test

Acronym for Payment Card Industry. Acronym for personal data assistant or personal digital assistant. Handheld mobile devices with capabilities such as mobile phones, e-mail, or web browser. PIN entry device
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 Personally Identifiable Information PIN

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. Information that can be utilized to identify an individual including but not limited to name, address, social security number, phone number, etc. 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.
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. Acronym for Point of Interaction, the initial point where data is read from a card. An electronic transactionacceptance 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.

PIN Block
POI

Policy POS Private Network

Procedure

Organization-wide rules governing acceptable use of computing resources, security practices, and guiding development of operational procedures Acronym for point of sale. Hardware and/or software used to process payment card transactions at merchant locations. 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. Descriptive narrative for a policy. Procedure is the how to for a policy and describes how the policy is to be implemented.

Protocol PTS

Agreed-upon method of communication used within networks. Specification describing rules and procedures that computer products should follow to perform activities on a network. 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. 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. Acronym for PIN verification value. Discretionary value encoded in magnetic stripe of payment card.

Public Network

PVV

Q
QSA Acronym for Qualified Security Assessor, company approved by the PCI SSC to conduct PCI DSS on-site assessments.

R
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 twofactor authentication. Acronym for role-based access control. Control used to restrict access by specific authorized users based on their job responsibilities. RBAC 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. Process of changing cryptographic keys. Periodic re-keying limits the amount of data encrypted by a single key. A lab that is not maintained by the PA-QSA. An entity that sells and/or integrates payment applications but does not develop them. The standard identified by the Internet Engineering Task Force (IETF) that defines the usage and appropriate address ranges for private (non-internet routable) networks. 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. Type of malicious software that when installed without authorization, is able to conceal its presence and gain administrative control of a computer system. 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. 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.

Re-keying

Remote Lab Environment Reseller / Integrator RFC 1918 Risk Analysis / Risk Assessment Rootkit Router

RSA

S
Salt Sampling Random string that is concatenated with other data prior to being operated on by a hash function. See also Hash. 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. Acronym for SysAdmin, Audit, Networking and Security, an institute that provides computer security training and professional certification. (See www.sans.or 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.

SANS Scoping

SDLC Secure Coding Secure Wipe Security Officer Security Policy Security Protocols SAQ Sensitive Area

Acronym for system development life cycle. Phases of the development of a software or computer system that includes planning, analysis, design, testing, and implementation. The process of creating and implementing applications that are resistant to tampering and/or compromise. Also called secure delete, a program utility used to delete specific files permanently from a computer system. Also called secure delete, a program utility used to delete specific files permanently from a computer system. Set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information 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. Acronym for Self-Assessment Questionnaire. Tool used by any entity to validate its own compliance with the PCI DSS. 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 Server Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able to subvert the process. 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. 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 Code

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. Acronym for Secure Hash Algorithm. A family or set of related cryptographic hash functions including SHA-1 and SHA-2. See Strong Cryptography. 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. Acronym for Simple Network Management Protocol. Supports monitoring of network attached devices for any conditions that warrant administrative attention. Type of malicious software that when installed, intercepts or takes partial control of the users computer without the users consent. Acronym for Structured Query Language. Computer language used to create, modify, and retrieve data from relational database management systems. 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. Abbreviation for Secure Shell. Protocol suite providing encryption for network services like remote login or remote file transfer. 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. 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.

SHA-1/SHA-2 Smart Card

SNMP Spyware

SQL

SQL Injection

SSH SSL

Stateful Inspection

Strong Cryptography

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper keymanagement 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. Abbreviation for system administrator. Individual with elevated privileges who is responsible for managing a computer system or network. Any network component, server, or application included in or connected to the cardholder data environment. 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.

SysAdmin System Components System-level object

T
TACACS

TCP TDES TELNET Threat

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. Acronym for Transmission Control Protocol. Basic communication language or protocol of the Internet. 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. 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. 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 Token Transaction Data Trojan

Truncation

Trusted Network Two-Factor Authentication

Acronym for Transport Layer Security. Designed with goal of providing data secrecy and data integrity between two communicating applications. TLS is successor of SSL. 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. Data related to electronic payment card transaction. 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. 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. Network of an organization that is within the organizations ability to control or manage. 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).

U
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
Virtualization Virtual Machine Monitor (VMM) 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. 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 Virtual Appliance (VA)

Virtual Switch or Router

Virtual Terminal

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. 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. 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. 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. Abbreviation for virtual LAN or virtual local area network. Logical local area network that extends beyond a single traditional physical local area network. 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. Flaw or weakness which, if exploited, may result in an intentional or unintentional compromise of a system.

VLAN VPN

Vulnerability

W
WAN

Web Application

Acronym for wide area network. Computer network covering a large area, often a regional or company wide computer system. 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 WEP

Wireless Access Point WLAN WPA/WPA2

Computer that contains a program that accepts HTTP requests from web clients and serves the HTTP responses (usually web pages). 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. Network that connects computers without a physical connection to wires. Acronym for wireless local area network. Local area network that links two or more computers or devices without wires. 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.

Major Observations from the Verizon 2011 PCI Compliance Report: 44 percent compliance, compared to the 46 percent who were found compliant in previous report The most difficult part of meeting this requirement is the documentation of network device configurations, with only 63 percent of compa Documentation is however, its frequently outdated. Restricting inbound access (PCI Requirement 1.2.1) continues to be an issue for many being audited, with 23 percent of businesses found t Insecure traffic, such as FTP and Telnet, is still flowing through many networks. Most businesses dont have anyone with the time to dig into every rule in the firewalls to understand the complete rule sets.

PCI DSS Requirement

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

1.1.1 A formal process for approving and testing all A policy and process for approving and testing all connections and changes to the firewalls and routers will network connections and changes to the firewall help prevent security problems caused by misconfiguration and router configurations
of the network, router, or firewall. Data flows between virtual machines should be included in policy and process

1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks

Network diagrams enable the organization to identify the location of all its network devices. Additionally, the network diagram can be used to map the data flow of cardholder data across the network and between individual devices in order to fully understand the scope of the cardholder data environment. Without current network and data flow diagrams, devices with cardholder data may be overlooked and may unknowingly be left out of the layered security controls implemented for PCI DSS and thus vulnerable to compromise. Network and data flow diagrams should include virtual system components and document Intrahost data flows.

1.1.3 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone

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 Description of groups, roles, and This description of roles and assignment of responsibility responsibilities for logical management of network ensures that someone is clearly responsible for the components security of all components and is aware of their responsibility, and that no devices are left unmanaged.

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

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.

1.1.6 Requirement to review firewall and router rule sets at least every six months

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.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

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 Note: An untrusted network is any network that is manage. Failure to implement this measure correctly external to the networks belonging to the entity means that the entity will be vulnerable to unauthorized under review, and/or which is out of the entity's access by malicious individuals or software. ability to control or manage. 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 This requirement is intended to prevent malicious which is necessary for the cardholder data individuals from accessing the organization's network via environment. 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.

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.

1.2.2 Secure and synchronize router configuration files.

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

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. 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.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

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 Termination of IP connections both inbound and or outbound for traffic between the Internet and outbound provides opportunity for inspection and the cardholder data environment. 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 Do not allow internal addresses to pass from the Internet into the DMZ. Normally a packet contains the IP address of the computer that originally sent it. This allows other computers in the network to know where it came from. In certain cases, this sending IP address will be spoofed by malicious individuals. For example, malicious individuals send a packet with a spoofed address, so that (unless your firewall prohibits it) the packet will be able to come into your network from the Internet, looking like it is internal, and therefore legitimate, traffic. Once the malicious individual is inside your network, they can begin to compromise your systems. Ingress filtering is a technique you can use on your firewall to filter packets coming into your network to, among other things, ensure packets are not spoofed to look like they are coming from your own internal network. For more information on packet filtering, consider obtaining information on a corollary technique called egress filtering. 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.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

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

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.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organizations network.

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.

ations, with only 63 percent of companies meeting Requirement 1.1.5 regularly.

with 23 percent of businesses found to be non-compliant at the time of the assessment.

the complete rule sets.

Testing Procedure

1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to verify that standards are complete. Complete the following:

1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.

1.1.2.a Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all connections to cardholder data, including any wireless networks.

1.1.2.b Verify that the diagram is kept current.

1.1.3.a Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

1.1.3.b Verify that the current network diagram is consistent with the firewall configuration standards.

1.1.4 Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.

1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for businessfor example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

1.1.5.b Identify insecure services, protocols, and ports 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.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months.

1.1.6.b Obtain and examine documentation to verify that the rule sets are reviewed at least every six months.

1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows:

1.2.1.a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.

1.2.1.b 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 Verify that router configuration files are secure and synchronizedfor example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.

1.2.3 Verify that there are perimeter firewalls installed between any wireless networks and systems that store cardholder data, and that these firewalls deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

1.3 Examine firewall and router configurationsincluding but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segmentto determine that there is no direct access between the Internet and system components in the internal cardholder network segment, as detailed below.

1.3.1 Verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

1.3.2 Verify that inbound Internet traffic is limited to IP addresses within the DMZ.

1.3.3 Verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.

1.3.4 Verify that internal addresses cannot pass from the Internet into the DMZ.

1.3.5 Verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized

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

1.3.7 Verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks.

1.3.8.a 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 Verify that any disclosure of private IP addresses and routing information to external entities is authorized.

1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organizations network, have personal firewall software installed and active.

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by users of mobile and/or employee-owned computers.

Merchant TYPES

Validation instruction for QSA/ISA (For In-Place Requirements)

Priority

Identify the document(s) which defines the formal processes for: i. Testing of all network connections ii. Approval of all network connections iii. Testing of all firewall configuration changes iv. Approval of all firewall configuration changes v. Testing of all router configuration changes vi. Approval of all router configuration changes 6 Describe how the documented processes were observed to be implemented, for: i. Testing of all network connections ii. Approval of all network connections iii. Testing of all firewall configuration changes iv. Approval of all firewall configuration changes v. Testing of all router configuration changes vi. Approval of all router configuration changes Identify the current network diagram(s). i. Iscurrent ii. Includes all connections to cardholder data iii. Includes any wireless network connections

.Identify the document requiring that the network diagram is kept current. 1 process is followed.

Identify the firewall configuration standards that define requirements for: i. A firewall at each Internet connection ii. A firewall between any DMZ and the internal network zone

.Identify the current network diagrams and firewall configuration standards reviewed. another. Identify the firewall configuration standards that include descriptions of the following for logical management of components: i. Groups ii. Roles iii. Responsibilities for logical management of components: i. Groups ii. Roles iii. Responsibilities interviewed, and who confirm that the roles and responsibilities are assigned as documented for: i. Logical management of router components ii. Logicaleach of the following identify the firewall configuration standards which For management of firewall components define those necessary for business, including a business justification for each: Services Protocols Ports For each of the following identify the router configuration standards which define those necessary for business, including a business justification for each: Services Protocols Ports 2

insecure service, protocol and port allowed: i. Identify the documented justification. ii. Identify the responsible personnel interviewed who confirm that each insecure service/protocol/port is necessary. iii. Identify the firewall and router configuration standards which define the security features required for each insecure service/protocol/port. iv. Describe how observed firewall configurations verify the security features are implemented. v. Describe how observed router configurations verify the security features are implemented Identify the firewall configuration standards that require a review of firewall rule sets at least every six months. at least every six months.

Identify documented results of previous: i. Firewall rule set reviews ii. Router rule set reviews i.Firewall rule set reviews are completed at least every six months. Router rule set reviews ii:are completed at least every six months.

Describe how observed firewall/router configurations limit traffic to that which is necessary for the cardholder data environment: i. Inbound ii. Outbound Identify the document that defines the restrictions and confirm this is consistent with the observed configurations: i. Inbound ii. Outbound Describe how inbound and outbound traffic was observed to be limited to that which is necessary for the cardholder data environment: i. Inbound ii. Outbound

Describe how firewall and router configuration were observed to specifically deny all other traffic: inboud and outbound. Describe how the router configuration files were observed to be secured

Describe how firewalls were observed to be in place between any wireless networks and systems that store cardholder data. from any wireless environment into the cardholder data environment. traffic from the wireless environment into the cardholder data environment is necessary for business purposes

Identify the document defining system components that provide authorized publicly accessible services, protocols, and ports. Describe how observed firewall/router configurations ensure that the DMZ limits inbounds traffic to only those system components

Describe how observed firewall/router configurations limit inbound Internet traffic to IP addresses within the DMZ. 2 within the DMZ. Identify the network documents/diagrams specifying that direct connections are not allowed for traffic between the Internet and the cardholder data environment: i. Inbound ii. Outbound between the Internet and the cardholder data environment: i. Inbound ii. Outbound environment confirms that direct connections are not permitted: i. Inbound ii. Outbound Describe how observed firewall/router configurations prevent internal addresses passing from the Internet into the DMZ. addresses cannot pass from the Internet into the DMZ. 2

Identify the document that explicitly defines authorized outbound traffic from the cardholder data environment to the Internet. authorized traffic. the Internet confirms that only explicitly authorized traffic is allowed. 2

Describe how observed firewall configurations implement stateful inspection. implemented (that is, only established connections are allowed into the network). 2

For all system components that store cardholder data: Identify the diagrams and/or other document(s) which define how system components are located on an internal network zone, segregated from the DMZ and other untrusted networks. Describe how observed network and system configurations confirm the system components are located on an internal network zone, segregated from the DMZ and other untrusted networks. Describe how observed network traffic confirms that the system components are located on an internal network zone, segregated from the DMZ and other untrusted networks. Identify the document defining methods to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet.

and routing information from being disclosed to the Internet. routing information are not disclosed to the Internet. Identify the documents that specifies whether any disclosure of private IP addresses and routing information to external parties is permitted For each permitted disclosure, identify the repsonsible personnel interviewed who confirmed that disclosure is authorized Describe how observed configurations ensure that any disclosure of private IP addresses and routing information to external entities is authorized.

Identify whether mobile and/or employee-owned computers with direct connectivity to the Internet are used to access the organizations network. Identify the document requiring that mobile and/or employee-owned computers with direct connectivity to the Internet have personal firewall software: i. Installed ii. Active Describe how personal firewall software was observed on mobile and/or employeeowned computers to be: i. Installed ii. Active Identify the document defining personal firewall software configuration standards. Describe how personal firewall software on mobile and/or employee-owned computers was observed to be: i. Configured by the organization to the documented configuration standards ii. Not alterable by mobile and/or employee-owned computer users

74

Merchant TYPES

C-VT

Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet.

Severity in case of non compliance

Proofs / Documentation links

Stage of implementation

10

28

Y N C

Remediation plan

Estimated date for completion

Comments

Owner

Malicious

Almost all systems administrators profess to know how

PCI DSS Requirement

NEW - Guidance

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

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

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

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 Sources of industry-accepted system hardening have established system-hardening standards may include, but are not limited to: recommendations, which advise how to correct these weaknesses. If systems are left with these - Center for Internet Security (CIS) weaknessesfor example, weak file settings or - International Organization for Standardization (ISO) default services and protocols (for services or - SysAdmin Audit Network Security (SANS) Institute protocols that are often not needed)an attacker - National Institute of Standards Technology (NIST) 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.

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

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.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, SFTP, 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.

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

2.2.4 Remove all unnecessary functionality, such as The server-hardening standards must include scripts, drivers, features, subsystems, file systems, processes to address unnecessary functionality with and unnecessary web servers. 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.4 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.

Requirement 2: Do not use vendor-sup

Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default

Major observations from the 2011 Verizon PCI Compliance Rep Up to 56 percent in compliance from 48 percent the year befor The most significant change was the requirement to change vendor-supplied default passwords, whic Requirements 2.2.3b (secure system configuration) and 2.2.4 (remove unnecessary services) both remain l ystems administrators profess to know how to configure a system to be secure (Requirement 2.2.3a), but when it comes down to building and maintaini

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.1 Verify the following regarding vendor default settings for wireless environments:

2.1.1.a Verify encryption keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the company or changes positions

2.1.1.b Verify default SNMP community strings on wireless devices were changed.

2.1.1.c Verify default passwords/passphrases on access points were changed.

2.1.1.d Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks.

2.1.1.e Verify other security-related wireless vendor defaults were changed, if applicable.

2.2.a Examine the organizations system configuration standards for all types of system components and verify the system configuration standards are consistent with industryaccepted hardening standards.

2.2.b Verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.2.

2.2.c Verify that system configuration standards are applied when new systems are configured.

2.2.d Verify that system configuration standards include each item below (2.2.1 2.2.4).

2.2.1.a For a sample of system components, 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 For a sample of system components, inspect enabled system services, daemons, and protocols. Verify that only necessary services or protocols are enabled.

2.2.2.b Identify any enabled insecure services, daemons, or protocols. Verify they are justified and that security features are documented and implemented.

2.2.3.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.

2.2.3.b Verify that common security parameter settings are included in the system configuration standards. 2.2.3.c For a sample of system components, verify that common security parameters are set appropriately.

2.2.4.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.4.b Verify enabled functions are documented and support secure configuration.

2.2.4.c Verify that only documented functionality is present on the sampled system components.

2.3 For a sample of system components, 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 remote login commands are not available for use internally. 2.3.c Verify that administrator access to the web-based management interfaces is encrypted with strong cryptography.

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

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker

Major observations from the 2011 Verizon PCI Compliance Report Up to 56 percent in compliance from 48 percent the year before. quirement to change vendor-supplied default passwords, which was up to 82 percent from 48 percent. ration) and 2.2.4 (remove unnecessary services) both remain low, at 74 percent and 67 percent respectively. ent 2.2.3a), but when it comes down to building and maintaining a system in a compliant manner (Requirement 2.2.3c), were still failing in over a quarte

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

A B C-VT

Identify the sample of system components observed. For each sampled system component, describe how attempts to log on using vendorsupplied accounts and passwords confirm that all default accounts and passwords are changed before installing a system on the network.

1 2

Identify the document requiring that wireless encryption keys must be changed: i. From default at installation ii. Anytime anyone with knowledge of the keys leaves the organization or changes positions processes for changing keys are followed: i. At installation ii. Anytime anyone with knowledge of the keys leaves the organization or changes positions completed as required.requiring that default SNMP community strings must be Identify the document changed. community strings are changed. Identify the document requiring that default passwords/passphrases on access points must be changed. passwords/passphrases are changed. Identify the document requiring that firmware on wireless devices must be updated to support encryption for authentification and transmission Describe how observed wireless configurations confirm that firware is updated to support strong encryption for authnetification and transmission. Identify the document that defines any other security-related wireless vendor defaults. related vendor defaults are changed, as applicable. Identify the documented system configuration standards i. Cover all types of system components ii. Address all known security vulnerabilities industry-accepted hardening standards. Describe the process for updating system configuration standards as new vulnerability issues are identified. followed. 3 2

1 2 1 2 1 2 1 2

updated with new vulnerability issues. Identify the document defining the process for applying system configuration standards to new systems. applied.

Identify the system configuration standards requiring that: i. Only one primary function is implemented per server, including virtual system components or devices, as applicable. ii. Only necessary services or protocols are enabled and security features are implemented for any required services, protocols or daemons considered insecure. iii. System security parameters are configured to prevent misuse. iv. All unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed. Identify the sample of system components observed. confirm that only one primary function per server is implemented. Identify personnel interviewed and describe how systems were observed to determine whether virtualization technologies are used. Identify the functions for which virtualization technologies are used. Identify the sample of virtual system components or devices observed. For each sampled virtual system component and device, describe how the observed configurations confirm only one primary function is implemented per virtual system component or device.

1 component: Describe how system configurations were inspected to identify all enabled: o Services o Daemons o Protocols Identify the document specifying that each enabled service, daemon and protocol is necessary for that system component.

From the sample of system components observed in 2.2.2.a, identify if any insecure services, daemons, or protocols are enabled. For each insecure service, daemon, or protocol identified: i. Briefly describe why it is considered to be insecure. ii. Identify the documented business justification. iii. Identify the document defining security features for the insecure service, daemon or protocol. iv. Describe how the observed system configurations confirm that security features are implemented in accordance with documentation. Identify the systems administrators, security managers and other responsible personnel interviewed. Describe how each person interviewed demonstrated they have knowledge of common security parameter settings for the system components that they configure. Identify the system configuration standards that define the common security parameter settings. Identify the sample of system components observed. were observed to be set according to the documented system configuration standards. Identify the sample of system components observed. unnecessary functionality is removed. For each sampled system component: i. Identify the document defining the authorized functions that are allowed to be enabled. ii. Describe how enabled functions were identified on each system component. iii. Confirm that all observed enabled functions are documented. iv. Describe how the enabled functions were observed to support secure configuration. For each sampled system component, describe how documentation and observed system configurations were compared to confirm that only documented functionality is present on the system components.

1 component: i. Identify the strong encryption method used for non-console administrative access. ii. Describe how strong encryption was observed to be invoked before the administrator password is requested. For each sampled system component, describe how the observed services and parameter files confirm that the following are not available for use internally: Telnett and other remote-login command For each sampled system component: i. Describe how administrator access to web-based management interfaces is configured to require strong cryptography. ii. Describe how administrator access to the web-based management interfaces was observed to confirm that all such access is encrypted with strong cryptography. Identify whether the assessed entity is a shared hosting provider. DSS Requirements for Shared Hosting Providers has been completed and is included in the ROC. 3 2

1 2 1 2

67

0 0

12

curity parameters

ngs are well known by hacker communities and are easily determined via public information.

ere still failing in over a quarter of all cases.

Select In Place ? (Y)es (N)o (C)ompensatin g control In case of C add a row in the Compensating Controls sheet.

Severity

Proofs / Documentation links

Stage of implementation

26

Y N C

67

Remediation plan

Estimated date for completion

Comments

Owner

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intru necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other

Major observations from the 2011 Verizon PCI Compliance report Keeping stored cardholder data to a minimum seems to be a particularly difficult task for many companies. Organizations rarely adhere to their retention policy 33 percent of businesses were unable to meet with Requirement 3.1 Requirement 3.4, encrypt cardholder data, is met only 63 percent of the time. Requirement 3.6.4 is met in only 61 percent of cases,

PCI DSS Requirement

NEW - Guidance

3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes, as follows.

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

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

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

If full track data is stored, malicious individuals who obtain that data can reproduce and sell payment cards.

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. 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.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.

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.

3.4 Render PAN unreadable anywhere it is stored Lack of protection of PANs can allow malicious (including on portable digital media, backup media, individuals to view or download this data. PANs and in logs) by using any of the following approaches: stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non- One-way hashes based on strong cryptography primary storage (backup, audit logs, exception or (hash must be of the entire PAN) troubleshooting logs) must all be protected. Damage - Truncation (hashing cannot be used to replace the from theft or loss of backup tapes during transport truncated segment of PAN) can be reduced by ensuring PANs are rendered - Index tokens and pads (pads must be securely unreadable via encryption, truncation, or hashing. stored) Since audit, troubleshooting, and exception logs - Strong cryptography with associated keyhave to be retained, you can prevent disclosure of management processes and procedures data in logs by rendering PANs unreadable (or removing them) in logs. Note: It is a relatively trivial effort for a malicious individual to reconstruct original By correlating hashed and truncated versions of a PAN data if they have access to both the given PAN, a malicious individual may easily derive truncated and hashed version of a PAN. the original PAN value. Controls that prevent the Where hashed and truncated versions of correlation of this data will help ensure that the the same PAN are present in an entitys original PAN remains unreadable. environment, additional controls should be in place to ensure that the hashed and Please refer to the PCI DSS and PA-DSS Glossary of truncated versions cannot be correlated Terms, Abbreviations, and Acronyms for definitions to reconstruct the original PAN. of strong cryptography.

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.

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 diskencryption method cannot have: 1) A direct association with the operating system, or 2) Decryption keys that are associated with user accounts.

3.5 Protect any keys used to secure cardholder data against disclosure and misuse: Note: This requirement also applies to keyencrypting 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 keyencrypting 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 keyencrypting 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.

3.5.2 Store cryptographic keys securely in the fewest Cryptographic keys must be stored securely, usually possible locations and forms. encrypted with key-encrypting keys, and stored in very few locations. It is not intended that the keyencrypting 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

3.5.2 Store cryptographic keys securely in the fewest Cryptographic keys must be stored securely, usually possible locations and forms. encrypted with key-encrypting keys, and stored in very few locations. It is not intended that the keyencrypting 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. 3.6 Fully document and implement all keymanagement 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.

3.6.1 Generation of strong cryptographic keys

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." 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.2 Secure cryptographic key distribution

3.6.3 Secure cryptographic key storage

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.

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.

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.7 Prevention of unauthorized substitution of cryptographic keys.

The encryption solution should not allow for or accept substitution of keys coming from unauthorized sources or unexpected processes. This process will ensure individuals that act as key custodians commit to the key- custodian role and understand the responsibilities.

3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.

Requireme

ts of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic Ns using end-user messaging technologies, such as e-mail and instant messaging.

nitions of strong cryptography and other PCI DSS terms.

companies.

Testing Procedure

3.1 Obtain and examine the policies, procedures and processes for data retention and disposal, and perform the following:

3.1.1.a Verify that policies and procedures are implemented and include legal, regulatory, and business requirements for data retention, including specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).

3.1.1.b Verify that policies and procedures include provisions for secure disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data.

3.1.1.c Verify that policies and procedures include coverage for all storage of cardholder data. 3.1.1.d Verify that policies and procedures include at least one of the following: - A programmatic process (automatic or manual) to remove, at least quarterly, stored cardholder data that exceeds requirements defined in the data retention policy - Requirements for a review, conducted at least quarterly, to verify that stored cardholder data does not exceed requirements defined in the data retention policy.

3.1.1.e For a sample of system components that store cardholder data, verify that the data stored does not exceed the requirements defined in the data retention policy.

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 all other entities, if sensitive authentication data is received and deleted, obtain and review the processes for securely deleting the data to verify that the data is unrecoverable.

3.2.c For each item of sensitive authentication data below, perform the following steps:

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

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

3.3 Obtain and examine written policies and examine displays of PAN (for example, on screen, on paper receipts) to verify that primary account numbers (PANs) are masked when displaying cardholder data, except for those with a legitimate business need to see full PAN.

3.4.a Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable). 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.

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 Verify that cardholder data on removable media is encrypted wherever stored. Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method. 3.5 Verify processes to protect keys used for encryption of cardholder data against disclosure and misuse by performing the following:

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 system configuration files to verify that keys are stored in encrypted format and that key-encrypting keys are stored separately from data-encrypting keys.

3.5.2.b Identify key storage locations to verify that keys are stored in the fewest possible locations and forms.

3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data.

3.6.b For service providers only: If the service provider shares keys with their customers for transmission or storage of cardholder data, verify that the service provider provides documentation to customers that 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.c Examine the key-management procedures and perform the following: 3.6.1 Verify that key-management procedures are implemented to require the generation of strong keys.

3.6.2 Verify that key-management procedures are implemented to require secure key distribution.

3.6.3 Verify that key-management procedures are implemented to require secure key storage.

3.6.4 Verify that key-management procedures are implemented to require periodic key changes at the end of the defined cryptoperiod.

3.6.5.a Verify that key-management procedures are implemented to require the retirement of keys when the integrity of the key has been weakened.

3.6.5.b Verify that the key-management procedures are implemented to require the replacement of known or suspected compromised keys.

3.6.5.c If retired or replaced cryptographic keys are retained, verify that these keys are not used for encryption operations.

3.6.6 Verify that manual clear-text key-management procedures require split knowledge and dual control of keys.

3.6.7 Verify that key-management procedures are implemented to require the prevention of unauthorized substitution of keys.

3.6.8 Verify that key-management procedures are implemented to require key custodians to acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.

Requirement 3: Protect stored cardholder data

ns access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of pro

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

C-VT

Identify the documented policies and procedures that: i. Define the legal, regulatory, and business requirements for data retention responsible personnel interviewed who confirm: i. The legal, regulatory, and business requirements that retention requirements are based on ii. That the documented policies and procedures for data retention are implemented Identify the documented policies and procedures which define processes for secure disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data.

Describe how the documented policies and procedures were verified to include coverage for all storage of cardholder data. Identify the documented policies and procedures that: i. Define processes for ensuring that stored cardholder data does not exceed requirements defined in the data retention policy ii. Require that the processes be performed at least quarterly for a review, or a combination of both).

1 1

Identify the sample of system components that store cardholder data. does not exceed the requirements of data retention and disposal policy. Identify whether the assessed entity is an issuer or supports issuing services. If the assessed entity is an issuer or supports issuing services: i. Identify and describe the business justification for storing sensitive authentication data. ii. Identify the responsible personnel interviewed who confirm the business justification. iii. Describe how the data was observed to be secured.

For all instances where sensitive authentication data is received and deleted: i. Identify the document defining the processes for securely deleting sensitive authentication data. ii. Describe how the processes for securely deleting the data were verified to render the data unrecoverable.

Identify the sample of system components observed. For each sampled system component, identify the observed data sources, including: i. Incoming transaction data ii. All logs (for example, transaction, history, debugging, error) iii. History files iv. Trace files v. Several database schemas vi. Database contents vii. Any other data sources in scope For each sampled system component and data source, describe how observation of the data sources confirms that full track data is not stored under any circumstance.

Identify the sample of system components observed. i. Incoming transaction data ii. All logs (for example, transaction, history, debugging, error) iii. History files iv. Trace files v. Several database schemas vi. Database contents vii. Any other data sources in scope the data sources confirms that card verification codes or values (CVV2, CVC2, CID, CAV2) are not stored under any circumstance.

Identify the sample of system components observed. i. Incoming transaction data ii. All logs (for example, transaction, history, debugging, error) iii. History files iv. Trace files v. Several database schemas vi. Database contents vii. Any other data sources in scope the data sources confirms that PINs or encrypted PIN blocks are not stored under any circumstance.

Identify all instances where primary account numbers (PAN) is displayed. i. Requires PAN is masked when displayed, except for those with a legitimate business need to see full PAN. ii. Identifies those with a legitimate business need to see full PAN masked, except where there is a legitimate business need to view the full PAN.

Identify all instances where PAN is stored (including system components, portable digital media, backup media, and in logs). i. Identify the documents describing the methods for protecting the PAN. ii. Briefly describe the implemented methodsincluding the vendor, type of system/process, and the encryption algorithms (if applicable)used to protect the PAN. iii. Describe how the implemented methods render the PAN unreadable using any of the following defined methods: o One-way hashes based on strong cryptography o Truncation o Index tokens and pads, with the pads being securely stored o Strong cryptography, with associated key-management processes and procedures

Identify the sample of data repositories observed.

how the observed data confirms PAN is rendered unreadable. Identify the sample of removable media observed. unreadable. Identify the sample of audit logs observed. unreadable or removed.
5 5

i. Describe the observed disk encryption mechanisms in use. ii. For each disk encryption mechanism in use, describe how the disk encryption mechanism was observed to be separate from the native operating systems mechanism (that is, logical access to the encrypted file system is managed independently of the native operating system access controls)

If disk encryption is used, describe how cryptographic keys were observed to be stored securely. If disk encryption is used, describe how cardholder data on removable media was observed to be encrypted wherever stored.

Identify observed user access lists for cryptographic key storage. confirm that access to keys is restricted to the fewest number of custodians necessary. Describe how system configuration files were observed to confirm that: i. Keysarestoredinencryptedform. ii. Key-encrypting keys are stored separately from data encrypting keys.

Identify all locations where keys are stored. possible locations and forms. Identify the documents defining key-management procedures for keys used for encryption of cardholder data.

If the entity being assessed is a service provider: transmission or storage of cardholder data. i. Identify the document providing customers guidance on how to securely transmit, store, and update customers keys in accordance with Requirements 3.6.1 through 3.6.8 ii. Describe how the document was observed to be provided to customers.

5 Identify the document that defines procedures for the generation of strong keys. implemented. 5

Identify the document that defines procedures for secure key distribution. implemented. Identify the document that defines procedures for secure key storage. implemented.

Identify the document that defines: i. Key cryptoperiod(s) ii. The procedures for periodic key changes at the end of the defined cryptoperiod(s) cryptoperiod(s) were observed to be implemented.

Identify the document that defines procedures for the retirement of keys when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear- text key). been weakened were observed to be implemented. Identify the document that defines procedures for the replacement of known or suspected compromised keys. keys were observed to be implemented. Identify whether retired or replaced cryptographic keys are retained. If retired or replaced cryptographic keys are retained: i. Identifythedocumentwhichrequiresthatthesekeys: o Are securely archived o Are not used for encryption operations ii. Describehowthekeyswereobservedtobe: o Securely archived o Not used for encryption operations dentify whether manual clear-text cryptographic key management operations are used. If manual clear-text cryptographic key management operations are used: Identify the document that defines procedures requiring: o Split knowledge of keys o Dual control of keys Describe how the following procedures were observed to be implemented for manual clear-text cryptographic key operations: o Split knowledge of keys o Dual control of keys

Identify the document that defines procedures for prevention of unauthorized substitution of keys. Describe how the procedures for the prevention of unauthorized substitution of keys were observed to be implemented. Identify the document that defines procedures for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.

their key-custodian responsibilities.

137

er effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk

Select In Place ? (Y)es (N)o (C)ompensating control

Y

Severity

Proofs / Documentation links

Stage of implementation

1 1

N N

1 1

1 1

N N

5 5

37

Y N C

135

. For example, methods for minimizing risk include not storing cardholder data unless absolutely

Remediation plan

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

Major observations from the 2011 Verizon PCI Compliance Report: Compliance with Requirement 4 increased from 63 percent to 72 percent. 83% of business comply with 4.2 Many businesses have segmented their wireless networks and no longer allow any PCI- regulated traffic containing sensitive cardholder dat

PCI DSS Requirement

NEW - Guidance

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. Examples of open, public networks that are in scope of the PCI DSS include but are not limited to: - The Internet - Wireless technologies, - Global System for Mobile communications (GSM) - General Packet Radio Service (GPRS).

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. For example, Secure Sockets Layer (SSL) encrypts web pages and the data entered into them. When using SSL secured websites, ensure https is part of the URL. Note that some protocol implementations (such as SSL version 2.0 and SSH version 1.0) have documented vulnerabilities, such as buffer overflows, 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 configurations and versions to prevent an insecure connection being used.

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 should be purchased or other compensating controls E-mail, instant messaging, and chat can be easily

4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant intercepted by packet-sniffing during delivery messaging, chat, etc.). traversal across internal and public networks. Do not utilize these messaging tools to send PAN unless they provide strong encryption.

messaging, chat, etc.).

etworks

ssed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targe

d traffic containing sensitive cardholder data to flow over the airwaves.

Testing Procedure

4.1 Verify the use of security protocols wherever cardholder data is transmitted or received over open, public networks. Verify that strong cryptography is used during data transmission, as follows:

4.1.a Select a sample of transactions as they are received and observe transactions as they occur to verify that cardholder data is encrypted during transit.

4.1.b Verify that only trusted keys and/or certificates are accepted.

4.1.c Verify that the protocol is implemented to use only secure configurations, and does not support insecure versions or configurations.

4.1.d Verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.) 4.1.e For SSL/TLS implementations: - Verify that HTTPS appears as a part of the browser Universal Record Locator (URL). - Verify that no cardholder data is required when HTTPS does not appear in the URL. 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.

4.2.a Verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

4.2.b Verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies.

y encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to ca

Vaidation Instructions for QSA/ISA (For In-Place Requirements)

Priority

C-VT

Identify all instances where cardholder data is transmitted or received over open, public networks. i. Describetheobservedsecurityprotocolsinuse. ii. Describe how configurations were observed to use strong cryptography.

Identify the number and types of transactions sampled. encrypted during transit For all instances where cardholder data is transmitted or received over open, public networks: i. Describe the mechanisms used to ensure that only trusted keys and/or certificates are ii. Describe how the mechanisms were observed to accept only trusted keys and/or certificates.

For all instances where cardholder data is transmitted or received over open, public networks: i. Describe how the observed protocol configuration and implementation confirms that: o The security protocols are implemented to use only secure configurations. o The protocol implementation does not support insecure versions or configurations. For each encryption methodology in use: i. Identify vendor recommendations/ best practices for encryption strength. ii. Identify the encryption strength observed to be implemented. For all instances where SSL/TLS is used to encrypt cardholder data over open, public networks: i. Describe how observed configurations and processes confirm that: HTTPS appears as a part of the browser URL. There is no cardholder data required when HTTPS does not appear in the URL. Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. i. Identify the industry best practices used to implement: o Strong encryption for authentication o Strong encryption for transmission ii. Describe how observed wireless configurations and processes confirm that industry best practices are implemented for: o Strong encryption for authentication o Strong encryption for transmission

2 identified instance: i. Describe the method used for securing PAN or rendering it unreadable for each enduser messaging technology used. ii. Describe how the method was observed to be implemented whenever PAN is sent via these technologies.

Identify the policy document which states that unprotected PANs must not be sent via end-user messaging technologies.

18

gain privileged access to cardholder data environments.

Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet.

Severity

Proofs / Documentation links

Stage of implementation

Y N C

18

Remediation plan

Estimated date for completion

Comments

Owner

Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters

Requi

PCI DSS Requirement

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

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.2 Ensure that all anti-virus mechanisms are current, actively running, and generating audit logs.

The best anti-virus software is limited in effectiveness if it does not have current anti- virus signatures or if it isn't active in the network or on an individual's computer. Audit logs provide the ability to monitor virus activity and anti-virus reactions. Thus, it is imperative that anti-virus software be configured to generate audit logs and that these logs be managed in accordance with Requirement 10.

Requirement 5: Use and r

uding viruses, worms, and Trojansenters the network during many business approved activities including employee e-mail and use of the Internet, mob

Major Observations from the 2011 Verizon PCI Compliance Report: Requirement 5 (Use and regularly update anti-virus software or programs) dropped from 70 percent last year to 64 p

Testing Procedure

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.

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.2 Verify that all anti-virus software is current, actively running, and generating logs by performing the following:

5.2.a Obtain and examine the policy and verify that it requires updating of anti-virus software and definitions. 5.2.b Verify that the master installation of the software is enabled for automatic updates and periodic scans.

5.2.c For a sample of system components including all operating system types commonly affected by malicious software, verify that automatic updates and periodic scans are enabled.

5.2.d For a sample of system components, verify that anti-virus software log generation is enabled and that such logs are retained in accordance with PCI DSS Requirement 10.7.

Requirement 5: Use and regularly update anti-virus software or programs

tivities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities.

from the 2011 Verizon PCI Compliance Report: oftware or programs) dropped from 70 percent last year to 64 percent this year.

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

A B C-VT

Identify the sample of system components observed (include all operating system types commonly affected by malicious software). to be deployed.

Identify the sample of system components observed. observed to: i. Detect all known types of malicious software. ii. Remove all known types of malicious software. iii. Protect against all known types of malicious software.

Identify the policy document that requires updating of anti-virus software and definitions. For i. ii. iii. iv. each master installation, describe how observed configurations and processes confirm that: Anti-virus software is configured for automatic updates. Anti-virus software is configured for periodic scans. Automatic updates are performed. Periodic scans are performed. Identify the sample of system components observed (include all operating system types commonly affected by malicious software). processes confirm that: i. Anti-virus software is configured for automatic updates. ii. Anti-virus software is configured for periodic scans. iii. Automatic updates are performed. iv. Periodic scans are performed. Identify the sample of system components observed For each of these samples: Describe how anti-vuris software log generation was observed to be enabled Describe how antivirus logs were observed to be retained in accordance with PCI-DSS 10.7. Audit logs are available for at least one year Processes are in place to immediately restore at least the last three months'slogs for analysis.

1 1

1 1

14

0 0

of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving m

Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet.
N

Severity

Proofs / Documentation links

Stage of implementation

N N

2 2

Y N C

14

to protect systems from current and evolving malicious software threats.

Remediation plan

Estimated date for completion

Comments

Owner

Unscrupulous individuals use security vulnerabilities to gain privileged access to systems.

Note: Appropriate software patches are tho

Requirement 6 (Develop Patching itself is still an issue, as only

PCI DSS Requirement

NEW - Guidance

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

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.

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.

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.

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

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 of custom code prior to release to production or customers in order to identify any potential coding vulnerability. Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Web applications are also subject to additional controls, if they are public facing, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

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 Without proper change controls, security features for all changes to system components. The processes could be inadvertently or deliberately omitted or must include the following: rendered inoperable, processing irregularities could occur, or malicious code could be introduced. 6.4.1 Separate development/test and production environments 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. 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.4 Removal of test data and accounts before production systems become active

6.4.5 Change control procedures for the implementation of security patches and software modifications. Procedures 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. Likewise, a change may negatively affect security functionality of a system necessitating the change to be backed out.

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. Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by the organization.

6.4.5.2 Documented change approval by authorized parties.

6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system.

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.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 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following: Note: The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

The application layer is high-risk and may be targeted by both internal and external threats. Without proper security, cardholder data and other confidential company information can be exposed, resulting in harm to a company, its customers, and its reputation. As with all PCI DSS requirements, Requirements 6.5.1 through 6.5.5 and 6.5.7 through 6.5.9 are the minimum controls that should be in place. This list is composed of the most common, accepted secure coding practices at the time that this version of the PCI DSS was published. As industry accepted secure coding practices change, organizational coding practices should likewise be updated to match. The examples of secure coding resources provided (SANS, CERT, and OWASP) are suggested sources of reference and have been included for guidance only. An organization should incorporate the relevant secure coding practices as applicable to the particular technology in their environment.

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 commerceenabled 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.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. 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.4 Insecure communications

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." 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. 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.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. 6.5.7 Cross-site scripting (XSS)

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

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

Requirement 6: Dev

bilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendorprovided security patches, which must be installed by the en

ote: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with

Major observations from the 2011 Verizon PCI Compliance Report: Requirement 6 (Develop and maintain secure systems and applications) is up from 48 percent overall compliance to 53 percent. Patching itself is still an issue, as only 74 percent of businesses were able to make certain that all systems were properly patched at the time of the

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.

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: 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 Obtain and review policies to confirm that all custom application code changes must be reviewed (using either manual or automated processes) as follows: - Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. - Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5). - Appropriate corrections are implemented prior to release. - Code review results are reviewed and approved by management prior to release.

6.3.2.b Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.2.a, above.

6.4 From an examination of change control processes, interviews with system and network administrators, and examination of relevant data (network configuration documentation, production and test data, etc.), verify the following:

6.4.1 The development/test environments are separate from the production environment, with access control in place to enforce the separation.

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 Production data (live PANs) are not used for testing or development.

6.4.4 Test data and accounts are removed before a production system becomes active.

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: 6.4.5.1 Verify that documentation of impact is included in the change control documentation for each sampled change.

6.4.5.2 Verify that documented approval by authorized parties is present for each sampled change.

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.

6.4.5.4 Verify that back-out procedures are prepared for each sampled change.

6.5.a Obtain and review software development processes. Verify that processes require training in secure coding techniques for developers, based on industry best practices and guidance.

6.5.b Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques.

6.5.c. Verify that processes are in place to ensure that applications are not vulnerable to, at a minimum, the following:

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

6.5.2 Buffer overflow (Validate buffer boundaries and truncate input strings.)

6.5.3 Insecure cryptographic storage (Prevent cryptographic flaws)

6.5.4 Insecure communications (Properly encrypt all authenticated and sensitive communications)

6.5.5 Improper error handling (Do not leak information via error messages)

6.5.6 All High vulnerabilities as identified in PCI DSS Requirement 6.2.

6.5.7 Cross-site scripting (XSS) (Validate all parameters before inclusion, utilize context-sensitive escaping, etc.)

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

6.5.9 Cross-site request forgery (CSRF). (Do not reply on authorization credentials and tokens automatically submitted by browsers.)

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 thirdparty company or an internal organization, as long as the reviewers specialize in application security and can demonstrate independence from the development team.

Requirement 6: Develop and maintain secure systems and applications

orprovided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released,

d sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabi

n PCI Compliance Report: is up from 48 percent overall compliance to 53 percent. rtain that all systems were properly patched at the time of the IROC.

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

A B C-VT

Identify the sample of system components observed. the sample: i. Identify the vendor security patch list reviewed. ii. Describe how current vendor security patches for the system component and/or related software were observed to be installed. Identify the document requiring that all critical new security patches are installed within one month. 3

Identify the responsible personnel interviewed who confirm: i. That processes are in place to identify new security vulnerabilities ii. Whether a risk ranking is assigned to such vulnerabilities 3 for assigning a risk ranking, including how critical, highest risk vulnerabilities are ranked as High* (Note: The ranking of vulnerabilities is considered a best practice until June 30, 2012, after which it

Identify the document requiring that outside sources are used to identify new security vulnerabilities.

vulnerabilities.

Identify the document that defines software development processes based on industry standards and/or best practice.

Identify the documented software development processes that include information security throughout the software development life cycle. Identify the documented software development processes that specify how software applications are developed in accordance with PCI DSS.

3 3 3

Identify the document requiring removal of custom application accounts, user IDs and/or passwords before the system goes into production or is released to customers. accounts, user IDs and/or passwords are removed before the system goes into production or is released to customers. 3

Identify the policy document requiring that all custom application code changes must be reviewed. changes (for example, manual or automated, or a combination of both). and confirm the documented processes require the following: i. All custom application code changes are reviewed. ii. Code changes are reviewed by individuals other than the original author. iii. Code changes are reviewed by individuals who are knowledgeable in code review techniques. iv. Code changes are reviewed by individuals who are knowledgeable in secure coding practices. v. Code reviews ensure secure coding guidelines have been followed. vi. Any corrections identified during the code review are implemented prior to release. vii. Code review results are reviewed by management prior to release. viii. Code review results are approved by management prior to release.

Identify the sample of custom application changes. processes were observed to be implemented: i. All custom application code changes are reviewed. ii. Code changes are reviewed by individuals other than the original author. iii. Code changes are reviewed by individuals who are knowledgeable in code review techniques. iv. Code changes are reviewed by individuals who are knowledgeable in secure coding practices. v. Code reviews ensure secure coding guidelines have been followed. vi. Any corrections identified during the code review are implemented prior to release. vii. Code-review results are reviewed by management prior to release. viii. Code review results are approved by management prior to release.

Identify the document that defines and/or illustrates: How the development/test environment is separated from the production environment Access control to enforce separation Identifify the system and /or network asministrators interviewed to confirm the above. Describe how the development/test environmentwas observed separated from the production environement and how the access controls were observed to enforced separation

Identify the document that defines separation of duties between personnel assigned to the development/test environment and those assigned to the production environment.

assigned to the production environment who were interviewed to confirm that separation of duties is in place.

Identify the document that defines processes for ensuring: i. Live PANs are not used for testing. ii. Live PANs are not used for development. confirm: i. Live PANs are not used for testing. ii. Live PANs are not used for development. i. Live PANs are not used for testing. ii. Live PANs are not used for development. Identify the documentthat defines processes for: Removing test data and test account before a production system becomes active Identify the development/test and/or production personnel interviewed to confirm the above. Describe the processes obervsedto be implementedfor the above.

Identify the document that defines change control procedures for implementation of security patches and software modifications. i. Documentation of impact ii. Documented approval by authorized parties iii. Testing of functionality to ensure the change does not adversely impact the security of the system iv. Testing of all custom code updates for compliance with PCI DSS Requirement 6.5 (to address the vulnerabilities identified in 6.5.1 6.5.9) v. Back-out procedures

6 Identify the sample of: i. System components ii. Recent changes/security patches is included in the change control documentation. Identify the sample of: i. System components ii. Recent changes/security patches is included in the change control documentation. Identify the sample of: i. System components ii. Recent changes/security patches For each sampled change: i. Describe how details of functionality testing are included in the change control documentation. ii. Describe how the functionality testing performed verifies that the change does not adversely impact the security of the system. Identify the sample of: i. System components ii. Recent custom code changes/updates For each sampled custom code change: i. Describe how details of testing for compliance with PCI DSS Requirement 6.5 (to address the vulnerabilities defined in 6.5.1 6.5.9) are included in the change control documentation. ii. Describe how the testing performed verifies that all updates are compliant with PCI DSS Requirement 6.5 (6.5.1 6.5.9) before being deployed into production. Identify the sample of: i. System components ii. Recent changes/security patches For each sampled change: Describe how details of back-out procedures are included in the change control documentation. Describe how the back-out procedures were observed to be prepared for each change.

Identify the document requiring that developers are trained in secure coding 3

Identify the sample of developers interviewed. secure coding techniques. 3

Identify the document that defines the process for ensuring all applications are not vulnerable to injection flaws, particularly SQL injection. not vulnerable to injection flaws, particularly SQL injection.

Identify the document that defines the process for ensuring all applications are not vulnerable to buffer overflow. not vulnerable to buffer overflow.

Identify the document that defines the process for ensuring all applications are not vulnerable to insecure cryptographic storage. not vulnerable to insecure cryptographic storage. 3

Identify the document that defines the process for ensuring all applications are not vulnerable to insecure communications. not vulnerable to insecure communications. 3

Identify the document that defines the process for ensuring all applications are not vulnerable to improper error handling. Describe the processes observed to be in place for ensuring that all applications are not vulnerable to improper error handling.

Identify whether a process is in place to ensure all applications are not vulnerable to High vulnerabilities as identified in PCI DSS Requirement 6.2. If there is a process in place: i. Identify the document that defines the process for ensuring that all applications are not vulnerable to High vulnerabilities as identified in PCI DSS Requirement 6.2. ii. Describe the processes observed to be in place for ensuring that applications are not vulnerable to all High vulnerabilities, as identified in PCI DSS Requirement 6.2. Identify the document that defines the process for ensuring web applications and application interfaces are not vulnerable to cross-site scripting (XSS).

and application interfaces are not vulnerable to cross-site scripting (XSS).

Identify the document that defines the process for ensuring web applications and application interfaces are not vulnerable to improper access control. Describe the processes observed to be in place for ensuring that web applications and application interfaces are not vulnerable to improper access control.

Identify the document that defines the process for ensuring web applications and application interfaces are not vulnerable to cross-site request forgery. Describe the processes observed to be in place for ensuring that web applications and application interfaces are not vulnerable to cross-site request forgery.

For each public-facing web application: i. Identify which of the two methods are implemented (web application vulnerability security assessments, web application firewalls, or both). If application vulnerability security assessments are performed: i. Describe the tools and/or methods used (manual or automated, or a combination of both). ii. Describe how it was observed that assessments are performed: o At least annually o After any changes iii. Identify the organization(s) performing the assessments. iv. Identify the responsible personnel interviewed, and describe how those reviewing the applications were confirmed to: o Specialize in application security o Demonstrate independence from the development team v. Describe the observed process which confirm that: o All identified vulnerabilities are corrected. o Applications are re-evaluated after the corrections are applied. If a web-application firewall(s) is used: i. Describe how the web-application firewall was observed to be placed in front of all publicfacing web applications. ii. Describe the observed web-application firewall configurations for: o Detecting web-based attacks o Preventing web-based attacks iii. Describe how the web-application firewall was observed to: o Detect web-based attacks o Prevent web-based attacks 129 0 0 2

ns

e the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals

lications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet.

Severity

Proofs / Documentation links

Stage of implementation

1 1 1 1

N N N N

3 3 3 3

36

Y N C

129

der data by malicious individuals and malicious software.

techniques.

Remediation plan

Estimated date for completion

Comments

Owner

The pe Most organizations fail to meet it

PCI DSS Requirement

NEW - Guidance

7.1 Limit 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 strong business reason for the access helps your organization prevent mishandling of cardholder data through inexperience or malice. When access rights are granted only to the least amount of data and privileges needed to perform a job, this is a called least privilege and need to know, and when privileges are assigned to individuals based on job classification and function, this is called role-based access control or RBAC. Role based access control enforcement is not limited to an application layer or any specific authorization solution. For example, technology including but not limited to directory services such as Active Directory or LDAP, Access Control Lists (ACLs), and TACACS are viable solutions as long as they are appropriately configured to enforce the principles of least privilege and need to know. Organizations should create a clear policy and processes for data access control based on need to know and using role-based access control, to define how and to whom access is granted, including appropriate management authorization processes.

Organizations should create a clear policy and processes for data access control based on need to know and using role-based access control, to define how and to whom access is granted, including appropriate management authorization processes. 7.1.1 Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities 7.1.2 Assignment of privileges is based on individual personnels job classification and function 7.1.3 Requirement for a documented approval by authorized parties specifying required privileges. 7.1.4 Implementation of an automated access control system 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.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.

Requirement 7: Rest

To ensure critical data can only be accessed by authorized personnel, s

Need to know is when access rights a

Major Observations 2011 Verizon PCI Compliance Report: The percentage of organizations fully meeting Requirement 7 at time of IROC was 75 percent, an eight percent incre Organizations met an average of 87 percent of tests in Requirement 7 at time of IROCthe highest among Most organizations fail to meet it in full due to lack of a documented and enforced access control policy as well as fail to automate the process When implementing access controls, several organizations are still focusing too much on the netw

Testing Procedure

7.1 Obtain and examine written policy for data control, and verify that the policy incorporates the following:

7.1.1 Confirm that access rights for privileged user IDs are restricted to least privileges necessary to perform job responsibilities. 7.1.2 Confirm that privileges are assigned to individuals based on job classification and function (also called role-based access control or RBAC). 7.1.3 Confirm that documented approval by authorized parties is required (in writing or electronically) for all access, and that it must specify required privileges. 7.1.4 Confirm that access controls are implemented via an automated access control system. 7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows:

7.2.1 Confirm that access control systems are in place on all system components.

7.2.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.

7.2.3 Confirm that the access control systems have a default deny-all setting.

Requirement 7: Restrict access to cardholder data by business need to know

Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.

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

bservations 2011 Verizon PCI Compliance Report: ment 7 at time of IROC was 75 percent, an eight percent increase over the 2010 report results. of tests in Requirement 7 at time of IROCthe highest among all twelve key controls. d access control policy as well as fail to automate the process of identifying and maintaining a list of authorized personnel. s, several organizations are still focusing too much on the network perimeter.

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

Identify the data control policy document which requires that access rights for privileged user IDs are restricted to the least privileges necessary to perform job responsibilities. Identify the data control policy document requiring that privileges are assigned to individuals based on job classification and function. Identify the data control policy document that requires the following: i. Documented approval by authorized parties for all access. ii. That documented approval must specify the required privileges. Identify the data control policy document requiring that access controls are implemented using an automated access control system

4 4

Describe the access control systems in use. components. For each access control system in use: i. Identify the documents that describe: o Job classifications and functions o The associated privilege assignments ii. Describe how the access control systems were observed to enforce privileges assigned to individuals based on job classification and function. For each access control system in use: i. Describe how the access control system was observed to have a default deny-all setting.

36

o know

on need to know and according to job responsibilities.

eded to perform a job.

C-VT

"Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet."

Severity

Proofs / Documentation links

Stage of implementation

1 1

N N

4 4

Y N C

36

Remediation plan

Estimated date for completion

Comments

Owner

Validation

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all account

Major Observations from the 2011 Verizon PCI Compliance report: More than half of organizations failed to meet Requirement 8 at time of the IROC. Of all the compliance validation tests for Requirement 8, organizations met an average of 77 percent at the time of IROC. Sub-requirement 8.3 (Ensure proper user authentication and password management for non-consumer users and administrators on all sys requirements. Sub-requirements 8.4 (Render all passwords unreadable during transmission and storage on all system components using strong cryptogra Most organizations do communicate their password policies and standards internally, but still experience difficulty enforcing them across a

PCI DSS Requirement

NEW - Guidance

8.1 Assign all users a unique ID before allowing them By ensuring each user is uniquely identifiedinstead to access system components or cardholder data. 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.2 In addition to assigning a unique ID, employ 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 items, when used in addition to unique IDs, help protect users unique IDs from being compromised (since the one attempting the compromise needs to know both the unique ID and the password or other authentication item). A digital certificate is a valid option as a form of the authentication type something you have as long as it is unique.

8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. (For example, remote authentication and dialin service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication.) Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

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 accessnetworknetwork and applications transmit the Many to that devices would not required by PCI 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.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

8.5 Ensure proper user identification and authentication management for nonconsumer users and administrators on all system components as follows:

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 user identification and authentication management.

8.5.1 Control addition, deletion, and modification To ensure users added to your systems are all valid of user IDs, credentials, and other identifier objects. 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.

8.5.2 Verify user identity before performing password resets.

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.

8.5.3 Set passwords for first-time use and resets to If the same password is used for every new user set a unique value for each user and change up, an internal user, former employee, or malicious immediately after the first use. individual may know or easily discover this password, and use it to gain access to accounts.

8.5.4 Immediately revoke access for any terminated users.

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. Existence of inactive accounts allows an unauthorized user exploit the unused account to potentially access cardholder data.

8.5.5 Remove/disable inactive user accounts at least every 90 days.

8.5.6 Enable accounts used by vendors for remote access only during the time period needed. Monitor vendor remote access accounts when in use.

Allowing vendors (like POS 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-ready external entry point into your network. Monitoring of vendor access to the cardholder data environment applies in the same way as it does for other users, such as organizational personnel. This includes monitoring and logging of activities as required by PCI DSS Requirements 10.1 and 10.2, and verifying that usage of vendor remote accounts is in accordance with the policy as defined in Requirements 12.3.8 and 12.3.9.

8.5.7 Communicate authentication procedures and Communicating password/authentication policies to all users who have access to cardholder procedures to all users helps those users understand data. and abide by the policies, and to be alert for any malicious individuals who may attempt to exploit their passwords to gain access to cardholder data (for example, by calling an employee and asking for their password so the caller can troubleshoot a problem). 8.5.8 Do not use group, shared, or generic accounts and passwords, or other authentication methods. If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to assign accountability for, or to have 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. This requirement for unique IDs and complex passwords is often met within administrative functions by using, for example, sudo or SSH such that the administrator initially logs on with their own unique ID and password, and then connects to the administrator account via sudo or SSH. Often direct root logins are disabled to prevent use of this shared administrative account. This way, individual accountability and audit trails are maintained. However, even with use of tools such as sudo and SSH, the actual administrator IDs and passwords should also meet PCI DSS requirements (if such accounts are not disabled) to prevent them from being misused.

should also meet PCI DSS requirements (if such accounts are not disabled) to prevent them from being misused.

8.5.9 Change user passwords at least every 90 days. 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.

8.5.10 Require a minimum password length of at least seven characters.

8.5.11 Use passwords containing both numeric and alphabetic characters.

8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.

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

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

8.5.14 Set the lockout duration to a minimum of 30 If an account is locked out due to someone minutes or until administrator enables the user ID. 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.5.15 If a session has been idle for more than 15 When users walk away from an open machine with minutes, require the user to re-authenticate to re- access to critical network or cardholder data, that activate the terminal or session. machine may be used by others in the users absence, resulting in unauthorized account access and/or account misuse.

8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users. Restrict user direct access or queries to databases to database administrators.

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 can have direct access to the database for their administrative duties).

stored procedures), rather than via direct access to the database by end users (except for DBAs, who can have direct access to the database for their administrative duties).

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

administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. However, Requirements 8

cent at the time of IROC. nsumer users and administrators on all system components) and 8.5.7 (Communicate password procedures and policies to all users who have access to

system components using strong cryptography) and 8.5.10 (Require a minimum password length of at least seven characters) were the least compliant a xperience difficulty enforcing them across all computing devices.

Testing Procedure

8.1 Verify that all users are assigned a unique ID for access to system components or cardholder data.

8.2 To verify that users are authenticated using unique ID and additional authentication (for example, a password) for access to the cardholder data environment, perform the following: - Obtain and 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.3 To verify that two-factor authentication is implemented for all remote network access, observe an employee (for example, an administrator) connecting remotely to the network and verify that two of the three authentication methods are used.

8.4.a For a sample of system components, examine password files to verify that passwords are unreadable during transmission and storage.

8.4.b For service providers only, observe password files to verify that customer passwords are encrypted.

8.5 Review procedures and interview personnel to verify that procedures are implemented for user identification and authentication management, by performing the following:

8.5.1 Select a sample of user IDs, including both administrators and general users. Verify that each user is authorized to use the system according to policy by performing the following: - Obtain and examine an authorization form for each ID. - Verify that the sampled user IDs are implemented in accordance with the authorization form (including with privileges as specified and all signatures obtained), by tracing information from the authorization form to the system.

8.5.2 Examine password/authentication procedures and observe security personnel to verify that, if a user requests a password reset by phone, e-mail, web, or other nonface-to-face method, the users identity is verified before the password is reset.

8.5.3 Examine password procedures and observe security personnel to verify that firsttime passwords for new users, and reset passwords for existing users, are set to a unique value for each user and changed after first use.

8.5.4 Select a sample of users terminated in the past six months, and review current user access lists to verify that their IDs have been deactivated or removed.

8.5.5 Verify that inactive accounts over 90 days old are either removed or disabled.

8.5.6.a Verify that any accounts used by vendors to access, support and maintain system components are disabled, and enabled only when needed by the vendor.

8.5.6.b Verify that vendor remote access accounts are monitored while being used.

8.5.7 Interview the users from a sample of user IDs, to verify that they are familiar with authentication procedures and policies.

8.5.8.a For a sample of system components, examine user ID lists to verify the following: - Generic user IDs and accounts 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.8.b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited.

8.5.8.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed, even if requested.

8.5.9.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.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that nonconsumer users are given guidance as to when, and under what circumstances, passwords must change.

8.5.10.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least seven characters long.

8.5.10.b For service providers only, review internal processes and customer/user documentation to verify that that non-consumer user passwords are required to meet minimum length requirements.

8.5.11.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to contain both numeric and alphabetic characters.

8.5.11.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to contain both numeric and alphabetic characters.

8.5.12.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.5.12.b For service providers only, review internal processes and customer/user documentation to verify that new non-consumer user passwords cannot be the same as the previous four passwords.

8.5.13.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.5.13.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user accounts are temporarily locked-out after not more than six invalid access attempts.

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

8.5.15 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.5.16.a Review database and application configuration settings and verify that all users are authenticated prior to access.

8.5.16.b Verify that database and application configuration settings ensure 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.5.16.c Verify that database and application configuration settings restrict user direct access or queries to databases to database administrators.

8.5.16.d Review database applications 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).

aken on critical data and systems are performed by, and can be traced to, known and authorized users.

ccess systems with cardholder data. However, Requirements 8.1, 8.2 and 8.5.8 through 8.5.15 are not intended to apply to user accounts within a point-o

sword procedures and policies to all users who have access to cardholder data) rate among the best implemented compliance test procedures within the

length of at least seven characters) were the least compliant at the time of IROC.

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

A B C-VT

Identify the document requiring that the users are assigned a unique userId before beingallowed to access system components or cardholder data Describe how implemented access control systems were observed to assign unique Ids for access to system components and cardholder data Descibe how IDs with access to system components anc cardholder data were observed be unique. Identify the document describing the authentication method(s) used, and confirm that the methods require users to be authenticated using a unique ID and additional authentication for access to the cardholder data environment. 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. For each type of authentication method used and for each type of system component: i. Describe how the authentication method was observed to be used for access to the cardholder data environment. ii. Describe how the authentication method was observed to be functioning consistent with the documented authentication method(s).

Identify the document that requires two-factor authentication for remote access by: i. Employees (users) ii. Administrators iii. Third parties Describe the two-factor authentication technologies implemented for remote access to the network. For each identified technology: Identify the personnel (for example, an administrator) observed connecting remotely to the network. Describe how two-factor authentication was observed to be required for remote access to the network. Identify which two factors are used: Something you know, Something you are, Something you have.

Identify the sample of system components observed. that passwords are unreadable during: i. Transmission ii.Storage For each sampled system component, describe how the observed system configuration settings verify that strong cryptography is used for passwords during: I.Transmission ii. Storage If the entity being assessed is a service provider: Describe how observed customer password files verify that customer passwords are encrypted during: i. Transmission ii. Storage Describe how observed system configuration settings confirm that customer passwords are rendered unreadable using strong cryptography during: i. Transmission ii. Storage

Identify the samples of: Administrator and General userIDs For each sampled administrator user ID, describe how the observed authorization forms andsystem settings confirm that: The adminitrator userId is implemented in accordance with the authorization form and with the privileges specified on this form with all appropriated signatures otained. For each sample general USerID describe how the authorization form and system settings confirm that: The userId is implemented in accordance with the authorization form and with the privileges specified on this form with all appropriated signatures otained.

Describe the non-face-to-face methods used for requesting password resets. For each of these method: Identify therelated documented procedures and confirmthe procedures requires the userId's identity to be verified before the password is reset. Describe how security personnel responsible for resetting passwords were observed to verify user identities beforesetting the passwords.

Identify the documented procedures for issuing first-time passwords for new users, and confirm the procedures require: i. First-time passwords must be set to a unique value for each user. ii. First-time passwords must be changed after the first use. Describe how security personnel responsible for assigning first-time passwords were observed to: i. Set first-time passwords to a unique value for each new user. ii. Set first-time passwords to be changed after first use. confirm the procedures require: Reset passwords must be set to a unique value for each user. ii. Reset passwords must be changed after the first use. Describe how security personnel responsible for resetting passwords were observed to: i. Set reset passwords to a unique value for each existing user. ii. Set reset passwords to be changed access be immediately revoked for any Identify the document requiring that after first use. terminated users. Identify the sample of users terminated in the past six months. For each sampled user, describe how the user account was observed to be deactivated or removed from user access lists.

Identify the document requiringthat inactive user accounts over 90 daysold are either removed or disabled. Describe how user accounts inactive over 90 days old were observed to be disabled or removed.

dentify the document requiring that accounts used by vendors to access, support and maintain system components are: i. Disabled when not being used ii. Enabled only when needed Briefly describe the implemented processes for: i. Disabling vendor accounts when not being used. ii. Enabling vendor accounts only when needed. to the documented processes.

Identify the document requiring that accounts used by vendors are monitored while being used. Describe how vendor accounts were observed to be monitored while being used. Identify the sample of user IDs. For each user ID in the sample, describe how the interviewed users demonstrated that they are familiar with authentication procedures and policies.

Identify the sample of system components observed. For each sampled system component, describe how observed user ID lists verify that: i. Generic user IDs and accounts are disabled or removed. ii. Shared user IDs for system administration activities and other critical functions do not exist. For each sampled system component, identify personnel with administrator IDs who were interviewed, and who confirm that: i. Shared user IDs are not used to administer any system components. ii. Generic user IDs are not used to administer any system components.

Identify the documented policies/procedures which explicitly prohibit: Group and shared password or other authentication methods

Identify the system administrators interviewed who verify that the following are never distributed, even if requested: i. Group passwords or other authentication methods ii. Shared passwords or other authentication methods component: i. Describe the system configuration settings inspected. ii. Identify how often users are required to change their passwords, as observed in the system configuration settings.

If the entity being assessed is a service provider: Identify the customer/user documentation that provide the following guidance to non-consumer users: When to change their passwords and under what circumstances passwords must be changed Describe how the documented guidance was observed Describe how the service provider processesuser passwords were observed to include: periodic password changes, details whenand under which circumstances passwords must be change; component: ii. Identify the required minimum password length observed in the system configuration settings. If the entity being assessed is a service provider: passwords to meet minimum length requirements. meet minimum password-length requirements. component: ii. Identify the types of characters required for passwords, as observed in the system configuration settings. If the entity being assessed is a service provider: passwords to use both numeric and alphabetic characters. contain both numeric and alphabetic characters. component: Identify the number of previously used passwords that cannot be the same as a new password, as observed in the system configuration settings.

If the entity being assessed is a service provider: passwords to not be the same as the previous four passwords. passwords cannot be the same as the previous four passwords.

4 component: ii. Identify the number of invalid logon attempts that result in user accounts being locked out, as observed in the system configuration settings. If the entity being assessed is a service provider: passwords to be temporarily locked out after not more than six invalid access attempts. are temporarily locked out after no more than six invalid access attempts. 4 component: i. Describe the system configuration settings inspected. Identify which of the following was observed to be required once a user account is locked out: The user account remains locked for a minimum of 30 minutes; or The user account remains locked until a system administrator resets the account.

Identify the sample of system components observed. For each sampled system component: i. Describe the system configuration settings which were inspected. ii. Identify to what time (in minutes) that system and/or session idle time-out features are set, as observed in the system configuration settings. iii. Describe how the system and/or session idle time-out features were observed to require the user to re-authenticate to re-activate the terminal or session. Identify all databases containing cardholder data. For each database containing cardholder data: i. Describe how authentication is managed (for example, via application and/or database interfaces). ii. Describe how database and/or application configuration settings were observed to authenticate all users prior to access.

For each database containing cardholder data: i. Describe how the observed database and application configuration settings ensure that only programmatic methods are used for: o All user access to the database o All user queries of the database o All user actions on the database (for example, move, copy, delete) ii. Describe how it was observed that only programmatic methods are used for: o All user access to the database o All user queries of the database o All user actions on the database (for example, move, copy, delete) For each database containing cardholder data, describe how database and application configuration settings were observed to restrict the following to only database administrators: i.User direct access to the database ii.User direct queries to the database For each database containing cardholder data: i. Identify applications with access to the database. ii. Describe the implemented methods for ensuring that application IDs can only be used by the applications, and not by: o Individual users o Other processes iii. Describe how the methods were observed to ensure that application IDs cannot be used by: o Individual users o Other processes

132

0 0

accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such a

est procedures within the main compliance

Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet.

Severity

Proofs / Documentation links

Stage of implementation

33

Y N C

132

facilitate a single transaction (such as cashier accounts).

Remediation plan

Estimated date for completion

Comments

Owner

Sub-requirements 9.3, 9.4 (employee/visito Only about h On average, 84 percent of tests we The most challenging sub-control, at time of

PCI DSS Requirement

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

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,

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.

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 Restrict physical access to publicly accessible network jacks. For example, areas accessible to visitors should not have network ports enabled unless network access is explicitly authorized.

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

9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines.

9.2 Develop procedures to easily distinguish between onsite personnel and visitors, especially in areas where cardholder data is accessible.

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.3 Make sure all visitors are handled as follows:

Visitor controls are important to reduce the ability of unauthorized and malicious persons to gain access to your facilities (and potentially, to cardholder data). Visitor controls are important to ensure visitors only enter areas they are authorized to enter, that they are identifiable as visitors so personnel can monitor their activities, and that their access is restricted to just the duration of their legitimate visit.

9.3.1 Authorized before entering areas where cardholder data is processed or maintained.

9.3.2 Given a physical token (for example, a badge or access device) that expires and that identifies the visitors as not onsite personnel.

9.3.3 Asked to surrender the physical token before leaving the facility or at the date of expiration. 9.4 Use a visitor log to maintain a physical audit trail of visitor activity. 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. A visitor log documenting minimum information on the visitor is easy and inexpensive to maintain and will assist, during a potential data breach investigation, in identifying physical access to a building or room, and potential access to cardholder data. Consider implementing logs at the entry to facilities and especially into zones where cardholder data is present.

authorizing physical access on the log. Retain this log investigation, in identifying physical access to a for a minimum of three months, unless otherwise building or room, and potential access to cardholder restricted by law. data. Consider implementing logs at the entry to facilities and especially into zones where cardholder data is present.

9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the locations security at least annually.

If stored in a non-secured facility, backups that contain cardholder data may easily be lost, stolen, or copied for malicious intent. For secure storage, consider contracting with a commercial data storage company OR, for a smaller entity, using a safedeposit box at a bank.

9.6 Physically secure all 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. 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.7 Maintain strict control over the internal or external distribution of any kind of media, including the following:

9.7.1 Classify media so the sensitivity of the data can It is important that media be identified such that its be determined. classification status can be easily discernable. Media not identified as confidential may not be adequately protected or may be lost or stolen 9.7.2 Send the media by secured courier or other delivery method that can be accurately tracked.

Media may be lost or stolen if sent via a nontrackable 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.8 Ensure management approves any and all media Cardholder data leaving secure areas without a that is moved from a secured area (especially when process approved by management can lead to lost or media is distributed to individuals). stolen data. Without a firm process, media locations are not tracked, nor is there a process for where the data goes or how it is protected. 9.9 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.

9.9.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.10 Destroy media when it is no longer needed for business or legal reasons as follows:

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.10.1 Shred, incinerate, or pulp hardcopy materials so that cardholder data cannot be reconstructed.

9.10.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed.

Major Observations from the 2011 Verizon Compliance Report: ub-requirements 9.3, 9.4 (employee/visitor controls), and 9.6 (secure physical delivery) rate among the best implemented compliance test procedures. Only about half (55 percent) of organizations fully met Requirement 9 at the time of IROC. On average, 84 percent of tests were fully met in Requirement 9 at the time of IROC, a seven percent reduction from our 2010 results. he most challenging sub-control, at time of IROC, is 9.9.1: Properly maintain inventory logs of all media and conduct media inventories at least annually.

Testing Procedure

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

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.

9.1.2 Verify by interviewing network administrators and by observation that network jacks are enabled only when needed by authorized onsite personnel. Alternatively, verify that visitors are escorted at all times in areas with active network jacks.

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.

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.3 Verify that visitor controls are in place as follows:

9.3.1 Observe the use of visitor ID badges to verify that a visitor ID badge does not permit unescorted access to physical areas that store cardholder data.

9.3.2.a Observe people within the facility to verify the use of visitor ID badges, and that visitors are easily distinguishable from onsite personnel.

9.3.2.b Verify that visitor badges expire. 9.3.3 Observe visitors leaving the facility to verify visitors are asked to surrender their ID badge upon departure or expiration. 9.4.a Verify that a visitor log is in use to record physical access to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted.

9.4.b Verify that the log contains the visitors name, the firm represented, and the onsite personnel authorizing physical access, and is retained for at least three months.

9.5.a Observe the storage locations physical security to confirm that backup media storage is secure.

9.5.b Verify that the storage location security is reviewed at least annually.

9.6 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.7 Verify that a policy exists to control distribution of media, and that the policy covers all distributed media including that distributed to individuals.

9.7.1 Verify that all media is classified so the sensitivity of the data can be determined.

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

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

9.9 Obtain and examine the policy for controlling storage and maintenance of all media and verify that the policy requires periodic media inventories.

9.9.1 Obtain and review the media inventory log to verify that periodic media inventories are performed at least annually.

9.10 Obtain and examine the periodic media destruction policy and verify that it covers all media, and confirm the following:

9.10.1.a Verify that hard-copy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed. 9.10.1.b Examine storage containers used for information to be destroyed to verify that the containers are secured. For example, verify that a to-be-shredded container has a lock preventing access to its contents. 9.10.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 (for example, degaussing).

mpliance Report: te among the best implemented compliance test procedures. rement 9 at the time of IROC. OC, a seven percent reduction from our 2010 results. of all media and conduct media inventories at least annually.

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

Identify and briefly describe all computer rooms, data centers and other physical areas with systems in the cardholder data environment. For each area identified: Describe the physical security controls observed. Describe how access was observed to be controlled with badge readers or other devices, including authorized badges and lock and key. Identify the number of randomly selected systems in the cardholder environment for which a system administrator login attempt was observed. Describe how consoles for the randomlys elected systems were observed to be "locked. i. Describe the video cameras and/or access control mechanisms observed to monitor the entry/exit points. ii. Describe how the video cameras and/or access control mechanisms were observed to monitor individual physical access to the sensitive area. Describe how the video cameras and/or access control mechanisms were observed to be protected from: i. Tampering ii. Disabling

Describe how the video cameras and/or access control mechanisms were observed to be monitored. reviewed and correlated with other entries. observed to be stored for at least three months. Identify the network administrator interviewed who confirm that either: Publicly accessible network jacks are enabled when needed by authorized personnel Visitors are excorted at all times in areas with actibe jacks. Describe how the here above processes were observed. 2 2

Describe how physical access was observed to be restricted to: i. Wireless access points ii. Wireless gateways iii. Wireless handheld devices iv. Network/communications hardware v. Telecommunication lines

Identify the documented processes and procedures for assigning badges to onsite personnel, and verify the processes include: i. Granting new badges ii. Changing access requirements iii. Revoking badges for terminated onsite personnel were observed to be implemented, including: i. Granting new badges ii. Changing access requirements iii. Revoking badges for terminated onsite personnel and verify the processes include: i. Granting new badges ii. Changing access requirements iii. Expiration of visitor badges observed to be implemented, including: i. Granting new badges ii. Changing access requirements Identify the document which identifies personnel who are authorized to access the badge system. personnel.

5 badges clearly identify visitors. 5

Describe how the use of visitor badges was observed to verify that the visitor ID badge does not permit unescorted access to physical areas that store cardholder data.

Describe how people within the facility were observed to use visitor ID badges. onsite personnel. Describe how visitor badges were observed to expire. Describe how observed visitors were asked to surrender their ID badge upon departure or expiration. Describe how a visitor log was observed to be in use to record physical access to: The facility Computer rooms and data centers where cardholder data is stored or transmitted

5 5

Describe how the visitor log was observed to contain: i. Visitor name ii. Firm represented iii. Onsite personnel authorizing physical access

Identify all locations where backup media is stored. media is stored securely.

Identify the document that defines the process for reviewing the security of each storage location at least annually. performed at least annually. Identify the documented procedures for protecting cardholder data, and confirm that the procedures include controls for physically securing all media. i. Briefly describe the controls for physically securing the media. ii. Describe how the documented controls were observed to be implemented

5 how the policy covers all distributed media.

Identify the document that defines how media are classified Briefly describe how media is classiffied to determined sensitivity of the data Describe how the classification were observed.

Describe how it was observed that all media sent outside the facility is: i. Logged ii. Authorized by management iii. Sent via secured courier or other delivery method that can be accurately tracked.

Identify the sample of offsite tracking logs for all media. i. Tracking details ii. Proper management authorization Identify the policy document that defines requirements for: i. Controlling storage of all media ii. Controlling maintenance of all media iii. Periodic inventories for all media i. Controlling storage of all media ii. Controlling maintenance of all media iii. Performing periodic inventories for all media

Identify the document that describes the process for conducting media inventories at least annually.

annually. 1 that the policy covers all media. 1

Describe the documented process for destruction of hardcopy materials. materials cannot be reconstructed. Describe how the containers used for storing information to be destroyed were observed to be secured. 1

1 1 1

Describe the documented process for destruction of electronic media, including details of methods used for: i. Secure wiping of media, and/or ii. Physical destruction of media Describe how the observed processes ensure that data is rendered unrecoverable. identify the industry-accepted standards used.

111

11

11

C-VT

Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet.

I n t e r m e d i a r y C o n t r o l
N

Severity

Proofs / Documentation links

1 1

N N

N N

5 5

11

11

29

Y N C

111

Stage of implementation

Remediation plan

Estimated date for completion

Comment s

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 comprom

Major Observations from the 2011 Verizon PCI Compliance Report: Requirement 10 is historically one of the most challenging key controls to meet. 52 percent of organizations fully met Requirement 10 at the time of IROC, representing a 13 percent increase from last years data set. On average, organizations met 70 percent of tests in Requirement 10 at time of IROC, a five percent decrease from 2010. The most challenging sub-control appears to be 10.5.5: Use file-integrity monitoring or change-detection software on logs to ensure that e Other pitfalls towards compliance with Requirement 10 are the failure or inability to invest in a capable automated tool (log aggregator) to

PCI DSS Requirement

NEW - Guidance

10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

It is critical to have a process or system that links user access to system components accessed, and in particular, for those users with administrative privileges. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user. Post-incident forensic teams heavily depend on these logs to initiate the investigation. 10.2 Implement automated audit trails for all system Generating audit trails of suspect activities alerts the components to reconstruct the following events: system administrator, sends data to other monitoring mechanisms (like intrusion detection systems), and provides a history trail for postincident 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. 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. 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, 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. 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. 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. 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.2.2 All actions taken by any individual with root or administrative privileges

10.2.3 Access to all audit trails

10.2.4 Invalid logical access attempts

10.2.5 Use of identification and authentication mechanisms

10.2.6 Initialization of the audit logs

10.2.7 Creation and deletion of system-level objects

10.3 Record at least the following audit trail entries for all system components for each 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.

10.3.1 User identification

10.3.2 Type of event

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

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.

10.4.3 Time settings are received from industryaccepted time sources.

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

10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN.

10.5.5 Use file-integrity monitoring or changedetection 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. Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure of a potential breach. The log- review process does not have to be manual. Especially for those entities with a large number of servers, consider use of log harvesting, parsing, and alerting tools.

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.

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.

with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).

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.

older data

r minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something

cent increase from last years data set. ent decrease from 2010. etection software on logs to ensure that existing log data cannot be changed without generating alerts. File- integrity monitoring can be extremely com capable automated tool (log aggregator) to monitor logs on a daily basis, not maintaining security procedures to trigger a response to an exception repo

Testing Procedure

10.1 Verify through observation and interviewing the system administrator, that audit trails are enabled and active for system components.

10.2 Through interviews, examination of audit logs, and examination of audit log settings, perform the following:

10.2.1 Verify all individual access to cardholder data is logged.

10.2.2 Verify actions taken by any individual with root or administrative privileges are logged.

10.2.3 Verify access to all audit trails is logged.

10.2.4 Verify invalid logical access attempts are logged.

10.2.5 Verify use of identification and authentication mechanisms is logged.

10.2.6 Verify initialization of audit logs is logged.

10.2.7 Verify creation and deletion of system level objects are logged.

10.3 Through interviews and observation, for each auditable event (from 10.2), perform the following:

10.3.1 Verify user identification is included in log entries.

10.3.2 Verify type of event is included in log entries.

10.3.3 Verify date and time stamp is included in log entries.

10.3.4 Verify success or failure indication is included in log entries.

10.3.5 Verify origination of event is included in log entries.

10.3.6 Verify identity or name of affected data, system component, or resources is included in log entries.

10.4.a Verify that time-synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.

10.4.b Obtain and review the process for acquiring, distributing and storing the correct time within the organization, and review the time-related system-parameter settings for a sample of system components. Verify the following is included in the process and implemented:

10.4.1.a Verify that only designated central time servers receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

10.4.1.b Verify that the designated central time servers peer with each other to keep accurate time, and other internal servers receive time only from the central time servers.

10.4.2.a Review 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 Review system configurations and time synchronization settings and processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed.

10.4.3 Verify that the time servers accept time updates from specific, industryaccepted 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).

10.5 Interview system administrator and examine permissions to verify that audit trails are secured so that they cannot be altered as follows:

10.5.1 Verify that only individuals who have a job-related need can view audit trail files.

10.5.2 Verify that current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.

10.5.3 Verify that current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.

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.

10.5.5 Verify the use of file-integrity monitoring or change- detection software for logs by examining system settings and monitored files and results from monitoring activities.

10.6.a Obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.

10.6.b Through observation and interviews, verify that regular log reviews are performed for all system components.

10.7.a Obtain and examine security policies and procedures and verify that they include audit log retention policies and require audit log retention for at least one year.

10.7.b Verify that audit logs are available for at least one year and processes are in place to immediately restore at least the last three months logs for analysis.

lows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible

erating alerts. File- integrity monitoring can be extremely complex and expensive to implement. security procedures to trigger a response to an exception report, and the inability to test implementations of log archival

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priority

A B C-VT

Identify the system administrator(s) interviewed who confirm that audit trails are enabled and active for system components. 4

Identify the responsible personnel interviewed who confirm that all individual access to cardholder data is logged. cardholder data. 4

Identify the responsible personnel interviewed who confirm that actions taken by any individual with root or administrative privileges are logged. individual with root or administrative privileges. 4 root or administrative privileges.

Identify the responsible personnel interviewed who confirm that access to all audit trails is logged. 4 Describe how observed audit logs include access to all audit trails. Identify the responsible personnel interviewed who confirm that invalid logical access attempts are logged. 4

Identify the responsible personnel interviewed who confirm that the use of identification and authentication mechanisms is logged. and authentication mechanisms. mechanisms. 4

Identify the responsible personnel interviewed who confirm that the initialization of audit logs is logged. 4

Identify the responsible personnel interviewed who confirm that the following are logged: i. Creation of system level objects ii. Deletion of system level objects 4 i. Creation of system level objects ii. Deletion of system level objects Creation of system level objects and Deletion of system level objects

For each auditable event from 10.2.1 10.2.7: Identify the responsible personnel interviewed who confirm that user identification is included in log entries. Describe how audit logs were observed to include user identification. For each auditable event from 10.2.1 10.2.7: dentify the responsible personnel interviewed who confirm that the type of event is included in log entries. Describe how audit logs were observed to include the type of event. For each auditable event from 10.2.1 10.2.7: dentify the responsible personnel interviewed who confirm that the date and time is included in log entries. Describe how audit logs were observed to include the date and time. For each auditable event from 10.2.1 10.2.7: Identify the responsible personnel interviewed who confirm that success or failure I.indication is included in log entries. ii. Describe how audit logs were observed to include success or failure indication. For each auditable event from 10.2.1 10.2.7: Identify the responsible personnel interviewed who confirm that origination of the event is included in log entries. ii. Describe how audit logs were observed to include the origination of the event. For each auditable event from 10.2.1 10.2.7: Identify the responsible personnel interviewed who confirm that the identity or name of affected data, system component, or resource is included in log entries. ii. Describe how audit logs were observed to include the identity or name of affected data,

Identify the time synchronization technologies in use. technologies are kept current per PCI DSS Requirements 6.1 and 6.2. i. Implemented i. Kept current per the documented process

Identify the document that defines processes for acquiring, distributing, and storing the correct time within the organization, and confirm the processes require that: i. Only designated central time servers receive time signals from external sources. ii. Time signals from external sources are based on International Atomic Time or UTC. Identify the sample of system components observed. confirm that: i. Only designated central time servers receive time signals from external sources. ii. Time signals from external sources are based on International Atomic Time or UTC. Identify the document requiring that: the designated central time servers peer each other to keep accurate time Other internal time servers received time from central time servers Identify the sample of system components observed Describe how configuration settingsobserved on the sample system components confirm the above. Describe how time synchronization processes were observed to verify the above. Identify the document that: i. Requires that access to time data is restricted to only personnel with a business need to access time data. ii. Defines which personnel have a business need to access time data.

4 access to time data have a business need to access time data.

observed to restrict access to time data to only personnel with a documented business need. Identify the document that requires: i. Changes to time settings on critical systems are logged ii. Changes to time settings on critical systems are monitored iii. Changes to time settings on critical systems are reviewed 4

observed to log any changes to time settings on critical systems. Changes to time settings on critical systems are logged Changes to time settings on critical systems are monitored Changes to time settings on critical systems are reviewed

Identify the document that defines how time settings are received from industryaccepted time sources Describe how configuration settings on time servers were observed to receive time updates from specific, industry-accepted external sources. servers receive time updates from specific, industry-accepted external sources. Optionnally: Identify the document that defines how time updates are encrypted with a symmetric key, and access control lists specify the IP addresses of client machines to be provided with the time updates. updates with a symmetric key. machines to be provided with the time updates. updates are encrypted with a symmetric key, and access control lists are implemented to specify the IP addresses of client machines.

Identify the document defining which personnel have a job-related need to view audit personnel with access to view audit trail files have a business need to do so. audit trail files to only individuals who have a documented job-related need. related need can view the audit trail files. Describe the methods used to protect audit trail files from unauthorized modifications (e.g., via access control mechanisms, physical segregation, and/or network segregation). Describe how system configurations and audit log settings were observed to protect audit trail files from unauthorized modifications. Describe how observed access to audit logs confirms that audit trail files are protected from unauthorized modifications. Identify and briefly describe: i. The centralized log server or media that audit trail files are backed up to ii. How frequently the audit trail files are backed up, and how the frequency Is appropriate iii. How the centralized log server or media is difficult to alter i. That current audit trail files are promptly backed up to the centralized log server or media. ii. The frequency that audit trail files are backed up iii. That the centralized log server or media is difficult to alter. back up audit trail files to the centralized log server or media.

Describe how logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are offloaded or copied onto a secure centralized internal log server or media. Identify the responsible personnel interviewed who confirm that logs for externalfacing technologies are offloaded or copied onto a secure, centralized internal log server or media. to offload or copy logs onto a secure centralized internal log server or media. the centralized internal log server or (FIM) or change-detection software in use. Identify the file-integrity monitoring media. software, who were interviewed to confirm that audit log files are monitored. log data cannot be changed without generating alerts.

4 cannot be changed without generating alerts.

Identify the security policy document which requires: i. Review of logs for all system components, including those that perform security functions, at least daily ii. Follow-up to exceptions 4 i. Reviewing logs for all system components at least daily ii. Following up exceptions i. Reviewing logs for all system components at least daily ii. Following up exceptions Identify the responsible personnel interviewed who confirm that: i. Log reviews are performed for all system components at least daily ii. Log reviews include follow-up to exceptions 4 Log reviews are performed for all system components Log reviews include follow-up to exceptions Identify the security policy document that: i. Defines audit log retention policies ii. Requires audit log retention for at least one year. Identify the document which defines procedures for audit log retention. Describe how the implemented procedures ensure audit log retention for at least one year.

Identify the document that defines the process to immediate restore at least the last three months logs for analysis. Describe the implemented processes. Describe how audit logs and restore processes were observed to confirm that: i. ii. Audit logs are available for at least one year. At least the last three months logs can be immediately restored for analysis.

132

0 0

y difficult, if not impossible, without system activity logs.

I n t e r m e In case of C add a d row in the i Compensating a Controls sheet. r y C o n t r o l

N N

Select In Place ? (Y)es (N)o (C)ompensating control

Severity

Proofs / Documentation links

Stage of implementation

33

Y N C

132

Remediation plan

Estimated date for completion

Comments

Owner

Major observations from the 2011 Verizon PCI Compliance Report: Only 37 percent of organizations fully met Requirement 11 at the time of IROC It is the least compliant key control of the PCI DSS standard Organizations met an average of 65 percent of tests in Requirement 11 at time of IROC, a five percent drop, from 2010. Organizations continue to have difficulty meeting the sub-requirements regarding network vulnerability scanning (11.2), penetration testin 67 percent of organizations met the testing requirements of 11.2. The difficulties reside into the frequency (quarterly) combined with the expectation that findings are remediated and re- tested. Time and resource constraints hindered some in our sample from being able to present four passing external and internal scans. 53 percent of organizations perform external and internal penetration testing at least once a year and after any significant infrastructure o

PCI DSS Requirement

NEW - Guidance

11.1 Test for the presence of wireless access points and detect 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.

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

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 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re- scan. For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.

A vulnerability scan is an automated tool run against external and internal network devices and servers, designed to expose potential vulnerabilities in networks that could be found and exploited by malicious individuals. Once these weaknesses are identified, the entity corrects them, and repeats the scan to verify the vulnerabilities have been corrected. At the time of an entitys initial PCI DSS assessment, it is possible that four quarterly scans have not yet been performed. If the most recent scan result meets the criteria for a passing scan, and there are policies and procedures in place for future quarterly scans, the intent of this requirement is met. It is not necessary to delay an in place assessment for this requirement due to a lack of four scans if these conditions are satisfied.

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.

11.2.2 Perform quarterly external vulnerability scans As external networks are at greater risk of via an Approved Scanning Vendor (ASV), approved compromise, quarterly external vulnerability by the Payment Card Industry Security Standards scanning must be performed by a PCI SSC Council (PCI SSC).

Approved Scanning Vendor (ASV).

Note: Quarterly external vulnerability scans must be ASVs are required to follow a set of scanning performed by an Approved Scanning Vendor (ASV), and reporting criteria set forth by the PCI SSC in approved by the Payment Card Industry Security the Approved Scanning Vendor Program Guide Standards Council (PCI SSC). Scans conducted after network changes may be performed by internal staff.

List of approved scanning vendors

11.2.3 Perform internal and external scans after any significant change. Note: Scans conducted after changes may be performed by internal staff.

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 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a subnetwork added to the environment, or a web server added to the environment). These penetration tests must include the following:

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 which may include exploiting identified vulnerabilities. Often, performing a vulnerability scan is one of the first steps a penetration tester will perform in order to comprise a strategy of attack, although it is not the only step. Even if a vulnerability scan does not detect any 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 must utilize 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 in order to identify any areas of potential weakness in the environment that need to be addressed.

11.3.1 Network-layer penetration tests

11.3.2 Application-layer penetration tests

11.4 Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment, and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.

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.

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

File-integrity monitoring (FIM) tools check for changes to critical files, and notify when such changes are detected. There are both off-the-shelf and open source tools available for file integrity monitoring. If not implemented properly and the output of the FIM monitored, a malicious individual Note: For file-integrity monitoring purposes, critical could alter configuration file contents, operating files are usually those that do not regularly change, system programs, or application executables. Such but the modification of which could indicate a unauthorized changes, if undetected, could render system compromise or risk of compromise. Fileexisting security controls ineffective and/or result in integrity monitoring products usually come precardholder data being stolen with no perceptible configured with critical files for the related operating impact to normal processing. system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

rcent drop, from 2010. erability scanning (11.2), penetration testing (11.3), and file integrity monitoring (11.5).

s are remediated and re- tested. ssing external and internal scans. ar and after any significant infrastructure or application upgrade or modification (Requirement 11.3).

Testing Procedure

11.1.a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis.

11.1.b Verify that the methodology is adequate to detect 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 Verify that the documented process to identify unauthorized wireless access points is performed at least quarterly for all system components and facilities.

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.e Verify the organizations incident response plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected.

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

11.2.1.b Review the scan reports and verify that the scan process includes rescans until passing results are obtained, or all High vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.

11.2.1.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

11.2.2.a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly scans occurred in the most recent 12-month period.

11.2.2.b Review the results of each quarterly scan to ensure that they satisfy the ASV Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0 by the CVSS and no automatic failures).

11.2.2.c Review the scan reports to verify that the scans were completed by an Approved Scanning Vendor (ASV), approved by the PCI SSC.

11.2.3.a Inspect change control documentation and scan reports to verify that system components subject to any significant change were scanned.

11.2.3.b Review scan reports and verify that the scan process includes rescans until: - For external scans, no vulnerabilities exist that are scored greater than a 4.0 by the CVSS, - For internal scans, a passing result is obtained or all High vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.

11.2.3.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

11.3.a Obtain and examine the results from the most recent penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment.

11.3.b Verify that noted exploitable vulnerabilities were corrected and testing repeated.

11.3.c Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV). 11.3.1 Verify that the penetration test includes network-layer penetration tests. These tests should include components that support network functions as well as operating systems.

11.3.2 Verify that the penetration test includes application-layer penetration tests. The tests should include, at a minimum, the vulnerabilities listed in Requirement 6.5.

11.4.a Verify the use of intrusion-detection systems and/or intrusion-prevention systems and that all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment is monitored.

11.4.b Confirm IDS and/or IPS are configured to alert personnel of suspected compromises.

11.4.c Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection.

11.5.a Verify the use of file-integrity monitoring tools within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities. Examples of files that should be monitored: - System executables - Application executables - Configuration and parameter files - Centrally stored, historical or archived, log and audit files

11.5.b Verify the tools are configured to alert personnel to unauthorized modification of critical files, and to perform critical file comparisons at least weekly.

ment 11.3).

Validation Instructions for QSA/ISA (For In-Place Requirements)

Priotity

A B C-VT

Identify the document that defines the methods and processes to: i. Detect wireless access points. ii. Identify unauthorized wireless access points. iii. Perform the process (at least) on a quarterly basis.

Describe the documented methodology for detection and identification of unauthorized wireless access points, including: i. WLAN cards inserted into system components ii. Portable wireless devices connected to system components iii. Wireless devices attached to a network port or network device iv. Any other unauthorized wireless access points Describe how the methodology/processes were observed to be adequate to detect and identify unauthorized wireless access points, including: i. WLAN cards inserted into system components ii. Portable wireless devices connected to system components iii. Wireless devices attached to a network port or network device iv. Any other unauthorized wireless access points Identify the personnel who perform the process who were interviewed to confirm that: i. The process is performed at least quarterly ii. The process covers all system components iii. The process covers all facilities Describe how observed results of previously performed processes confirm that: The process is performed at least quarterly The process covers all system components The process covers all facilities

Identify and describe any automated monitoring technologies in use (for example, wireless IDS/IPS, NAC, etc.) i. Describe how the observed technology is configured to generate alerts to personnel. ii. Describe how alerts to personnel were observed to be generated. iii. Identify the personnel responsible for receiving the alerts, who were interviewed to confirm that the generated alerts are received as intended. Identify the Incident Response Plan document that defines response procedures in the event unauthorized wireless devices are detected. unauthorized wireless devices are detected, the documented response is followed.

Identify the internal scan report documents that verify four quarterly internal scans occurred in the most recent 12-month period. month period, identify the following: i. Date quarterly scan was performed ii. Result of scan

Identify the document that defines the process for performing rescans as part of the quarterly internal scan process. followed for quarterly internal scans. following: i. Whether a rescan was required ii. Details of how rescans were performed until either: o Passing results are obtained, or o All High vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved. From the scan reports, indetify whether internal and/or external resources perform internal scans Indetify the interviwed personnel who performed the scans, and describe how the personnel demonstrated they are qualified to perform the scans Describe how organizational independence of the tester was observed to exist. 2

Identify the external scan report documents that verify four quarterly external scans occurred in the most recent 12-month period. 2

Describe how the external scan reports verify that the scans satisfy the ASV Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0 by the CVSS and no automatic failures). Describe how the external scan reports verify that the scans were completed by a PCI SSC- Approved Scanning Vendor (ASV).

Identify the document that defines the process for performing internal and external scans after any significant change. system components during the past 12 months. 2 system components subject to significant change were scanned after the change. For all scans reviewed in 11.2.3.a, identify the following: i. Whether a rescan was required ii. Details of how rescans were performed until: o For external scans No vulnerabilities with a CVSS score greater than 4.0 exist. o For internal scans Either passing results were obtained, or all High vulnerabilities as defined in PCI DSS Requirement 6.2 were resolved. after significant changes includes rescans as defined. From the scan reports, identify whether internal and/or external resources perform how the personnel demonstrated they are qualified to perform the scans. 2

Identify the documented penetration test results which confirm: i. Internal penetration tests are performed annually. ii. External penetration tests are performed annually. occurred during the past 12 months. are performed after: i. Significant internal infrastructure or application upgrade. ii. Significant external infrastructure or application upgrade.

Identify whether any exploitable vulnerabilities were noted in the most recent: i. Internal penetration test results ii. External penetration test results vulnerabilities were corrected. i. Testing was repeated. ii. All noted exploitable vulnerabilities were corrected. Indetify wheter internal or external resources performed the penetration tests Indentify the interviewed personnel who performed the tests and describehow the personnel demonstrated that they are qualified for such tests Describe how organizational independence is ensured. Identify the documented results from the most recent penetration tests confirming that: i. Internal penetration testing includes network-layer penetration tests. ii. External penetration testing includes network-layer penetration tests. iii. The network-layer penetration tests include: o Components that support network functions o Operating systems Identify the responsible personnel interviewed who confirm that: i. Internal penetration testing includes network-layer penetration tests. ii. External penetration testing includes network-layer penetration tests. iii. The network-layer penetration tests include: o Components that support network functions o Operating systems 2

Identify the documented results from the most recent penetration tests confirming that: i. ii. Internal penetration testing includes application-layer penetration tests. External penetration testing includes application-layer penetration tests. The application-layer tests include, at a minimum, the vulnerabilities listed in PCI DSS Requirement 6.5. Identify the responsible personnel interviewed who confirm that: Internal penetration testing includes application-layer penetration tests. External penetration testing includes application-layer penetration tests. The application-layer tests include, at a minimum, the vulnerabilities listed in PCI DSS Requirement 6.5. Describe the intrusion-detection and/or intrusion-prevention systems (IDS/IPS) that are implemented. ensure that all traffic is monitored: i. At the perimeter of the cardholder data environment ii. At critical points within the cardholder data environment At the perimeter of the cardholder data environment ii. At critical points within the cardholder data environment

Describe how observed IDS/IPS are configured to alert personnel of suspected compromises. 2 confirm that the generated alerts are received as intended.

Identify the document that defines vendor instructions for: i. Configuring IDS/IPS devices ii. Maintaining IDS/IPS devices iii. Updating IDS/IPS devices 2 instructions are followed for: Configuring IDS/IPS devices Maintaining IDS/IPS devices Updating IDS/IPS devices Describe the file-integrity monitoring (FIM) tools deployed. Describe how FIM settings and configurations were observed to monitor changes to: i. Critical system files ii. Critical configuration files iii. Critical content files Describe how observed results from monitoring activities confirm that changes to the following files are monitored: i. Critical system files ii. Critical configuration files iii. Critical content files

Describe how observed FIM settings are configured to: Alert personnel to unauthorized modification of critical files Perform Critical file comparisons at least weekly Describe how results and alerts from monitoring activities were observed to confirm the above Identify the responsible personnel who were interviewed to confirm the above.

64

0 0

Select In Place ? (Y)es (N)o (C)ompensating control In case of C add a row in the Compensating Controls sheet.

Severity

Proofs / Documentation links

15

25

Y N C

64

Stage of implementation

Remediation plan

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 b

Major Observations from the 2011 Verizon PCI Compliance Report: 39 percent of organizations fully met Requirement 12 at the time of IROC. This is a five percent drop in comparison to the 2010 report find Organizations met an average of 79 percent of tests in Requirement 12 at the time of IROC. Policies are written without completing prerequisite work; thus they lack critical content, and fail to identify the information assets that m The most compliant sub-control for Requirement 12 at the time of the IROC is 12.4 The most challenging sub-requirements under Requirement 12 are 12.8.2 and 12.8.4. Requirement 12.8.2, formally obtaining acknowledgement from service providers of their commitment to maintain proper security of card Lack of interpretation of sub-control 12.8.4 (Maintain a program to monitor service providers PCI DSS compliance status) contributed towa

PCI DSS Requirement

NEW - Guidance

12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following:

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 Addresses all PCI DSS requirements.

12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. (Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.)

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, 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. Daily operational security procedures act as desk instructions for personnel to use in their day-to-day system administrative and maintenance activities. Undocumented operational security procedures will lead to personnel who are not aware of the full scope of their tasks, processes that cannot be repeated easily by new workers, and potential gaps in these processes that may allow a malicious individual to gain access to critical systems and resources. 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. 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.1.3 Includes a review at least annually and updates when the environment changes.

12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).

12.3 Develop usage policies for critical technologies (for example, remote- access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDAs), email usage and Internet usage) and define proper use of these technologies. Ensure these usage policies require the following:

12.3.1 Explicit approval by authorized parties

12.3.2 Authentication for use of the technology

f 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.3.3 A list of all such devices and personnel with access

12.3.4 Labeling of devices to determine owner, contact information and purpose

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 label and log all devices in concert with established inventory controls. Also, logical labeling may be employed with information such as codes that can correlate the device to its owner, contact information and purpose.

12.3.5 Acceptable uses of the technology

12.3.6 Acceptable network locations for the technologies

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.7 List of company-approved products

12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity

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.

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 12.3.9 Activation of remote-access technologies for devices after 15 minutes of inactivity. Please also see vendors and business partners only when needed Requirement 8.5.6 for more on this topic. by vendors and business partners, with immediate deactivation after use

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.

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.

12.5 Assign to an individual or team the following information security management responsibilities:

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.

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.1 Establish, document, and distribute security policies and procedures.

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.

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

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 computerbased training session, while ongoing periodic updates may be delivered via e-mails, posters, 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.6.2 Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures.

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.8 If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service providers, to include the following: 12.8.1 Maintain a list of service providers.

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. 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. 12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

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. 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. 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. 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.8.4 Maintain a program to monitor service providers PCI DSS compliance status at least annually.

12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.

12.9.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum: - Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum - Specific incident response procedures - Business recovery and continuity procedures - Data back-up processes - Analysis of legal requirements for reporting compromises - Coverage and responses of all critical system components - Reference or inclusion of incident response procedures from the payment brands 12.9.2 Test the plan at least annually.

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.

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.9.3 Designate specific personnel to be available Without proper testing, key steps may be missed on a 24/7 basis to respond to alerts. 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.

would need to encompass all components of the plan.

12.9.4 Provide appropriate training to staff with security breach response responsibilities.

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

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

personnel.

s expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement

drop in comparison to the 2010 report findings.

il to identify the information assets that must be protected.

itment to maintain proper security of cardholder data obtained from clientsand accepting accountability for the protection of that data remains a t CI DSS compliance status) contributed towards its low compliance rating.

Testing Procedure

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

12.1.1 Verify that the policy addresses all PCI DSS requirements.

12.1.2.a Verify that an annual risk assessment process is documented that identifies threats, vulnerabilities, and results in a formal risk assessment.

12.1.2.b Review risk assessment documentation to verify that the risk assessment process is performed at least annually. 12.1.3 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 Examine the daily operational security procedures. Verify that they are consistent with this specification, and include administrative and technical procedures for each of the requirements.

12.3 Obtain and examine the usage policies for critical technologies and perform the following:

12.3.1 Verify that the usage policies require explicit approval from authorized parties to use the technologies.

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

12.3.3 Verify that the usage policies require a list of all devices and personnel authorized to use the devices.

12.3.4 Verify that the usage policies require labeling of devices with information that can be correlated to owner, contact information and purpose.

12.3.5 Verify that the usage policies require acceptable uses for the technology.

12.3.6 Verify that the usage policies require acceptable network locations for the technology.

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

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.

12.4 Verify that information security policies clearly define information security responsibilities for all personnel.

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:

12.5.1 Verify that responsibility for creating and distributing security policies and procedures is formally assigned.

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.

12.5.3 Verify that responsibility for creating and distributing security incident response and escalation procedures is formally assigned.

12.5.4 Verify that responsibility for administering user account and authentication management is formally assigned.

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

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.

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.

12.8 If the entity shares cardholder data with service providers (for example, back-up tape storage facilities, managed service providers such as Web hosting companies or security service providers, or those that receive data for fraud modeling purposes), through observation, review of policies and procedures, and review of supporting documentation, perform the following: 12.8.1 Verify that a list of service providers is maintained.

12.8.2 Verify that the written agreement includes an acknowledgement by the service providers of their responsibility for securing cardholder data.

12.8.3 Verify that policies and procedures are documented and were followed including proper due diligence prior to engaging any service provider.

12.8.4 Verify that the entity maintains a program to monitor its service providers PCI DSS compliance status at least annually.

12.9 Obtain and examine the Incident Response Plan and related procedures and perform the following:

12.9.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.9.1.b Review documentation from a previously reported incident or alert to verify that the documented incident response plan and procedures were followed.

12.9.2 Verify that the plan is tested at least annually.

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

12.9.4 Verify through observation and review of policies that staff with responsibilities for security breach response are periodically trained.

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

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

onsibilities for protecting it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contra

ng accountability for the protection of that data remains a taxing compliance issue

Validation Instructions for QSA/ISA (For In-place requirements)

Priority

Identify the documented information security policy. to: i. All relevant personnel ii. All relevant vendors and business partners the policy. Describe how the policy addresses all applicable PCI DSS requirements.

1 how the documented process: i. Identifies threats and vulnerabilities ii. Results in formal risk assessment

Describe how observed risk assessment results confirm that: i. The risk assessment process is performed at least annually. ii. The documented risk assessment process was followed. Indetify the document requiring that the information security polcy is: Reviewed at least annually and updated as neededto reflect changes to business objectives or risk environment Identify the personnel interviewd who confirmed the above Describe how the above were observed.

6 documented procedures: i. Are consistent with PCI DSS requirements ii. Include administrative procedures for each requirement iii. Include technical procedures for each requirement implemented including: i. Administrative procedures for each requirement ii. Technical procedures for each requirement 6

Identify critical technologies in use. i. Identify the documented usage policies defining proper use of the technology. ii. Describe how the documented policies require explicit approval from authorized parties to use the technology. iii. Describe how explicit approval for use of the technology was observed to be implemented.

For each identified critical technology: i. Describe how the documented policies require that use of the technology be authenticated with user ID and password or other authentication item. ii. Describe how the required authentication for use of the technology was observed to be implemented. For each identify critical technology: Describe how the documented policies require: o A list of all devices o A list of personnel authorized to use the devices Describe how the following was observed to be implemented: o A list of all devices o A list of personnel authorized to use the devices For each identify critical technology: Describe how the documented policies require labeling of devices with information that can be correlated to: o Owner o Contact information o Purpose Describe how labeling was observed to be implemented which correlates to: o Owner o Contact information o Purpose For each identify critical technology: Describe how the documented policies require acceptable uses for the technology. Describe how requirements for acceptable uses of the technology were observed to beimplemented. For each identify critical technology: Describe how the documented policies require acceptable uses for the technology. Describe how requirements for acceptable network locations were observed to be implemented. For each identify critical technology: Describe how the documented policies require a list of company-approved products. Describe how the list of company-approved products was observed to be implemented. For each remote-access technology: Describe how the documented policies require automatic disconnect of sessions after a specific period of inactivity. Describe how automatic disconnect after a specific period of inactivity was observed to be implemented.

6 each remote-access technology: Describe how the documented policies require: o Activation of the technology only when needed o Immediate deactivation of the technology after use Describe how it was observed that: The technology is activated only when needed. The technology is immediately deactivated after use.

Describe how the documented policies prohibit the following for personnel accessing cardholder data via remote-access technologies: i. Copying of cardholder data onto local hard drives and removable electronic media ii. Moving of cardholder data onto local hard drives and removable electronic media iii. Storage of cardholder data onto local hard drives and removable electronic media accessing cardholder data via remote-access technologies: Prohibit the copying of cardholder data onto local hard drives and removable electronic media Prohibit the moving of cardholder data onto local hard drives and removable electronic media Prohibit the storage of cardholder data onto local hard drives and removable electronic media Identify the documentation that defines whether any authorized business need for copying, moving, or storing cardholder data onto local hard drives or removable electronic media via remote-access technologies exists. Identify how explicit authorization was observed to be implemented for the copying, moving, or storage of cardholder data onto local hard drives or removable electronic media. Describe how the documented policies require the protection of cardholder data in accordance with PCI DSS Requirements, for all personnel with proper authorization. Describe how the protection of cardholder data was observed to be implemented in accordance with PCI DSS Requirements. Describe how the security policy and procedures clearly define information security responsibilities for all personnel. information security responsibilities.

Identify the document that formally assigns responsibility for information security to a Chief Security Officer or other security-knowledgeable member of management. to be implemented.

Identify the document that formally assigns responsibility for: i. Creating security policies and procedures ii. Distributing security policies and procedures i. Creating security policies and procedures ii. Distributing security policies and procedures Identify the document that formally assigns responsibility for: Monitoring and analyzing security alerts Distributing information to appropriate information security and business unit management personnel i. Monitoring and analyzing security alerts ii. Distributing information to appropriate information security and business unit management personnel Identify the document that formally assigns responsibility for: Creating and distributing security incident response and escalation procedures Describe how the above assigned responsibilities were observed to be implemented. Identify the document that formally assigns responsibility for administering user account and authentication management. authentication management was observed to be implemented. Identify the document which formally assigns responsibility for: i. Monitoring all access to data ii. Controlling all access to data for: i. Monitoring all access to data ii. Controlling all access to data Identify the document that defines a formal security awareness program for all implemented for all personnel.

4 6

6 6

Identify the document defining the methods of communicating awareness and educating personnel. Identify the methods observed for communicating awareness and educating personnel.

Identify the document requiring that all personnel attend awareness training: i. Upon hire ii. At least annually Upon hire At least annually

Identify the document that requires: i. All personnel to acknowledge that they have read and understand the information security policy. ii. All personnel to provide an acknowledgement at least annually. i. All personnel acknowledge that they have read and understand the information security policy. ii. All personnel provide an acknowledgement at least annually. Identify the document requiring that backgroud checks be conducted: On potential personnel who wil have access to the cardholder data environment Prior to hiring personnel Identify the HR personnel who were interviewed to confirm the above Describe how the above was observed.

1 2

Identify all service providers with whom cardholder data is shared. cardholder data is shared. maintained (kept up-to-date). For each service provider with whom cardholder data is shared: Identify the document that includes service provider acknowledgment of their responsibility for securing cardholder data.

1 2

Identify the document that defines procedures for proper due diligence prior to engaging any service provider. implemented. 2

Identify the document that: i. Defines a program to monitor service providers PCI DSS compliance status ii. Requires that service providers PCI DSS compliance status be monitored at least annually was observed to be implemented. 2 monitored at least annually.

Identify the incident response plan and procedure document(s). Describe how the document includes: i. Roles and responsibilities ii. Communication strategies iii. Requirement for notification of the payment brands iv. Specific incident response procedures v. Business recovery and continuity procedures vi. Data back-up processes vii. Analysis of legal requirements for reporting compromises viii. Coverage for all critical system components ix. Responses for all critical system components x. Reference or inclusion of incident response procedures from the payment brands

Identify documentation from a previously reported incident or alert. Describe how the documentation verifies that the defined incident response plan and procedures were followed. Identify the document that: i. Defines procedures for testing the incident response plan ii. Requires the plan be tested at least annually i. The incident response plan is tested according to the defined procedures. ii. The plan is tested at least annually. i. Tested according to the defined procedures ii. Tested at least annually

Identify the document that designates personnel to be available for: i. 24/7 incident monitoring ii. 24/7 incident response for: i. Any evidence of unauthorized activity ii. Detection of unauthorized wireless access points iii. Critical IDS alerts iv. Reports of unauthorized critical system or content file changes is provided for: i. Evidence of unauthorized activity ii. Detection of unauthorized wireless access points iii. Critical IDS alerts iv. Reports of unauthorized critical system or content file changes

Identify the document requiring that staff with security breach responsibilities are periodically trained. periodically trained. Identify the document that defines how the following are monitored: i. Alerts from intrusion-detection/intrusion-prevention ii. Alerts from file-integrity monitoring systems iii. Detection of unauthorized wireless access points i. Alerts from intrusion-detection/intrusion-prevention ii. Alerts from file-integrity monitoring systems iii. Detection of unauthorized wireless access points implemented: i. Alerts from intrusion-detection / intrusion-prevention ii. Alerts from file-integrity monitoring systems. iii. Detection of unauthorized wireless access points implemented: i. Alerts from intrusion-detection/intrusion-prevention ii. Alerts from file-integrity monitoring systems iii. Detection of unauthorized wireless access points Identify the document which defines the processes to mofify ane evolve the incident response plan: According to lessons learned To incorporate industry development Describe how the above processes were observed to be implemented. 4 4

216

s, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environme

C-VT

Select In Place ? (Y)es (N)o (C)ompensating control

I n t e r m e In case of C add d a row in the i Compensating a Controls sheet. r y C o n t r o l

N

Severity

Proofs / Documentation links

Stage of implementation

N 1 N N 6

N 1 N 1 1 1 1 N 6 N 1

N 1 N 6

N 1 N 6

N 1 1 1 1 N 6

N 1 1 1 1 N 6

N 1 1 N 6

N 1 1 1 1 N 6

N 1 1 N 6

N 1 N 1 1 N 6 N 6

N 1 N 6

N 1 N 6

N 1 1 1 1 N 6

N 1 1 1 1 N 6

N 1 N 6

N 1 1 1 1 N 4

N 1 N 6

N 1 N 6

N 1 1 1 1 N 6

N 1 N 1 N 6 N 6

N 1 N 6

N 1 N 6

N 1 1 1 1 N 2

N 1 1 1 1 N 2

N 1 1 1 1 N 2

N 1 1 1 1 N 2

N 1 N 4

N 1 N 4

N 1 N 4

N 1 N 4

N 1 N 4

N 1 N 4

N 14 14 19 44 Y N C 216

ardholder data environment.

Remediation plan

Estimated date for completion

Comments

Owner