Pci Audit Procedures v1-1

7/31/2019 Pci Audit Procedures v1-1

1/51

Payment Card Industry (PCI) Data Security

Standard

Security Audit Procedures

Version 1.1Release: September 2006


2/51


3/51

Security Audit Procedures v 1.1 3

Introduction

The PCI Security Audit Procedures are designed for use by assessors conducting onsite reviews for merchants and serviceproviders required to validate compliance with Payment Card Industry (PCI) Data Security Standard (DSS) requirements.The requirements and audit procedures presented in this document are based on the PCI DSS.

This document contains the following:

Introduction

PCI DSS Applicability Information

Scope of Assessment for Compliance with PCI DSS Requirements Instructions and Content for Report On Compliance

Revalidation of Open Items

Security Audit Procedures

APPENDICES

Appendix A: PCI DSS Applicability for Hosting Providers (with Testing Procedures)

Appendix B: Compensating Controls

Appendix C: Compensating Controls Worksheet/Completed Example


4/51


PCI DSS Applicability Information

The following table illustrates commonly used elements of cardholder and sensitive authentication data; whether storage ofeach data element is permitted or prohibited; and if each data element must be protected. This table is not exhaustive,but is presented to illustrate the different types of requirements that apply to each data element.

* These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements for general protection of the

cardholder environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require

specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during the course of business. PCI DSS,

however, does not apply if PANs are not stored, processed, or transmitted.

** Sensitive authentication data must not be stored subsequent to authorization (even if encrypted).

Data Element Storage

Permitted

Protection

Required

PCI DSS

REQ. 3.4

Cardholder DataPrimary Account

Number (PAN)YES YES YES

Cardholder Name* YES YES* NO

Service Code* YES YES* NO

Expiration Date* YES YES* NO

Sensitive Authentication Data** Full Magnetic Stripe NO N/A N/A

CVC2/CVV2/CID NO N/A N/A

PIN / PIN Block NO N/A N/A


5/51


6/51


7/51


Compensating

Controls

Compensating controls must be documented by the assessor and included with the Report on Compliance submission, asshown in Appendix C Compensating Controls Worksheet / Completed Example.

See PCI DSS Glossary, Abbreviation, and Acronyms for the definitions of compensating controls.

Instructions and Content for Report on Compliance

This document is to be used by assessors as the template for creating the Report on Compliance. The audited entity shouldfollow each payment card companys respective reporting requirements to ensure each payment card companyacknowledges the entitys compliance status. Contact each payment card company to determine each companys reportingrequirements and instructions. All assessors must follow the instructions for report content and format when completing aReport on Compliance:

1. Contact Information and Report Date

Include contact information for merchant or service provider and assessor

Date of report

2. Executive Summary

Include the following:

Business description

List service providers and other entities with which the company shares cardholder data

List processor relationships

Describe whether entity is directly connected to payment card company

For merchants, POS products used


8/51


Any wholly-owned entities that require compliance with the PCI DSS

Any international entities that require compliance with the PCI DSS

Any wireless LANs and/or wireless POS terminals connected to the cardholder environment

3. Description of Scope of Work and Approach Taken

Version of the Security Audit Procedures document used to conduct the assessment

Timeframe of assessment

Environment on which assessment focused (for example, clients Internet access points, internal corporate network,processing points for the payment card company)

Any areas excluded from the review

Brief description or high-level drawing of network topology and controls

List of individuals interviewed

List of documentation reviewed

List of hardware and critical (for example, database or encryption) software in use

For Managed Service Provider (MSP) reviews, clearly delineate which requirements in this document apply to the MSP(and are included in the review), and which are not included in the review and are the responsibility of the MSPscustomers to include in their reviews. Include information about which of the MSPs IP addresses are scanned as partof the MSPs quarterly vulnerability scans, and which IP addresses are the responsibility of the MSPs customers toinclude in their own quarterly scans


9/51


4. Quarterly Scan Results

Summarize the four most recent quarterly scan results in comments at Requirement 11.2

Scan must cover all externally accessible (Internet-facing) IP addresses in existence at the entity

5. Findings and Observations

All assessors must use the following template to provide detailed report descriptions and findings on each requirementand sub-requirement

Where applicable, document any compensating controls considered to conclude that a control is in place

SeePCI DSS Glossary, Abbreviation, and Acronyms for the definitions of compensating controls.

Revalidation of Open Items

A controls in place report is required to verify compliance. If the initial report by the auditor/assessor contains openitems, the merchant/service provider must address these items before validation is completed. The assessor/auditor willthen reassess to validate that the remediation occurred and that all requirements are satisfied. After revalidation, theassessor will issue a new Report on Compliance, verifying that the system is fully compliant and submit it consistent withinstructions (See above.).

Build and Maintain a Secure NetworkRequirement 1: Install and maintain a firewall configuration to protect cardholder data

Firewalls are computer devices that control computer traffic allowed into and out of a companys network, as well as trafficinto more sensitive areas within a companys internal network. A firewall examines all network traffic and blocks thosetransmissions that do not meet the specified security criteria.

All systems must be protected from unauthorized access from the Internet, whether entering the system as e-commerce,employees Internet-based access through desktop browsers, or employees e-mail access. Often, seemingly insignificantpaths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key protectionmechanism for any computer network.

PCI DSS REQUIREMENTS TESTING PROCEDURES IN PLACENOT INPLACE

TARGET DATE/COMMENTS

1.1 Establish firewall configurationstandards that include the following:

1.1 Obtain and inspect the firewall configuration standardsand other documentation specified below to verify that

standards are complete. Complete each item in this section


10/51


11/51


12/51


13/51


14/51


15/51




2.2.3.c For a sample of system components, criticalservers, and wireless access points, verify that commonsecurity parameters are set appropriately

2.2.4 Remove all unnecessaryfunctionality, such as scripts, drivers,features, subsystems, file systems,and unnecessary web servers.

2.2.4 For a sample of system components, criticalservers, and wireless access points,, verify that allunnecessary functionality (for example, scripts, drivers,features, subsystems, file systems, etc.) is removed. Verifyenabled functions are documented, support secureconfiguration, and that only documented functionality ispresent on the sampled machines

2.3 Encrypt all non-consoleadministrative access. Usetechnologies such as SSH, VPN, orSSL/TLS (transport layer security) forweb-based management and othernon-console administrative access.

2.3 For a sample of system components, critical servers,and wireless access points,, verify that non-consoleadministrative access is encrypted by:

Observing an administrator log on to each systemto verify that SSH (or other encryption method) isinvoked before the administrators password isrequested

Reviewing services and parameter files onsystems to determine that Telnet and other remotelog-in commands are not available for useinternally

Verifying that administrator access to the wirelessmanagement interface is encrypted with SSL/TLS.Alternatively, verify that administrators cannotconnect remotely to the wireless managementinterface (all management of wirelessenvironments is only from the console)

2.4 Hosting providers must protect

each entitys hosted environment anddata. These providers must meetspecific requirements as detailed inAppendix A: PCI DSS Applicability forHosting Providers.

2.4 Perform testing procedures A.1.1 through A.1.4

detailed in Appendix A, PCI DSS Applicability for HostingProviders (with Testing Procedures) for PCI audits of SharedHosting Providers, to verify that Shared Hosting Providersprotect their entities (merchants and service providers)hosted environment and data.


16/51


Protect Cardholder Data

Requirement 3: Protect stored cardholder data

Encryption is a critical component of cardholder data protection. If an intruder circumvents other network security controlsand gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to thatperson. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities.For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncatingcardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.

PCI DSS REQUIREMENTS TESTING PROCEDURES IN PLACE NOT INPLACE


3.1 Keep cardholder data storageto a minimum. Develop a dataretention and disposal policy. Limitstorage amount and retention time tothat which is required for business,legal, and/or regulatory purposes, asdocumented in the data retention

policy.

3.1 Obtain and examine the company policies andprocedures for data retention and disposal, and perform thefollowing

Verify that policies and procedures include legal,regulatory, and business requirements for dataretention, including specific requirements forretention of cardholder data (for example,

cardholder data needs to be held for X period for Ybusiness reasons)

Verify that policies and procedures includeprovisions for disposal of data when no longerneeded for legal, regulatory, or business reasons,including disposal of cardholder data

Verify that policies and procedures includecoverage for all storage of cardholder data,including database servers, mainframes, transferdirectories, and bulk data copy directories used totransfer data between servers, and directoriesused to normalize data between server transfers

Verify that policies and procedures include Aprogrammatic (automatic) process to remove, atleast on a quarterly basis, stored cardholder datathat exceeds business retention requirements, or,alternatively, requirements for an audit, conductedat least on a quarterly basis, to verify that storedcardholder data does not exceed business

retention requirements


17/51




3.2 Do not store sensitiveauthentication data subsequent toauthorization (even if encrypted).

Sensitive authentication data includesthe data as cited in the followingRequirements 3.2.1 through 3.2.3:

3.2 If sensitive authentication data is received and deleted,obtain and review the processes for deleting the data to verifythat the data is unrecoverable

For each item of sensitive authentication data below, performthe following steps:

3.2.1Do not store the full contentsof any track from the magneticstripe (that is on the back of a card,

in a chip or elsewhere). This data isalternatively called full track, track,track 1, track 2, and magnetic stripedata

In the normal course of business,the following data elements from themagnetic stripe may need to beretained: the accountholders name,primary account number (PAN),

expiration date, and service code.To minimize risk, store only thosedata elements needed for business.NEVER store the card verificationcode or value or PIN verificationvalue data elements.

Note: See Glossary for additionalinformation.

3.2.1 For a sample of system components, critical servers,and wireless access points, examine the following and verifythat the full contents of any track from the magnetic stripe on

the back of card are not stored under any circumstance: Incoming transaction data

Transaction logs

History files

Trace files

Debugging logs

Several database schemas

Database contents

3.2.2 Do not store the card-validation value or code (three-digitor four-digit number printed on thefront or back of a payment card) usedto verify card-not-presenttransactions

Note: See Glossary for additionalinformation.

3.2.2 For a sample of system components, critical servers,and wireless access points, examine the following and verifythat the three-digit or four-digit card-validation code printedon the front of the card or the signature panel (CVV2, CVC2,CID, CAV2 data) is not stored under any circumstance:

Incoming transaction data

Transaction logs

History files

Trace files

Debugging logs


18/51




Several database schemas Database contents

3.2.3 Do not store the personalidentification number (PIN) or theencrypted PIN block.

3.2.3 For a sample of system components, critical servers,and wireless access points, examine the following and verifythat PINs and encrypted PIN blocks are not stored under anycircumstance:

Incoming transaction data

Transaction logs

History files

Trace files Debugging logs

Several database schemas

Database contents

3.3 Mask PAN when displayed (thefirst six and last four digits are themaximum number of digits to bedisplayed).

Note: This requirement does not applyto employees and other parties with aspecific need to see the full PAN; nordoes the requirement supersedestricter requirements in place fordisplays of cardholder data (forexample, for point of sale [POS]receipts).

3.3 Obtain and examine written policies and examineonline displays of credit card data to verify that credit cardnumbers are masked when displaying cardholder data, exceptfor those with a specific need to see full credit card numbers

3.4 Render PAN, at minimum,unreadable anywhere it is stored

(including data on portable digitalmedia, backup media, in logs, anddata received from or stored bywireless networks) by using any of thefollowing approaches:

Strong one-way hashfunctions (hashed indexes)

Truncation

Index tokens and pads (pads

3.4.a Obtain and examine documentation about the systemused to protect stored data, including the vendor, type of

system/process, and the encryption algorithms (if applicable).Verify that data is rendered unreadable using one of thefollowing methods:

One-way hashes (hashed indexes) such as SHA-1

Truncation or masking

Index tokens and PADs, with the PADs being securelystored

Strong cryptography, such as Triple-DES 128-bit or

AES 256-bit, with associated key management


19/51




must be securely stored) Strong cryptography with

associated key managementprocesses and procedures

The MINIMUM account informationthat must be rendered unreadable isthe PAN.

If for some reason, a company isunable to encrypt cardholder data,

refer to Appendix B: CompensatingControls.

processes and procedures

3.4.b Examine several tables from a sample of databaseservers to verify the data is rendered unreadable (that is, notstored in plain text)

3.4.c Examine a sample of removable media (for example,

backup tapes) to confirm that cardholder data is renderedunreadable

3.4.d Examine a sample of audit logs to confirm thatcardholder data is sanitized or removed from the logs

3.4.e Verify that cardholder data received from wirelessnetworks is rendered unreadable wherever stored

3.4.1 If disk encryption is used(rather than file- or column-leveldatabase encryption), logicalaccess must be managedindependently of native operatingsystem access control mechanisms(for example, by not using localsystem or Active Directoryaccounts). Decryption keys must

not be tied to user accounts.

3.4.1.a If disk encryption is used, verify that logical accessto encrypted file systems is implemented via a mechanismthat is separate from the native operating systemsmechanism (for example, not using local or Active Directoryaccounts)

3.4.1.b Verify that decryption keys are not stored on thelocal system (for example, store keys on floppy disk, CD-ROM, etc. that can be secured and retrieved only whenneeded)

3.4.1.c Verify that cardholder data on removable media isencrypted wherever stored (disk encryption often cannotencrypt removable media)

3.5 Protect encryption keys usedfor encryption of cardholder dataagainst both disclosure and misuse:

3.5 Verify processes to protect encryption keys used forencryption of cardholder data against disclosure and misuseby performing the following:

3.5.1 Restrict access to keys to thefewest number of custodians

necessary

3.5.1 Examine user access lists to verify that access tocryptographic keys is restricted to very few custodians


20/51




3.5.2 Store keys securely in thefewest possible locations and forms 3.5.2 Examine system configuration files to verify thatcryptographic keys are stored in encrypted format and thatkey-encrypting keys are stored separately from data-encrypting keys

3.6 Fully document and implementall key management processes andprocedures for keys used forencryption of cardholder data,including the following:

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

3.6.b ForService Providers only: If the Service Providershares keys with their customers for transmission ofcardholder data, verify that the Service Provider provides

documentation to customers that includes guidance on how tosecurely store and change customers encryption keys (usedto transmit data between customer and service provider)

3.6.c Examine the key management procedures andperform the following:

3.6.1 Generation of strong keys 3.6.1 Verify that key management procedures require thegeneration of strong keys

3.6.2 Secure key distribution 3.6.2 Verify that key management procedures require

secure key distribution3.6.3 Secure key storage 3.6.3 Verify that key management procedures require

secure key storage

3.6.4 Periodic key changes

As deemed necessary andrecommended by theassociated application (forexample, re-keying);preferably automatically

At least annually

3.6.4 Verify that key management procedures requireperiodic key changes. Verify that key change procedures arecarried out at least annually

3.6.5 Destruction of old keys. 3.6.5 Verify that key management procedures require thedestruction of old keys

3.6.6 Split knowledge andestablishment of dual control of keys(so that it requires two or threepeople, each knowing only their partof the key, to reconstruct the wholekey

3.6.6 Verify that key management procedures require splitknowledge and dual control of keys (so that it requires two orthree people, each knowing only their part of the key, toreconstruct the whole key)


21/51




3.6.7 Prevention of unauthorizedsubstitution of keys 3.6.7 Verify that key management procedures require theprevention of unauthorized substitution of keys

3.6.8 Replacement of known orsuspected compromised keys

3.6.8 Verify that key management procedures require thereplacement of known or suspected compromised keys

3.6.9 Revocation of old or invalidkeys

3.6.9 Verify that key management procedures require therevocation of old or invalid keys (mainly for RSA keys)

3.6.10 Requirement for keycustodians to sign a form stating thatthey understand and accept their

key-custodian responsibilities

3.6.10 Verify that key management procedures require keycustodians to sign a form specifying that they understandand accept their key-custodian responsibilities

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Sensitive information must be encrypted during transmission over networks that are easy and common for a hacker tointercept, modify, and divert data while in transit.

PCI DSS REQUIREMENTS TESTING PROCEDURES IN PLACE NOT INPLACE


4.1 Use strong cryptography andsecurity protocols such as securesockets layer (SSL) / transport layersecurity (TLS) and internet protocolsecurity (IPSEC) to safeguardsensitive cardholder data duringtransmission over open, public

networks.Examples of open, public networksthat are in scope of the PCI DSS arethe Internet, WiFi (IEEE 802.11x),global system for mobilecommunications (GSM), and generalpacket radio service (GPRS).

4.1.a Verify the use of encryption (for example, SSL/TLS orIPSEC) wherever cardholder data is transmitted or receivedover open, public networks

Verify that strong encryption is used during datatransmission

For SSL implementations, verify that HTTPS appears

as a part of the browser Universal Record Locator(URL), and that no cardholder data is required whenHTTPS does not appear in the URL

Select a sample of transactions as they are receivedand observe transactions as they occur to verify thatcardholder data is encrypted during transit

Verify that only trusted SSL/TLS keys/certificates areaccepted

Verify that the proper encryption strength is

implemented for the encryption methodology in use


22/51




(Check vendor recommendations/best practices)

4.1.1 For wireless networkstransmitting cardholder data,encrypt the transmissions by usingWiFi protected access (WPA orWPA2) technology, IPSEC VPN, orSSL/TLS. Never rely exclusively onwired equivalent privacy (WEP) toprotect confidentiality and access to awireless LAN.

If WEP is used, do the following:

Use with a minimum 104-bitencryption key and 24 bit-initialization value

Use ONLY in conjunction withWiFi protected access (WPA orWPA2) technology, VPN, orSSL/TLS

Rotate shared WEP keysquarterly (or automatically if thetechnology permits)

Rotate shared WEP keyswhenever there are changes inpersonnel with access to keys

Restrict access based on mediaaccess code (MAC) address

4.1.1.a For wireless networks transmitting cardholderdata or connected to cardholder environments, verify thatappropriate encryption methodologies are used for anywireless transmissions, such as: Wi-Fi Protected Access(WPA or WPA2), IPSEC VPN, or SSL/TLS

4.1.1.b If WEP is used, verify

it is used with a minimum 104-bitencryption key and 24 bit-initializationvalue

it is used only in conjunction with Wi-FiProtected Access (WPA or WPA2)technology, VPN, or SSL/TLS

shared WEP keys are rotated at leastquarterly (or automatically if the technologyis capable)

shared WEP keys are rotated wheneverthere are changes in personnel with accessto keys

access is restricted based on MAC address

4.2Never send unencrypted PANs

by e-mail. 4.2.aVerify that an email encryption solution is used

whenever cardholder data is sent via email

4.2.b Verify the existence of a policy stating thatunencrypted PAN is not to be sent via email

4.2.c Interview 3-5 employees to verify that emailencryption software is required for emails containing PANs


23/51


Maintain a Vulnerability Management Program

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

Many vulnerabilities and malicious viruses enter the network via employees e-mail activities. Anti-virus software must beused on all systems commonly affected by viruses to protect systems from malicious software.



5.1 Deploy anti-virus software on allsystems commonly affected byviruses (particularly personalcomputers and servers)

Note: Systems commonly affected byviruses typically do not include UNIX-based operating systems ormainframes.

5.1 For a sample of system components, critical servers,and wireless access points, verify that anti-virus software isinstalled

5.1.1 Ensure that anti-virusprograms are capable of detecting,removing, and protecting againstother forms of malicious software,including spyware and adware.

5.1.1 For a sample of system components, critical servers,and wireless access points, verify that anti-virus programsdetect, remove, and protect against other malicious software,including spyware and adware

5.2 Ensure that all anti-virusmechanisms are current, activelyrunning, and capable of generatingaudit logs.

5.2 Verify that anti-virus software is current, activelyrunning, and capable of generating logs

Obtain and examine the policy and verify that iscontains requirements for updating anti-virus software

and definitions Verify that the master installation of the software is

enabled for automatic updates and periodic scans,and that a sample of system components, criticalservers, and wireless access points servers havethese features enabled

Verify that log generation is enabled and that logs areretained in accordance with company retention policy


24/51


25/51




6.3.2 Separate development, test,and production environments 6.3.2 The test/development environments are separatefrom the production environment, with access control inplace to enforce the separation

6.3.3 Separation of duties betweendevelopment, test, and productionenvironments

6.3.3 There is a separation of duties between personnelassigned to the development/test environments and thoseassigned to the production environment

6.3.4 Production data (live PANs)are not used for testing ordevelopment

6.3.4 Production data (live PANs) are not used for testingand development, or are sanitized before use

6.3.5 Removal of test data andaccounts before production systemsbecome active

6.3.5 Test data and accounts are removed before aproduction system becomes active

6.3.6 Removal of customapplication accounts, usernames,and passwords before applicationsbecome active or are released tocustomers

6.3.6 Custom application accounts, usernames and/orpasswords are removed before system goes into productionor is released to customers

6.3.7 Review of custom code prior

to release to production or customersin order to identify any potentialcoding vulnerability.

6.3.7.a Obtain and review any written or other policies to

confirm that code reviews are required and must beperformed by individuals other then originating code author

6.3.7.b Verify code reviews are conducted for new codeand after code changes

Note: This requirement applies to code reviews for customsoftware development, as part of the System DevelopmentLife Cycle (SDLC) these reviews can be conducted byinternal personnel. Custom code for web-facing applications

will be subject to additional controls as of June 30, 2008 see PCI DSS requirement 6.6 for details.

6.4 Follow change controlprocedures for all system and softwareconfiguration changes. The proceduresmust include the following:

6.4.a Obtain and examine company change-controlprocedures related to implementing security patches andsoftware modifications, and verify that the procedures requireitems 6.4.1 6.4.4 below


26/51




6.4.b For a sample of system components, critical servers,and wireless access points, examine the three most recentchanges/security patches for each system component, andtrace those changes back to related change controldocumentation. Verify that, for each change examined, thefollowing was documented according to the change controlprocedures:

6.4.1 Documentation of impact 6.4.1 Verify that documentation of customer impact isincluded in the change control documentation for eachsampled change

6.4.2 Management sign-off byappropriate parties

6.4.2 Verify that management sign-off by appropriateparties is present for each sampled change

6.4.3 Testing of operationalfunctionality

6.4.3 Verify that operational functionality testing wasperformed for each sampled change

6.4.4 Back-out procedures 6.4.4 Verify that back-out procedures are prepared foreach sampled change

6.5 Develop all web applicationsbased on secure coding guidelines.

such as the Open Web ApplicationSecurity Project Guidelines. Reviewcustom application code to identifycoding vulnerabilities. Coverprevention of common codingvulnerabilities in software developmentprocesses, to include the following:

6.5.a Obtain and review software development processes forany web-based applications. Verify that processes require

training in secure coding techniques for developers, and arebased on guidance such as the OWASP

Guidelines

(http://www.owasp.org)

6.5.b For any web-based applications, verify that processesare in place to confirm that web applications are notvulnerable to the following

6.5.1 Unvalidated input 6.5.1 Unvalidated input

6.5.2 Broken access control (forexample, malicious use of user IDs)

6.5.2 Malicious use of User IDs

6.5.3 Broken authentication andsession management (use of accountcredentials and session cookies)

6.5.3 Malicious use of account credentials and sessioncookies

6.5.4 Cross-site scripting (XSS)attacks

6.5.4 Cross-site scripting

6.5.5 Buffer overflows 6.5.5 Buffer overflows due to unvalidated input and othercauses

6.5.6 Injection flaws (for example, 6.5.6 SQL injection and other command injection flaws


27/51




structured query language (SQL)injection)

6.5.7 Improper error handling 6.5.7 Error handling flaws

6.5.8 Insecure storage 6.5.8 Insecure storage

6.5.9 Denial of service 6.5.9 Denial of service

6.5.10 Insecure configurationmanagement

6.5.10 Insecure configuration management

6.6 Ensure that all web-facing

applications are protected againstknown attacks by either of thefollowing methods:

Having all custom applicationcode reviewed for commonvulnerabilities by anorganization that specializes inapplication security

Installing an application-layer

firewall in front of web-facingapplications

Note: This method is considered a bestpractice until June 30, 2008, afterwhich it becomes a requirement.

6.6 For web-based applications, ensure that one of the

following methods are in place as follows: Verify that custom application code is periodically

reviewed by an organization that specializes inapplication security; that all coding vulnerabilities werecorrected; and that the application was re-evaluatedafter the corrections

Verify that an application-layer firewall is in place infront of web-facing applications to detect and preventweb-based attacks


28/51


Implement Strong Access Control Measures

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

This requirement ensures critical data can only be accessed by authorized personnel.

PCI DSS REQUIREMENTS TESTING PROCEDURESIN

PLACENOT INPLACE


7.1 Limit access to computingresources and cardholder

information only to those individualswhose job requires such access.

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

Access rights to privileged User IDs are restricted to leastprivileges necessary to perform job responsibilities

Assignment of privileges is based on individual personnels jobclassification and function

Requirement for an authorization form signed by managementthat specifies required privileges

Implementation of an automated access control system

7.2 Establish a mechanism for

systems with multiple users thatrestricts access based on a usersneed to know, and is set to denyall unless specifically allowed.

7.2 Examine system settings and vendor documentation to verify that

an access control system is implemented and that it includes thefollowing

Coverage of all system components

Assignment of privileges to individuals based on jobclassification and function

Default deny-all setting (some access control systems are setby default to allow-all thereby permitting access unless/until arule is written to specifically deny it)


29/51


Requirement 8: Assign a unique ID to each person with computer access.

Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems

are performed by, and can be traced to, known and authorized users.



8.1 Identify all users with aunique user name before allowingthem to access systemcomponents or cardholder data.

8.1 For a sample of user IDs, review user ID listings and verify thatall users have a unique username for access to system components orcardholder data

8.2 In addition to assigning aunique ID, employ at least one ofthe following methods toauthenticate all users:

Password

Token devices (forexample, SecureID,certificates, or public key)

Biometrics

8.2 To verify that users are authenticated using unique ID andadditional authentication (for example, a password) for access to thecardholder environment, perform the following:

Obtain and examine documentation describing theauthentication method(s) used

For each type of authentication method used and for eachtype of system component, observe an authentication to verifyauthentication is functioning consistent with documentedauthentication method(s)

8.3 Implement two-factorauthentication for remote access tothe network by employees,administrators, and third parties.Use technologies such as remoteauthentication and dial-in service(RADIUS) or terminal accesscontroller access control system(TACACS) with tokens; or VPN(based on SSL/TLS or IPSEC) withindividual certificates.

8.3 To verify that two-factor authentication is implemented for allremote network access, observe an employee (for example, anadministrator) connecting remotely to the network and verify that botha password and an additional authentication item (Smart card, tokenPIN) are required.

8.4 Encrypt all passwordsduring transmission and storageon all system components.

8.4.a For a sample of system components, critical servers, andwireless access points, examine password files to verify thatpasswords are unreadable

8.4.b For Service Providers only, observe password files to verifythat customer passwords are encrypted


30/51


31/51




users who have access to

cardholder data

8.5.8 Do not use group, shared,or generic accounts andpasswords

8.5.8.a For a sample of system components, critical servers, andwireless access points, 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 othercritical functions do not exist

Shared and generic User IDs are not used to administerwireless LANs and devices

8.5.8.b Examine password policies/procedures to verify that groupand shared passwords are explicitly prohibited

8.5.8.c Interview system administrators to verify that group andshared passwords are not distributed, even if requested

8.5.9 Change user passwordsat least every 90 days

8.5.9 For a sample of system components, critical servers, andwireless access points, obtain and inspect system configuration

settings to verify that user password parameters are set to requireusers to change passwords at least every 90 days

For Service Providers only, review internal processes andcustomer/user documentation to verify that customer passwords arerequired to change periodically and that customers are givenguidance as to when, and under what circumstances, passwordsmust change

8.5.10 Require a minimumpassword length of at least seven

characters

8.5.10 For a sample of system components, critical servers, andwireless access points, obtain and inspect system configuration

settingsto verify that password parameters are set to requirepasswords to be at least seven characters long

For Service Providers only, review internal processes andcustomer/user documentation to verify that customer passwords arerequired to meet minimum length requirements

8.5.11 Use passwordscontaining both numeric andalphabetic characters

8.5.11 For a sample of system components, critical servers, andwireless access points, obtain and inspect system configurationsettings to verify that password parameters are set to requirepasswords to contain both numeric and alphabetic characters

For Service Providers only, review internal processes and


32/51


33/51


34/51


35/51


36/51




to its contents

9.10.2 Purge, degauss, shred, orotherwise destroy electronicmedia so that cardholder datacannot be reconstructed

9.10.2 Verify that electronic media is destroyed beyond recovery byusing a military wipe program to delete files, or via degaussing orotherwise physically destroying the media

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data.

Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allowsthorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficultwithout system activity logs.


PLACENOT INPLACE


10.1 Establish a process for linking allaccess to system components (especiallyaccess done with administrative privilegessuch as root) to each individual user.

10.1 Verify through observation and interviewing thesystem administrator, that audit trails are enabled andactive, including for any connected wireless networks.

10.2 Implement automated audit trails forall system components to reconstruct thefollowing events:

10.2 Verify though interviews, examination of auditlogs, and examination of audit log settings, that thefollowing events are logged into system activity logs:

10.2.1 All individual accesses tocardholder data

10.2.1 All individual access to cardholder data

10.2.2 All actions taken by any individualwith root or administrative privileges

10.2.2 Actions taken by any individual with root oradministrative privileges

10.2.3 Access to all audit trails 10.2.3 Access to all audit trails

10.2.4 Invalid logical access attempts 10.2.4 Invalid logical access attempts

10.2 5 Use of identification andauthentication mechanisms

10.2.5 Use of identification and authenticationmechanisms

10.2.6 Initialization of the audit logs 10.2.6 Initialization of audit logs

10.2.7 Creation and deletion of system- 10.2.7 Creation and deletion of system level objects


37/51



PLACENOT INPLACE


level objects

10.3 Record at least the following audit trailentries for all system components for eachevent:

10.3 Verify through interviews and observation, foreach auditable event (from 10.2), that the audit trailcaptures the following:

10.3.1 User identification 10.3.1 User identification

10.3.2 Type of event 10.3.2 Type of event

10.3.3 Date and time 10.3.3 Date and time stamp

10.3.4 Success or failure indication 10.3.4 Success or failure indication, including thosefor wireless connections

10.3.5 Origination of event 10.3.5 Origination of event

10.3.6 Identity or name of affected data,system component, or resource

10.3.6 Identity or name of affected data, systemcomponent, or resources

10.4 Synchronize all critical system clocksand times

10.4 Obtain and review the process for acquiring anddistributing the correct time within the organization, aswell as the time-related system-parameter settings for asample of system components, critical servers, andwireless access points. Verify the following is included in

the process and implemented:

10.4.aVerify that NTP or similar technology is used fortime synchronization

10.4.b Verify that internal servers are not all receivingtime signals from external sources. [Two or threecentral time servers within the organization receiveexternal time signals [directly from a special radio, GPSsatellites, or other external sources based on

International Atomic Time and UTC (formerly GMT)],peer with each other to keep accurate time, and sharethe time with other internal servers.]

10.4.cVerify that the Network Time Protocol (NTP) isrunning the most recent version


38/51


39/51



PLACENOT INPLACE


accounting protocol (AAA) servers (for

example, RADIUS).Note: Log harvesting, parsing, and alertingtools may be used to meet compliance withRequirement 10.6

10.6.b Through observation and interviews, verify that

regular log reviews are performed for all systemcomponents

10.7 Retain audit trail history for at leastone year, with a minimum of three monthsavailable online.

10.7.a Obtain and examine security policies andprocedures and verify that they include audit logretention policies and require audit log retention for atleast one year

10.7.b Verify that audit logs are available online or on

tape for at least one year

Requirement 11: Regularly test security systems and processes.

Vulnerabilities are being discovered continually by hackers and researchers, and being introduced by new software.Systems, processes, and custom software should be tested frequently to ensure security is maintained over time and withany changes in software.


PLACENOT INPLACE


11.1 Test security controls, limitations,network connections, and restrictions annuallyto assure the ability to adequately identify andto stop any unauthorized access attempts.Use a wireless analyzer at least quarterly toidentify all wireless devices in use.

11.1.a Confirm by interviewing security personnel andexamining relevant code, documentation, andprocesses that security testing of devices is in place toassure that controls identify and stop unauthorizedaccess attempts within the cardholder environment.

11.1.b Verify that a wireless analyzer is used at leastquarterly to identify all wireless devices.

11.2 Run internal and external networkvulnerability scans at least quarterly andafterany significant change in the network (such asnew system component installations, changesin network topology, firewall rulemodifications, product upgrades).

11.2.a Inspect output from the most recent fourquarters of network, host, and application vulnerabilityscans to verify that periodic security testing of thedevices within the cardholder environment occurs.Verify that the scan process includes rescans untilclean results are obtained


40/51



PLACENOT INPLACE


Note: Quarterly external vulnerability scans

must be performed by a scan vendor qualifiedby the payment card industry. Scansconducted after network changes may beperformed by the companys internal staff.

11.2.b To verify that external scanning is occurring on

a quarterly basis in accordance with the PCI SecurityScanning Procedures, inspect output from the fourmost recent quarters of external vulnerability scans toverify that

Four quarterly scans occurred in the mostrecent 12-month period

The results of each scan satisfy the PCISecurity Scanning Procedures (for example, nourgent, critical, or high vulnerabilities)

The scans were completed by a vendorapproved to perform the PCI Security ScanningProcedures

11.3 Perform penetration testing at leastonce a year and after any significantinfrastructure or application upgrade ormodification (such as an operating systemupgrade, a sub-network added to theenvironment, or a web server added to the

environment). These penetration tests mustinclude the following

11.3 Obtain and examine the results from the mostrecent penetration test to verify that penetration testingis performed at least annually and after any significantchanges to the environment. Verify that any notedvulnerabilities were corrected. Verify that thepenetration tests include:

11.3.1 Network-layer penetration tests 11.3.1 Network-layer penetration tests

11.3.2 Application-layer penetration tests 11.3.2 Application-layer penetration tests

11.4 Use network intrusion detectionsystems, host-based intrusion detectionsystems, and intrusion prevention systems tomonitor all network traffic and alert personnelto suspected compromises. Keep all intrusiondetection and prevention engines up-to-date.

11.4.a Observe the use of network intrusion detectionsystems and/or intrusion prevention systems on thenetwork. Verify that all critical network traffic in thecardholder data environment is monitored

11.4.b Confirm IDS and/or IPS is in place to monitorand alert personnel of suspected compromises

11.4.c Examine IDS/IPS configurations and confirmIDS/IPS devices are configured, maintained, andupdated per vendor instructions to ensure optimalprotection


41/51



PLACENOT INPLACE


11.5 Deploy file integrity monitoring

software to alert personnel to unauthorizedmodification of critical system or content files;and configure the software to perform criticalfile comparisons at least weekly.

Critical files are not necessarily only thosecontaining cardholder data. For file integritymonitoring purposes, critical files are usuallythose that do not regularly change, but themodification of which could indicate a system

compromise or risk of compromise. Fileintegrity monitoring products usually comepre-configured with critical files for the relatedoperating system. Other critical files, such asthose for custom applications, must beevaluated and defined by the entity (that is themerchant or service provider)

11.5 Verify the use of file integrity monitoring

products within the cardholder data environment byobserving system settings and monitored files, as wellas reviewing results from monitoring activities

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for employees and contractors.

A strong security policy sets the security tone for the whole company and informs employees what is expected of them. Allemployees should be aware of the sensitivity of data and their responsibilities for protecting it.

PCI DSS REQUIREMENTS TESTING PROCEDURES INPLACE

NOT INPLACE


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

12.1 Examine the information security policy and verify thatthe policy is published and disseminated to all relevantsystem users (including vendors, contractors, and businesspartners)

12.1.1 Addresses all requirementsin this specification

12.1.1 Verify that the policy addresses all requirements inthis specification.

12.1.2 Includes an annual process 12.1.2 Verify that the information security policy includes


42/51


43/51


44/51


45/51



PLACENOT INPLACE


adhere to the PCI DSS

requirements

adherence to the PCI DSS requirements

12.8.2 Agreement that includes anacknowledgement that the serviceprovider is responsible for thesecurity of cardholder data theprovider possesses

12.8.2 Verify that the contract contains provisions foracknowledgement by the third party of their responsibilityfor securing cardholder data

12.9 Implement an incidentresponse plan. Be prepared torespond immediately to a system

breach.

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

12.9.1 Create the incident responseplan to be implemented in the eventof system compromise. Ensure theplan addresses, at a minimum,specific incident responseprocedures, business recovery andcontinuity procedures, data backupprocesses, roles and

responsibilities, and communicationand contact strategies (for example,informing the Acquirers and creditcard associations)

12.9.1 Verify that the Incident Response Plan and relatedprocedures include

roles, responsibilities, and communicationstrategies in the event of a compromise

coverage and responses for all critical systemcomponents

notification, at a minimum, of credit cardassociations and acquirers

strategy for business continuity post compromise reference or inclusion of incident response

procedures from card associations

analysis of legal requirements for reportingcompromises (for example, per California bill1386, notification of affected consumers is arequirement in the event of an actual orsuspected compromise, for any business withCalifornia residents in their database)

12.9.2 Test the plan at leastannually

12.9.2 Verify that the plan is tested at least annually

12.9.3 Designate specific personnelto be available on a 24/7 basis torespond to alerts

12.9.3 Verify through observation and review of policies,that there is 24/7 incident response and monitoringcoverage for any evidence of unauthorized activity, criticalIDS alerts, and/or reports of unauthorized critical system orcontent file changes

12.9.4 Provide appropriate trainingto staff with security breach

12.9.4 Verify through observation and review of policiesthat staff with security breach responsibilities are


46/51



PLACENOT INPLACE


response responsibilities periodically trained

12.9.5 Include alerts from intrusiondetection, intrusion prevention, andfile integrity monitoring systems

12.9.5 Verify through observation and review of processesthat monitoring and responding to alerts from securitysystems are included in the Incident Response Plan

12.9.6 Develop process to modifyand evolve the incident responseplan according to lessons learnedand to incorporate industrydevelopments

12.9.6 Verify through observation and review of policiesthat there is a process to modify and evolve the incidentresponse plan according to lessons learned and toincorporate industry developments

12.10 All processors and serviceproviders must maintain andimplement policies and procedures tomanage connected entities, to includethe following

12.10 Verify through observation, review of policies andprocedures, and review of supporting documentation thatthere is a process to manage connected entities byperforming the following:

12.10.1 Maintain list of connectedentities

12.10.1 Verify thata list of connected entities ismaintained

12.10.2 Ensure proper duediligence is conducted prior toconnecting an entity

12.10.2 Verify thatprocedures ensure that proper duediligence is conducted prior to connecting an entity

12.10.3 Ensure the entity is PCIDSS compliant

12.10.3 Verify thatprocedures ensure that the entity isPCI DSS compliant

12.10.4 Connect and disconnectentities by following an establishedprocess

12.10.4 Verify thatconnecting and disconnecting entitiesoccurs following an established process


47/51


Appendix A: PCI DSS Applicability for Hosting Providers (with Testing Procedures)

Requirement A.1: Hosting providers protect cardholder data environment

As referenced in Requirement 12.8, all service providers with access to cardholder data (including hosting providers) mustadhere to the PCI DSS. In addition, Requirement 2.4 states that hosting providers must protect each entitys hostedenvironment and data. Therefore, hosting providers must give special consideration to the following::

Requirements Testing Procedures In Place Not in PlaceTarget Date/Comments

A.1 Protect each entitys (that ismerchant, service provider, or otherentity) hosted environment anddata, as in A.1.1 through A.1.4:

A hosting provider must fulfill theserequirements as well as all otherrelevant sections of the PCI DSS.Note: Even though a hostingprovider may meet theserequirements, the compliance of theentity that uses the hosting provideris not guaranteed. Each entitymustcomply with the PCI DSS andvalidate compliance as applicable.

A.1 Specifically for a PCI audit of a Shared hostingProvider, to verify that Shared hosting Providers protectentities (merchants and service providers) hostedenvironment and data, select a sample of servers (MicrosoftWindows and Unix/Linux)across a representative sample ofhosted merchants and service providers, and verify A.1.1through A.1.4 below.

A.1.1 Ensure that each entity onlyhas access to own cardholder dataenvironment

A.1.1 If a shared hosting provider allows entities (forexample, merchants or service providers) to run their ownapplications, verify these application processes run using theunique ID of the entity. For example:

No entity on the system can use a shared web serveruser ID

All CGI scripts used by an entity must be created andrun as the entitys unique user ID

A.1.2 Restricteach entitys accessand privileges to own cardholder

A.1.2.a Verify the user ID of any application process is not aprivileged user (root/admin).


48/51


Requirements Testing Procedures In Place Not in PlaceTarget Date/Comments

A.1.2.b Verify each entity (merchant, service provider) has

read, write, or execute permissions only for files anddirectories it owns or for necessary system files (restrictedvia file system permissions, access control l ists, chroot,

jailshell, etc.). IMPORTANT: An entitys files may not beshared by group

A.1.2.c Verify an entitys users do not have write access toshared system binaries

A.1.2.d Verify that viewing of log entries is restricted to theowning entity

A.1.2.e To ensure each entity cannot monopolize serverresources to exploit vulnerabilities (error, race, and restartconditions, resulting in, for example, buffer overflows), verifyrestrictions are in place for the use of these systemresources:

Disk space

Bandwidth

Memory

CPUA.1.3 Ensure logging and audittrails are enabled and unique toeach entitys cardholder dataenvironment and consistent withPCI DSS Requirement 10

A.1.3.a Verify the shared hosting provider has enabledlogging as follows, for each merchant and service providerenvironment:

Logs are enabled for common third party applications

Logs are active by default

Logs are available for review by the owning entity

Log locations are clearly communicated to the owningentity

A.1.4 Enable processes to providefor timely forensic investigation inthe event of a compromise to anyhosted merchant or serviceprovider.

A.1.4 Verify the shared hosting provider has written policiesthat provide for a timely forensics investigation of relatedservers in the event of a compromise.


49/51


Appendix B Compensating Controls

Compensating Controls GeneralCompensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technicalspecification of a requirement, but has sufficiently mitigated the associated risk. See the PCI DSS Glossary for thefull definition of compensating controls.

The effectiveness of a compensating control is dependent on the specifics of the environment in which the control isimplemented, the surrounding security controls, and the configuration of the control. Companies should be awarethat a particular compensating control will not be effective in all environments. Each compensating control must be

thoroughly evaluated after implementation to ensure effectiveness. The following guidance provides compensatingcontrols when companies are unable to render cardholder data unreadable per requirement 3.4.

Compensating Controls for Requirement 3.4

For companies unable to render cardholder data unreadable (for example, by encryption) due to technicalconstraints or business limitations, compensating controls may be considered. Only companies that haveundertaken a risk analysis and have legitimate technological or documented business constraints can consider theuse of compensating controls to achieve compliance.

Companies that consider compensating controls for rendering cardholder data unreadable must understand the riskto the data posed by maintaining readable cardholder data. Generally, the controls must provide additionalprotection to mitigate any additional risk posed by maintaining readable cardholder data. The controls consideredmust be in addition to controls required in the PCI DSS, and must satisfy the Compensating Controls definition inthe PCI DSS Glossary. Compensating controls may consist of either a device or combination of devices,applications, and controls that meet all of the following conditions:

1. Provide additional segmentation/abstraction (for example, at the network-layer)2. Provide ability to restrict access to cardholder data or databases based on the following criteria:

IP address/Mac address

Application/service

User accounts/groups

Data type (packet filtering)

3. Restrict logical access to the database

Control logical access to the database independent of Active Directory or Lightweight DirectoryAccess Protocol (LDAP)

4. Prevent/detect common application or database attacks (for example, SQL injection).


50/51


Appendix C: Compensating Controls Completed Example/Worksheet

Example

1. Constraints: List constraints precluding compliance with the original requirement.

2. Objective: Define the objective of the original control; identify the objective met by the compensating control.

3. Identified Risk: Identify any additional risk posed by the lack of the original control.

4. Definition of Compensating Controls: Define the compensating controlsand explain how they address the objectives of theoriginal control and the increased risk, if any.

Company XYZ is going to require all users to log into the servers from their desktop usingthe SU command. SU allows a user to access the root account and perform actions underthe root account but is able to be logged in the su-log directory. In this way, each usersactions can be tracked through the SU account.

The objective of requiring unique logins is twofold. First, it is not considered acceptable froma security perspective to share login credentials. Secondly, shared logins makes itimpossible to state definitively that a person is responsible for a particular action.

Additional risk is introduced to the access control system by not ensuring all users have aunique ID and are able to be tracked.

Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each requirea root login. It is not possible for Company XYZ to manage the root login nor is it feasibleto log all root activity by each user.

C ti C t l W k h t


51/51


Compensating Controls Worksheet

1. Constraints: List constraints precluding compliance with the original requirement.

2. Objective: Define the objective of the original control; identify the objective met by the compensating control.

3. Identified Risk: Identify any additional risk posed by the lack of the original control.

4. Definition of Compensating Controls: Define the compensating controls and explain how they address the objectives of the

original control and the increased risk, if any.

Documents

Pci Audit Procedures v1-1