Description
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.1 April 2015 Document Changes Date October 2008 July 2009 Version 1.2 1.2.1 Description Pages To introduce PCI DSS v1.2 as “PCI DSS Requirements and Security Assessment Procedures,” eliminating redundancy between documents, and make both general and specific changes from PCI DSS Security Audit Procedures v1.1. For complete information, see PCI Data Security Standard Summary of Changes from PCI DSS Version 1.1 to 1.2. Add sentence that was incorrectly deleted between PCI DSS v1.1 and v1.2. 5 Correct “then” to “than” in testing procedures 6.3.7.a and 6.3.7.b. 32 Remove grayed-out marking for “in place” and “not in place” columns in testing procedure 6.5.b. 33 For Compensating Controls Worksheet – Completed Example, correct wording at top of page to say “Use this worksheet to define compensating controls for any requirement noted as ‘in place’ via compensating controls.” 64 October 2010 2.0 Update and implement changes from v1.2.1. See PCI DSS – Summary of Changes from PCI DSS Version 1.2.1 to 2.0. November 2013 3.0 Update from v2.0. See PCI DSS – Summary of Changes from PCI DSS Version 2.0 to 3.0. April 2015 3.1 Update from PCI DSS v3.0. See PCI DSS – Summary of Changes from PCI DSS Version 3.0 to 3.1 for details of changes. Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. Page 2 April 2015 Table of Contents Document Changes ........................................................................................................................................................................... 2 Introduction and PCI Data Security Standard Overview ................................................................................................................. 5 PCI DSS Resources .................................................................................................................................................................................................... 6 PCI DSS Applicability Information .................................................................................................................................................... 7 Relationship between PCI DSS and PA-DSS.................................................................................................................................... 9 Applicability of PCI DSS to PA-DSS Applications ....................................................................................................................................................... 9 Applicability of PCI DSS to Payment Application Vendors .......................................................................................................................................... 9 Scope of PCI DSS Requirements .................................................................................................................................................... 10 Network Segmentation .............................................................................................................................................................................................. 11 Wireless ..................................................................................................................................................................................................... 11 Use of Third-Party Service Providers / Outsourcing ................................................................................................................................................. 12 Best Practices for Implementing PCI DSS into Business-as-Usual Processes ........................................................................... 13 For Assessors: Sampling of Business Facilities/System Components ....................................................................................... 15 Compensating Controls .................................................................................................................................................................. 16 Instructions and Content for Report on Compliance .................................................................................................................... 17 PCI DSS Assessment Process ........................................................................................................................................................ 17 Detailed PCI DSS Requirements and Security Assessment Procedures ..................................................................................... 18 Build and Maintain a Secure Network and Systems ............................................................................................................................................. 19 Requirement 1: Install and maintain a firewall configuration to protect cardholder data ...................................................................................... 19 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters ...................................................... 28 Protect Cardholder Data .......................................................................................................................................................................................... 36 Requirement 3: Protect stored cardholder data .................................................................................................................................................... 36 Requirement 4: Encrypt transmission of cardholder data across open, public networks ..................................................................................... 46 Maintain a Vulnerability Management Program .................................................................................................................................................... 49 Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs ...................................................... 49 Requirement 6: Develop and maintain secure systems and applications ............................................................................................................ 52 Implement Strong Access Control Measures ........................................................................................................................................................ 64 Requirement 7: Restrict access to cardholder data by business need to know ................................................................................................... 64 Requirement 8: Identify and authenticate access to system components ............................................................................................................ 67 Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. Page 3 April 2015 ................................................................................................. 85 Requirement 10: Track and monitor all access to network resources and cardholder data ......................................................................................... 85 Requirement 11: Regularly test security systems and processes..... 115 Payment Card Industry (PCI) Data Security Standard.............................................................................................................................................................. 76 Regularly Monitor and Test Networks ....1 © 2006-2015 PCI Security Standards Council................................. 100 Requirement 12: Maintain a policy that addresses information security for all personnel.......... 110 Appendix B: Compensating Controls ..................... 92 Maintain an Information Security Policy ............................Requirement 9: Restrict physical access to cardholder data ..................... Page 4 April 2015 ........................................................................................................ All Rights Reserved.. .............. 110 Requirement A......................... ................................................................................................................................................................... LLC.................................1: Shared hosting providers must protect the cardholder data environment ..................... v3.............................................................. 113 Appendix D: Segmentation and Sampling of Business Facilities/System Components ............................................................................................................. 112 Appendix C: Compensating Controls Worksheet....................................................................................................... 100 Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers ........................................................................................ 9. combines the 12 PCI DSS requirements and corresponding testing procedures into a security assessment tool. legislation or regulatory requirements may require specific protection of personal information or other data elements (for example. The following sections provide detailed guidelines and best practices to assist entities prepare for. v3. Page 5 April 2015 . and service providers. LLC. issuers. or other legal requirements. Maintain a policy that addresses information security for all personnel This document.1 © 2006-2015 PCI Security Standards Council. Additionally. regional and sector laws and regulations. and report the results of a PCI DSS assessment. 4. government regulations.Introduction and PCI Data Security Standard Overview The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). PCI DSS comprises a minimum set of requirements for protecting account data. acquirers. conduct. Protect all systems against malware and regularly update anti-virus software or programs Develop and maintain secure systems and applications 7. and may be enhanced by additional controls and practices to further mitigate risks. It is designed for use during PCI DSS compliance assessments as part of an entity’s validation process. Protect stored cardholder data Encrypt transmission of cardholder data across open. cardholder name). 6. PCI Data Security Standard Requirements and Security Assessment Procedures. 11. 8. 2. public networks 5. All Rights Reserved. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. Below is a high-level overview of the 12 PCI DSS requirements. PCI DSS also applies to all other entities that store. Restrict access to cardholder data by business need to know Identify and authenticate access to system components Restrict physical access to cardholder data Regularly Monitor and Test Networks 10. PCI DSS applies to all entities involved in payment card processing—including merchants. Track and monitor all access to network resources and cardholder data Regularly test security systems and processes Maintain an Information Security Policy 12. as well as local. PCI Data Security Standard – High Level Overview Build and Maintain a Secure Network and Systems Protect Cardholder Data Maintain a Vulnerability Management Program Implement Strong Access Control Measures 1. Payment Card Industry (PCI) Data Security Standard. The PCI DSS Requirements and Testing Procedures begin on page 15. Install and maintain a firewall configuration to protect cardholder data Do not use vendor-supplied defaults for system passwords and other security parameters 3. PCI DSS does not supersede local or regional laws. processors. including: o PCI DSS – Summary of Changes from PCI DSS version 2. and Acronyms o Information Supplements and Guidelines o Prioritized Approach for PCI DSS o Report on Compliance (ROC) Reporting Template and Reporting Instructions o Self-assessment Questionnaires (SAQs) and SAQ Instructions and Guidelines o Attestations of Compliance (AOCs) Frequently Asked Questions (FAQs) PCI for Small Merchants website PCI training courses and informational webinars List of Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs) List of PTS approved devices and PA-DSS validated payment applications Note: Information Supplements complement the PCI DSS and identify additional considerations and recommendations for meeting PCI DSS requirements—they do not supersede.pcisecuritystandards.org) contains a number of additional resources to assist organizations with their PCI DSS assessments and validations. replace or extend the PCI DSS or any of its requirements.org for information about these and other resources. Please refer to www. including: Document Library.PCI DSS Resources The PCI Security Standards Council (PCI SSC) website (www. v3.pcisecuritystandards. Payment Card Industry (PCI) Data Security Standard. All Rights Reserved.1 © 2006-2015 PCI Security Standards Council. Abbreviations. Page 6 April 2015 . LLC.0 to 3.0 o PCI DSS Quick Reference Guide o PCI DSS and PA-DSS Glossary of Terms. and/or expiration date are stored.PCI DSS Applicability Information PCI DSS applies to all entities involved in payment card processing—including merchants. process. processed or transmitted. service code. or are otherwise present in the cardholder data environment. Some PCI DSS requirements may also be applicable to organizations that have outsourced their payment operations or 1 management of their CDE . v3. organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the account data is protected by the third party per the applicable PCI DSS requirements. Cardholder data and sensitive authentication data are defined as follows: Account Data Cardholder Data includes: Primary Account Number (PAN) Cardholder Name Sensitive Authentication Data includes: Full track data (magnetic-stripe data or equivalent on a chip) Expiration Date CAV2/CVC2/CVV2/CID Service Code PINs/PIN blocks The primary account number is the defining factor for cardholder data. 1 In accordance with individual payment brand compliance programs Payment Card Industry (PCI) Data Security Standard. and whether each data element must be protected. whether storage of each data element is permitted or prohibited. Page 7 April 2015 . This table is not exhaustive. and service providers. The table on the following page illustrates commonly used elements of cardholder and sensitive authentication data.1 © 2006-2015 PCI Security Standards Council. or transmit cardholder data and/or sensitive authentication data. but is presented to illustrate the different types of requirements that apply to each data element. processors. they must be protected in accordance with applicable PCI DSS requirements. acquirers. issuers. PCI DSS requirements apply to organizations where account data (cardholder data and/or sensitive authentication data) is stored. Additionally. processed or transmitted with the PAN. LLC. PCI DSS also applies to all other entities that store. All Rights Reserved. If cardholder name. 2 No Cannot store per Requirement 3. If PAN is stored with other elements of cardholder data.2 No Cannot store per Requirement 3.Account Data Cardholder Data Data Element Storage Permitted Render Stored Data Unreadable per Requirement 3. This applies even where there is no PAN in the environment. 2 3 4 5 Sensitive authentication data must not be stored after authorization (even if encrypted). only the PAN must be rendered unreadable according to PCI DSS Requirement 3. Full track data from the magnetic stripe. equivalent data on the chip. even if encrypted.4 apply only to PAN.4 Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No No Cannot store per Requirement 3.or four-digit value printed on the front or back of a payment card Personal identification number entered by cardholder during a card-present transaction. Page 8 April 2015 .3 and 3. and/or encrypted PIN block present within the transaction message Payment Card Industry (PCI) Data Security Standard. All Rights Reserved.1 © 2006-2015 PCI Security Standards Council. and any related usage and protection requirements. for how long. v3. Sensitive authentication data must not be stored after authorization. LLC.2 3 Sensitive Authentication 2 Data Full Track Data CAV2/CVC2/CVV2/CID PIN/PIN Block 4 5 PCI DSS Requirements 3. Organizations should contact their acquirer or the individual payment brands directly to understand whether SAD is permitted to be stored prior to authorization. or elsewhere The three.4. Applicability of PCI DSS to Payment Application Vendors PCI DSS may apply to payment application vendors if the vendor stores.1 © 2006-2015 PCI Security Standards Council. The PA-DSS details the requirements a payment application must meet in order to facilitate a customer’s PCI DSS compliance. All Rights Reserved. Secure payment applications. The PCI DSS assessment should verify the PA-DSS validated payment application is properly configured and securely implemented per PCI DSS requirements. as the application may no longer be representative of the version that was validated to PA-DSS. Payment Card Industry (PCI) Data Security Standard. including applications that have been validated to PA-DSS. CID. and PINs and PIN blocks. To determine whether PA-DSS applies to a given payment application. when implemented in a PCI DSS-compliant environment. Page 9 April 2015 . processes. will minimize the potential for security breaches leading to compromises of PAN. card verification codes and values (CAV2. If the payment application has undergone any customization. v3. full track data.Relationship between PCI DSS and PA-DSS Applicability of PCI DSS to PA-DSS Applications Use of a Payment Application Data Security Standard (PA-DSS) compliant application by itself does not make an entity PCI DSS compliant. or has access to their customers’ cardholder data (for example. in the role of a service provider). or transmit cardholder data are in scope for an entity’s PCI DSS assessment. please refer to the PA-DSS Program Guide. All applications that store. along with the damaging fraud resulting from these breaches. a more in-depth review will be required during the PCI DSS assessment. The PA-DSS requirements are derived from the PCI DSS Requirements and Security Assessment Procedures (defined in this document). CVV2). CVC2. process. LLC. or transmits cardholder data.org. since that application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide provided by the payment application vendor. which can be found at www.pcisecuritystandards. Any other component or device located within or connected to the CDE. application. mail. Examples of system components include but are not limited to the following: Systems that provide security services (for example. The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity. process . wireless access points. Payment Card Industry (PCI) Data Security Standard. processes and technologies that store. virtual applications/desktops. All Rights Reserved. The entity retains documentation that shows how PCI DSS scope was determined. and Domain Name System (DNS). virtual appliances. At least annually and prior to the annual assessment. Applications including all purchased and custom applications. could impact the CDE (for example. name resolution or web redirection servers) the CDE. servers. or may impact the security of (for example. and identify all systems that are connected to or. internal firewalls). and applications. authentication servers). Server types including but not limited to web. Page 10 April 2015 . the results may be a diagram or an inventory of cardholder data locations). Once all locations of cardholder data are identified and documented. computing devices. To confirm the accuracy of the defined CDE. “System components” include network devices. and other security appliances. the entity uses the results to verify that PCI DSS scope is appropriate (for example. Internet) applications. Virtualization components such as virtual machines. authentication servers) to ensure they are included in the PCI DSS scope. such data should be securely deleted. Network components including but not limited to firewalls. including internal and external (for example. virtual switches/routers. or transmit cardholder data or sensitive authentication data. authentication. If the entity identifies data that is not currently included in the CDE. database. network appliances. v3. or the CDE redefined to include this data. and hypervisors. migrated into the currently defined CDE. facilitate segmentation (for example. proxy. switches. LLC. For each PCI DSS assessment. perform the following: The assessed entity identifies and documents the existence of all cardholder data in their environment. if compromised. routers. to verify that no cardholder data exists outside of the currently defined CDE. The first step of a PCI DSS assessment is to accurately determine the scope of the review.Scope of PCI DSS Requirements The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data.1 © 2006-2015 PCI Security Standards Council. The cardholder data environment (CDE) is comprised of people. Network Time Protocol (NTP). the assessor is required to validate that the scope of the assessment is accurately defined and documented. Network Segmentation Network segmentation of.1. process. 2. an entity should carefully evaluate the need for the technology against the risk. the technologies deployed. it is strongly recommended as a method that may reduce: The scope of the PCI DSS assessment The cost of the PCI DSS assessment The cost and difficulty of implementing and maintaining PCI DSS controls The risk to an organization (reduced by consolidating cardholder data into fewer. Documenting cardholder data flows via a dataflow diagram helps fully understand all cardholder data flows and ensures that any network segmentation is effective at isolating the cardholder data environment. the assessor must verify that the segmentation is adequate to reduce the scope of the assessment. processing or transmission of cardholder data. Wireless If wireless technology is used to store. or transmit cardholder data from those that do not. Payment Card Industry (PCI) Data Security Standard. such as properly configured internal network firewalls. and 4. routers with strong access control lists. the cardholder data environment from the remainder of an entity’s network is not a PCI DSS requirement. or connected to the cardholder data environment. At a high level. LLC. and consolidation of necessary data. or transmit cardholder data (for example. adequate network segmentation isolates systems that store. more controlled locations) Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment.1 © 2006-2015 PCI Security Standards Council. the PCI DSS requirements and testing procedures for wireless environments apply and must be performed (for example. the adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number of factors. All Rights Reserved. may require reengineering of long-standing business practices. or if a wireless local area network (WLAN) is part of. and other controls that may be implemented. Before wireless technology is implemented.1.2. or other technologies that restrict access to a particular segment of a network. such that even if the out-of-scope system component was compromised it could not impact the security of the CDE. point-of-sale transactions. a system component must be properly isolated (segmented) from the CDE.1). However. v3. Restricting cardholder data to as few locations as possible by elimination of unnecessary data. Requirements 1. An important prerequisite to reduce the scope of the cardholder data environment is a clear understanding of business needs and processes related to the storage. Network segmentation can be achieved through a number of physical or logical means.1. To be considered out of scope for PCI DSS. or isolating (segmenting). Appendix D: Segmentation and Sampling of Business Facilities/System Components provides more information on the effect of network segmentation and sampling on the scope of a PCI DSS assessment. such as a given network's configuration. Page 11 April 2015 . However. If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment.3. Consider deploying wireless technology only for nonsensitive data transmission. process. “line-busting”). For example. service providers must undergo assessments upon request of their customers and/or participate in each of their customer’s PCI DSS reviews. Service providers are responsible for demonstrating their PCI DSS compliance. process. Service providers should contact their acquirer and/or payment brand to determine the appropriate compliance validation. Parties should clearly identify the services and system components which are included in the scope of the service provider’s PCI DSS assessment. If so. v3. Refer to Requirement 12. or transmit cardholder data on their behalf. Additionally.Use of Third-Party Service Providers / Outsourcing A service provider or merchant may use a third-party service provider to store. or 2) Multiple. and any requirements which are the responsibility of the service provider’s customers to include in their own PCI DSS reviews. There are two options for third-party service providers to validate compliance: 1) Annual assessment: Service providers can undergo an annual PCI DSS assessment(s) on their own and provide evidence to their customers to demonstrate their compliance. on-demand assessments: If they do not undergo their own annual PCI DSS assessments. and/or servers. LLC. providing the AOC and/or relevant sections of the service provider’s ROC (redacted to protect any confidential information) could help provide all or some of the information. Payment Card Industry (PCI) Data Security Standard. merchants and service providers must manage and monitor the PCI DSS compliance of all associated third-party service providers with access to cardholder data. or to manage components such as routers. with the results of each review provided to the respective customer(s) If the third party undergoes their own PCI DSS assessment.8 in this document for details. The specific type of evidence provided by the service provider to their customers will depend on the agreements/contracts in place between those parties. there may be an impact on the security of the cardholder data environment. they should provide sufficient evidence to their customers to verify that the scope of the service provider’s PCI DSS assessment covered the services applicable to the customer and that the relevant PCI DSS requirements were examined and determined to be in place. firewalls. For example. the specific PCI DSS requirements covered by the service provider. All Rights Reserved. databases. and may be required to do so by the payment brands. physical security. a managed hosting provider should clearly define which of their IP addresses are scanned as part of their quarterly vulnerability scan process and which IP addresses are their customer’s responsibility to include in their own quarterly scans.1 © 2006-2015 PCI Security Standards Council. Page 12 April 2015 . All Rights Reserved. Reviewing changes to the environment (for example. etc. etc.. and would need to be added to the quarterly vulnerability scan schedule). etc. Payment Card Industry (PCI) Data Security Standard. and perform the following: Determine the potential impact to PCI DSS scope (for example. to verify the control is operating effectively 3. Monitoring of security controls—such as firewalls. PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity’s overall security strategy. file-integrity monitoring (FIM). Identify PCI DSS requirements applicable to systems and networks affected by the changes (for example. intrusion-detection systems/intrusion-prevention systems (IDS/IPS).. and so on. v3. access controls.1 © 2006-2015 PCI Security Standards Council. These reviews can also be used to verify that appropriate evidence is being maintained—for example. 2. firewall reviews. to verify that PCI DSS requirements continue to be in place—for example. it would need to be configured per system configuration standards. addition of new systems. including FIM. vulnerability scan reports. patches. audit logs.Best Practices for Implementing PCI DSS into Business-as-Usual Processes To ensure security controls continue to be properly implemented. audit logging. and maintain their PCI DSS compliant environment in between PCI DSS assessments. LLC. Processes to respond to security control failures should include: Restoring the security control Identifying the cause of failure Identifying and addressing any security issues that arose during the failure of the security control Implementing mitigation (such as process or technical controls) to prevent the cause of the failure recurring Resuming monitoring of the security control. Examples of how to incorporate PCI DSS into BAU activities include but are not limited to: 1. patches and AV are up to date. a company merger or acquisition) resulting in formal review of the impact to PCI DSS scope and requirements. audit logs are being reviewed. Performing periodic reviews and communications to confirm that PCI DSS requirements continue to be in place and personnel are following secure processes. if a new system is in scope for PCI DSS. and include reviewing system components (or samples of system components). anti-virus. perhaps with enhanced monitoring for a period of time. Update PCI DSS scope and implement security controls as appropriate. including retail outlets. changes in system or network configurations) prior to completion of the change. data centers.—to assist the entity’s preparation for their next compliance assessment. a new firewall rule that permits connectivity between a system in the CDE and another system could bring additional systems or networks into scope for PCI DSS). Ensuring that all failures in security controls are detected and responded to in a timely manner. 4. Page 13 April 2015 .—to ensure they are operating effectively and as intended. configuration standards have been applied. This enables an entity to monitor the effectiveness of their security controls on an ongoing basis. 5. Changes to organizational structure (for example. These periodic reviews should cover all facilities and locations. etc. AV. The frequency of periodic reviews should be determined by the entity as appropriate for the size and complexity of their environment. If it is discovered that technologies are no longer supported by the vendor or cannot meet the entity’s security needs. administration and security operations). In addition to the above practices. All Rights Reserved. In environments where one individual performs multiple roles (for example. the entity should prepare a remediation plan. as necessary. up to and including replacement of the technology. and they do not replace or extend any PCI DSS requirement. Reviewing hardware and software technologies at least annually to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements. Page 14 April 2015 . Payment Card Industry (PCI) Data Security Standard.6. LLC. including PCI DSS. Note: These best practices for implementing PCI DSS into business-as-usual processes are provided as recommendations and guidance only.1 © 2006-2015 PCI Security Standards Council. v3. duties may be assigned such that no single individual has end-to-end control of a process without an independent checkpoint. For example. responsibility for configuration and responsibility for approving changes could be assigned to separate individuals. organizations may also wish to consider implementing separation of duties for their security functions so that security and/or audit functions are separated from operational functions. Examples of business facilities include but are not limited to: corporate offices. processing facilities. data-transfer servers). the sample must be larger for the assessor to be assured that each business facility/system component has implemented PCI DSS requirements appropriately. the sample can be smaller than if there are no standard processes/controls in place. the sample must be large enough to include business facilities/system components secured with each type of process. the assessor may independently select representative samples of business facilities/system components in order to assess the entity’s compliance with PCI DSS requirements. mainframe systems running legacy card processing applications.1 © 2006-2015 PCI Security Standards Council. Payment Card Industry (PCI) Data Security Standard. centralized PCI DSS security and operational processes and controls in place that ensure consistency and that each business facility/system component must follow. stores. Windows 7 or Solaris 10). data centers. The assessor must verify that the standardized. LLC. While it is acceptable for an assessor to sample business facilities/system components as part of their review of an entity’s PCI DSS compliance. the sample should still include a variety of applications (for example. If there is more than one type of standard security and/or operational process in place (for example. centralized controls are implemented and working effectively. These samples must be defined first for business facilities and then for system components within each selected business facility. the assessor may define a sample at a business facility to include Sun servers running Apache. All Rights Reserved. Samples must be a representative selection of all of the types and locations of business facilities. Similarly. it is not acceptable for an entity to apply PCI DSS requirements to only a sample of their environment (for example. for different types of business facilities/system components). web servers. v3. requirements for quarterly vulnerability scans apply to all system components). and Linux Servers running MySQL. database servers. as well as all of the types of system components within selected business facilities. and applications that are applicable to the area under review. Samples must be sufficiently large to provide the assessor with assurance that controls are implemented as expected. After considering the overall scope and complexity of the environment being assessed. data-transfer servers running HP-UX. for each business facility selected. Page 15 April 2015 . If there are no standard PCI DSS processes/controls in place and each business facility/system component is managed through nonstandard processes. For example. functions. Windows servers running Oracle. As an example. and other facility types in different locations. The sample must be large enough to provide the assessor with reasonable assurance that all business facilities/system components are configured per the standard processes. Sampling should include system components within each selected business facility. it is not acceptable for an assessor to only review a sample of PCI DSS requirements for compliance. assessors should consider the following: If there are standardized. When independently selecting samples of business facilities/system components. franchise locations.For Assessors: Sampling of Business Facilities/System Components Sampling is an option for assessors to facilitate the assessment process where there are large numbers of business facilities and/or system components. include a variety of operating systems. If all applications run from a single version of an OS (for example. Page 16 April 2015 . Please also refer to: Appendix D: Segmentation and Sampling of Business Facilities/System Components.1 © 2006-2015 PCI Security Standards Council. Samples of system components must include every type and combination that is in use. the Compensating Controls Worksheet (Appendix C) must be completed. If sampling is to be used. For each instance where sampling is used. the assessor must: Document the rationale behind the sampling technique and sample size. reviewed and validated by the assessor and included with the Report on Compliance submission. For each and every compensating control. and Explain how the sample is appropriate and representative of the overall population. LLC. different samples of business facilities and system components must be selected for each assessment. where applications are sampled. Document and validate the standardized PCI DSS processes and controls used to determine sample size. the sample must include all versions and platforms for each type of application. See the above-mentioned Appendices B and C for more details on “compensating controls. Assessors must revalidate the sampling rationale for each assessment. v3. Compensating Controls On an annual basis. per Appendix B: Compensating Controls and Appendix C: Compensating Controls Worksheet. Additionally.” Payment Card Industry (PCI) Data Security Standard. any compensating controls must be documented. All Rights Reserved. compensating control results should be documented in the ROC in the corresponding PCI DSS requirement section. For example. 2. Complete the applicable report for the assessment (i. Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)).Instructions and Content for Report on Compliance Instructions and content for the Report on Compliance (ROC) are now provided in the PCI DSS ROC Reporting Template. Attestations of Compliance are available on the PCI SSC website. The PCI DSS ROC Reporting Template must be used as the template for creating the Report on Compliance. PCI DSS Assessment Process 1.e. v3. along with any other requested documentation—such as ASV scan reports— to the acquirer (for merchants) or to the payment brand or other requester (for service providers). perform remediation to address requirements that are not in place. If required.. and provide an updated report. 4. All Rights Reserved. LLC. Complete the Attestation of Compliance for Service Providers or Merchants. Page 17 April 2015 . Contact each payment brand or the acquirer to determine reporting requirements and instructions. 6. Payment Card Industry (PCI) Data Security Standard. Confirm the scope of the PCI DSS assessment. as applicable. and the Attestation of Compliance. in its entirety. including documentation of all compensating controls. according to the applicable PCI guidance and instructions.1 © 2006-2015 PCI Security Standards Council. 5. following the testing procedures for each requirement. The assessed entity should follow each payment brand’s respective reporting requirements to ensure each payment brand acknowledges the entity’s compliance status. Submit the SAQ or ROC. Perform the PCI DSS assessment of the environment. 3. PCI DSS compliance is validated against these requirements. refer to the PCI DSS SAQ Instructions and Guidelines. Testing Procedures – This column shows processes to be followed by the assessor to validate that PCI DSS requirements have been met and are “in place. the assessor will then reassess to validate that the remediation is completed and that all requirements are satisfied. refer to the PCI DSS Attestations of Compliance. and is intended to assist understanding of the intent of each requirement. This column contains guidance only. After any open or not-in-place items are addressed by the entity. Payment Card Industry (PCI) Data Security Standard. All Rights Reserved. Page 18 April 2015 . Please refer to the following resources (available on the PCI SSC website) to document the PCI DSS assessment: For instructions on completing reports on compliance (ROC). For instructions on completing self-assessment questionnaires (SAQ). Note: PCI DSS requirements are not considered to be in place if controls are not yet implemented or are scheduled to be completed at a future date. For instructions on submitting PCI DSS compliance validation reports.1 © 2006-2015 PCI Security Standards Council. LLC. The guidance in this column does not replace or extend the PCI DSS Requirements and Testing Procedures.Detailed PCI DSS Requirements and Security Assessment Procedures The following defines the column headings for the PCI DSS Requirements and Security Assessment Procedures: PCI DSS Requirements – This column defines the Data Security Standard requirements. v3.” Guidance – This column describes the intent or security objective behind each of the PCI DSS requirements. refer to the PCI DSS ROC Reporting Template. 1.a Examine documented procedures to verify there is a formal process for testing and approval of all: Network connections and Changes to firewall and router configurations 1.b For a sample of network connections. router. or via other sources. as well as traffic into and out of more sensitive areas within an entity’s internal trusted networks.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations 1.1. All systems must be protected from unauthorized access from untrusted networks. as long as they meet the minimum requirements for firewalls as defined in Requirement 1. v3. Without formal approval and testing of changes. LLC. interview responsible personnel and examine records to verify that network connections were approved and tested.1 Inspect the firewall and router configuration standards and other documentation specified below and verify that standards are complete and implemented as follows: Guidance Firewalls and routers are key components of the architecture that controls entry to and exit from the network. PCI DSS Requirements 1. A documented and implemented process for approving and testing all connections and changes to the firewalls and routers will help prevent security problems caused by misconfiguration of the network. Payment Card Industry (PCI) Data Security Standard. Configuration standards and procedures will help to ensure that the organization’s first line of defense in the protection of its data remains strong.1. Often. these devices must be included within the scope and assessment of Requirement 1.1 © 2006-2015 PCI Security Standards Council. 1. employee Internet access through desktop browsers.Build and Maintain a Secure Network and Systems Requirement 1: Install and maintain a firewall configuration to protect cardholder data Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (external).1. All Rights Reserved. seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. or firewall. Other system components may provide firewall functionality. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. Where other system components are used within the cardholder data environment to provide firewall functionality. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network. whether entering the system via the Internet as e-commerce. records of the changes might not be updated. which could lead to inconsistencies between network documentation and the actual configuration. employee e-mail access.1. Firewalls are a key protection mechanism for any computer network. via wireless networks. Page 19 April 2015 . dedicated connections such as business-to-business connections.1 Establish and implement firewall and router configuration standards that include the following: Testing Procedures 1. These devices are software or hardware devices that block unwanted access and manage authorized access into and out of the network. processed.1.2. Shows all cardholder data flows across systems and networks. and between any DMZ and the internal network.1.b Verify that the current network diagram is consistent with the firewall configuration standards. 1. Cardholder data-flow diagrams identify the location of all cardholder data that is stored. All Rights Reserved.1.4.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone 1. v3. Without current network diagrams. Using a firewall on every Internet connection coming into (and out of) the network.4. and identify the location of all network devices. or transmitted within the network. per the documented configuration standards and network diagrams. 1. Network diagrams describe how networks are configured. compare to the change records. LLC.1. Payment Card Industry (PCI) Data Security Standard.1.1.1.1. Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment.2. including any wireless networks 1.3 Examine data-flow diagram and interview personnel to verify the diagram: 1.4. devices could be overlooked and be unknowingly left out of the security controls implemented for PCI DSS and thus be vulnerable to compromise.b Interview responsible personnel to verify that the diagram is kept current. Page 20 April 2015 . by showing how cardholder data flows across networks and between individual systems and devices. 1. 1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks.a Examine the firewall configuration standards and verify that they include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone. including any wireless networks.c Observe network configurations to verify that a firewall is in place at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone.1 © 2006-2015 PCI Security Standards Council. allows the organization to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection. Is kept current and updated as needed upon changes to the environment. and interview responsible personnel to verify the changes were approved and tested.1.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to cardholder data.1. 1.c Identify a sample of actual changes made to firewall and router configurations.3 Current diagram that shows all cardholder data flows across systems and networks 1.PCI DSS Requirements Testing Procedures Guidance 1. This description of roles and assignment of responsibilities ensures that personnel are aware of who is responsible for the security of all network components. including business justification for each—for example.5 Description of groups. and SNMP v1 and v2.a Verify that firewall and router configuration standards include a description of groups. protocol. and ports they don't use (even though the vulnerabilities are still present). and ports are disabled or removed. roles. 1. All Rights Reserved.a Verify that firewall and router configuration standards include a documented list of all services. If these insecure services. hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL). or ports include but are not limited to FTP. and Virtual Private Network (VPN) protocols. If roles and responsibilities are not formally assigned. and ports allowed. 1. Compromises often happen due to unused or insecure service and ports. protocols.6. or ports are necessary for business.1. POP3. 1. the use of the protocol should be justified.1.1 © 2006-2015 PCI Security Standards Council. Page 21 April 2015 . By clearly defining and documenting the services. protocols.5. and verify that security features are documented for each service. the risk posed by use of these protocols should be clearly understood and accepted by the organization. Telnet. and port. they should be disabled or removed. protocols.c Examine firewall and router configurations to verify that the documented security features are implemented for each insecure service.1. IMAP. and responsibilities for management of network components.PCI DSS Requirements Testing Procedures Guidance 1. Examples of insecure services. and ports that are necessary for business. protocols. If insecure services. Secure Shell (SSH). protocols and ports. protocols. protocols. LLC. 1.1. devices could be left unmanaged. and ports allowed. Payment Card Industry (PCI) Data Security Standard.6.5. since these often have known vulnerabilities and many organizations don’t patch vulnerabilities for the services.6 Documentation and business justification for use of all services. protocols. v3. roles. and the security features that allow these protocols to be used securely should be documented and implemented. including documentation of security features implemented for those protocols considered to be insecure. and responsibilities for management of network components 1.1. and that those assigned to manage components are aware of their responsibilities.6. organizations can ensure that all other services. 1. protocols.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.b Identify insecure services. or ports are not necessary for business.1.1. PCI DSS Requirements Testing Procedures 1.1.7 Requirement to review firewall and router rule sets at least every six months 1.1.7.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months. 1.1.7.b Examine documentation relating to rule set reviews and interview responsible personnel to verify that the rule sets are reviewed at least every six months. 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. 1.2 Examine firewall and router configurations and perform the following to verify that connections are restricted between untrusted networks and system components in the cardholder data environment: Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage. 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic. Guidance 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 the documented business justifications. Organizations with a high volume of changes to firewall and router rule sets may wish to consider performing reviews more frequently, to ensure that the rule sets continue to meet the needs of the business. It is essential to install network protection between the internal, trusted network and any untrusted network that is external and/or out of the entity’s ability to control or manage. Failure to implement this measure correctly results in the entity being vulnerable to unauthorized access by malicious individuals or software. For firewall functionality to be effective, it must be properly configured to control and/or limit traffic into and out of the entity’s network. 1.2.1.a Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment. 1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment. 1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement. Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. This requirement is intended to prevent malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within your network out to an untrusted server). Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out. Page 22 April 2015 PCI DSS Requirements 1.2.2 Secure and synchronize router configuration files. Testing Procedures 1.2.2.a Examine router configuration files to verify they are secured from unauthorized access. 1.2.2.b Examine router configurations to verify they are synchronized—for example, the running (or active) configuration matches the start-up configuration (used when machines are booted). 1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment. 1.2.3.a Examine firewall and router configurations to verify that there are perimeter firewalls installed between all wireless networks and the cardholder data environment. 1.2.3.b Verify that the firewalls deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment. Guidance While the running (or active) router configuration files include the current, secure settings, the startup files (which are used when routers are restarted or booted) must be updated with the same secure settings to ensure these settings are applied when the start-up configuration is run. Because they only run occasionally, start-up configuration files are often forgotten and are not updated. When a router re-starts and loads a start-up configuration that has not been updated with the same secure settings as those in the running configuration, it may result in weaker rules that allow malicious individuals into the network. 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 the entity’s knowledge, a malicious individual could easily and “invisibly” enter the network. If firewalls do not restrict access from wireless networks into the CDE, malicious individuals that gain unauthorized access to the wireless network can easily connect to the CDE 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, guest networks, warehouse environments, etc. Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. Page 23 April 2015 PCI DSS Requirements Testing Procedures Guidance 1.3 Examine firewall and router configurations—including 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 segment—and perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment: A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise. 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports. 1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports. The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server). 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. 1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ. This functionality is intended to prevent malicious individuals from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner. 1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment. 1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment. Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, as well as inspection and blocking of unwanted 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 Prohibit direct public access between the Internet and any system component in the cardholder data environment. Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. Page 24 April 2015 authorized response (since it retains each connection’s status) or is malicious traffic trying to trick the firewall into allowing the connection. among other things.4 Examine firewall and router configurations to verify that anti-spoofing measures are implemented. By maintaining the “state.5 Examine firewall and router configurations to verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.” the firewall knows whether an apparent response to a previous connection is actually a valid. 1.) A firewall that performs stateful packet inspection maintains the "state" (or the status) for each connection through the firewall. for example internal addresses cannot pass from the Internet into the DMZ. v3. 1. also known as dynamic packet filtering. Page 25 April 2015 .4 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.3. 1.) 1. and/or blocking of content). Connections should be inspected to restrict traffic to only authorized communications (for example by restricting source/destination addresses/ports. 1. Malicious individuals will often try to spoof (or imitate) the sending IP address so that the target system believes the packet is from a trusted source. Normally a packet contains the IP address of the computer that originally sent it so other computers in the network know where the packet came from. LLC. Payment Card Industry (PCI) Data Security Standard. only “established” connections are allowed into the network. ensure packets are not “spoofed” to look like they are coming from an organization’s own internal network. All traffic outbound from the cardholder data environment should be evaluated to ensure that it follows established.3.3. and only if they are associated with a previously established session.PCI DSS Requirements Testing Procedures Guidance 1. block traffic originating from the Internet with an internal source address.3.6 Implement stateful inspection.1 © 2006-2015 PCI Security Standards Council.) Filtering packets coming into the network helps to.6 Examine firewall and router configurations to verify that the firewall performs stateful inspection (dynamic packet filtering). (For example.3. All Rights Reserved. (Only established connections should be allowed in. (That is.3. authorized rules. Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used.3.b Interview personnel and examine documentation to verify that any disclosure of private IP addresses and routing information to external entities is authorized. segregated from the DMZ and other untrusted networks. the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks. Note: This requirement is not intended to apply to temporary storage of cardholder data in volatile memory. it is easier for an external attacker to access this information. and using that information to access the network.3. 1. Page 26 April 2015 . v3. 1. 1. Note: Methods to obscure IP addressing may include. All Rights Reserved. For example.1 © 2006-2015 PCI Security Standards Council. segregated from the DMZ and other untrusted networks.PCI DSS Requirements Testing Procedures 1. since there are fewer layers to penetrate.8 Do not disclose private IP addresses and routing information to unauthorized parties.a Examine firewall and router configurations to verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet.3.3. Removal or filtering of route advertisements for private networks that employ registered addressing. Guidance If cardholder data is located within the DMZ. Payment Card Industry (PCI) Data Security Standard.7 Examine firewall and router configurations to verify that system components that store cardholder data are on an internal network zone.7 Place system components that store cardholder data (such as a database) in an internal network zone. Internal use of RFC1918 address space instead of registered addresses. LLC. Securing system components that store cardholder data in an internal network zone that is segregated from the DMZ and other untrusted networks by a firewall can prevent unauthorized network traffic from reaching the system component. but are not limited to: Network Address Translation (NAT) Placing servers containing cardholder data behind proxy servers/firewalls.8.8. 1. Restricting the disclosure of internal or private IP addresses is essential to prevent a hacker “learning” the IP addresses of the internal network.3. 4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example. Personal firewall software is installed and configured per the organization’s specific configuration settings.4. Specific configuration settings are defined for personal firewall software. Personal firewall software is actively running. Personal firewall software is configured to actively run. and which are also used to access the network.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing firewalls are: Documented.a Examine policies and configuration standards to verify: 1. Systems that cannot be managed by corporate policy introduce weaknesses to the perimeter and provide opportunities that malicious individuals may exploit. 1. Personal firewall software is not alterable by users of mobile and/or employee-owned devices.PCI DSS Requirements 1. Personal firewall software is not alterable by users of mobile and/or employee-owned devices. LLC. v3.b Inspect a sample of mobile and/or employee-owned devices to verify that: 1. Personnel need to be aware of and following security policies and operational procedures to ensure firewalls and routers are continuously managed to prevent unauthorized access to the network. and Known to all affected parties. In use. which could use the device to gain access the organization’s systems and data once the device is re-connected to the network. Payment Card Industry (PCI) Data Security Standard. Personal firewall software is configured to not be alterable by users of mobile and/or employee-owned devices. The specific firewall configuration settings are determined by the organization. Page 27 April 2015 . Allowing untrusted systems to connect to an organization’s network could result in access being granted to attackers and other malicious users. Guidance Portable computing devices that are allowed to connect to the Internet from outside the corporate firewall are more vulnerable to Internet-based threats.1 © 2006-2015 PCI Security Standards Council. Personal firewall software is required for all mobile and/or employee-owned devices that connect to the Internet when outside the network (for example. and known to all affected parties. Firewall configurations include: Specific configuration settings are defined for personal firewall software.4. Use of a personal firewall helps to protect devices from Internet-based attacks. Note: The intent of this requirement applies to employee-owned and company-owned computers. laptops used by employees). All Rights Reserved. Personal firewall software is actively running. laptops used by employees). and which are also used to access the network. Testing Procedures 1. in use.5 Ensure that security policies and operational procedures for managing firewalls are documented. a Choose a sample of system components. and passwords to compromise operating system software. Simple Network Management Protocol (SNMP) community strings. POS terminals. systems.). Testing Procedures 2. account names. verify that all unnecessary default accounts (including accounts used by operating systems. security software. application and system accounts. Even if a default account is not intended to be used. etc. SNMP.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. (Use vendor manuals and sources on the Internet to find vendor-supplied accounts/passwords. POS terminals. etc. SNMP.Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems.) are changed before a system is installed on the network.) are removed or disabled before a system is installed on the network.1. etc.1. Guidance Malicious individuals (external and internal to an organization) often use vendor default settings. Simple Network Management Protocol (SNMP) community strings. Payment Card Industry (PCI) Data Security Standard. PCI DSS Requirements 2. and Simple Network Management Protocol (SNMP) community strings) have been changed. point-of-sale (POS) terminals. LLC. All Rights Reserved.b For the sample of system components.1 © 2006-2015 PCI Security Standards Council. 2. POS terminals. applications.) are removed or disabled.c Interview personnel and examine supporting documentation to verify that: All vendor defaults (including default passwords on operating systems. This applies to ALL default passwords.) 2. including but not limited to those used by operating systems. changing these settings will leave systems less vulnerable to attack. security software. v3. to verify that ALL default passwords (including those on operating systems. Page 28 April 2015 . Because these default settings are often published and are well known in hacker communities. POS terminals. application and system accounts. These passwords and settings are well known by hacker communities and are easily determined via public information. systems. software providing security services. and attempt to log on (with system administrator help) to the devices and applications using default vendor-supplied accounts and passwords. changing the default password to a strong unique password and then disabling the account will prevent a malicious individual from re-enabling the account and gaining access with the default password. applications. and the systems on which they are installed. Unnecessary default accounts (including accounts used by operating systems. applications. software that provides security services. etc. software that provides security services.1. application and system accounts. to verify: Default SNMP community strings are not used. Default SNMP community strings are required to be changed upon installation.1.e Examine vendor documentation and observe wireless configuration settings to verify other securityrelated wireless vendor defaults were changed. LLC. Page 29 April 2015 .a Interview responsible personnel and examine supporting documentation to verify that: Encryption keys were changed from default at installation Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions. the key-exchange protocol for older versions of 802.b Interview personnel and examine policies and procedures to verify: Guidance If wireless networks are not implemented with sufficient security configurations (including changing default settings). including but not limited to default wireless encryption keys. Default passwords/phrases on access points are required to be changed upon installation. Testing Procedures 2.1.1.1. 2.1. Firmware for devices should be updated to support more secure protocols. wireless sniffers can eavesdrop on the traffic.1. Default passwords/passphrases on access points are not used.1.11x encryption (Wired Equivalent Privacy. change ALL wireless vendor defaults at installation. passwords. easily capture data and passwords. 2.1. and SNMP community strings. Payment Card Industry (PCI) Data Security Standard. with system administrator help.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data. All Rights Reserved. v3.PCI DSS Requirements 2. 2.1.d Examine vendor documentation and observe wireless configuration settings to verify firmware on wireless devices is updated to support strong encryption for: Authentication over wireless networks Transmission over wireless networks.1. and easily enter and attack the network. or WEP) has been broken and can render the encryption useless. 2.1.1 © 2006-2015 PCI Security Standards Council.c Examine vendor documentation and login to wireless devices. In addition. if applicable. but are not limited to: Center for Internet Security (CIS) International Organization for Standardization (ISO) SysAdmin Audit Network Security (SANS) Institute National Institute of Standards Technology (NIST).2. file systems. etc. a number of security organizations have established system-hardening guidelines and recommendations.sans.2.. but are not limited to: www.org. which advise how to correct these weaknesses. v3.gov. www. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include.a Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industryaccepted hardening standards.2 Develop configuration standards for all system components. Payment Card Industry (PCI) Data Security Standard.d Verify that system configuration standards include the following procedures for all types of system components: Changing of all vendor-supplied defaults and elimination of unnecessary default accounts Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server Enabling only necessary services. 2. such as scripts.1 © 2006-2015 PCI Security Standards Council. as defined in Requirement 6.iso. 2.PCI DSS Requirements Testing Procedures Guidance 2. There are known weaknesses with many operating systems. Examples of sources for guidance on configuration standards include. drivers.1. System configuration standards must be kept up to date to ensure that newly identified weaknesses are corrected prior to a system being installed on the network. and unnecessary web servers. as required for the function of the system Implementing additional security features for any required services.c Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network. www. 2. and there are also known ways to configure these systems to fix security vulnerabilities. To help those that are not security experts. databases.2. LLC.org. and product vendors. features. protocols. and www. Page 30 April 2015 . 2.org. subsystems.2.b Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified. daemons. All Rights Reserved. protocols or daemons that are considered to be insecure Configuring system security parameters to prevent misuse Removing all unnecessary functionality. and enterprise applications.cisecurity.nist. (For example.1.a Select a sample of system components and inspect enabled system services. as required for the function of the system. daemons.2. v3. 2. organizations can ensure that functions requiring different security levels don’t co-exist on the same server. 2. or protocols and interview personnel to verify they are justified per documented configuration standards. database servers. inspect the system configurations to verify that only one primary function is implemented per virtual system component or device.1 © 2006-2015 PCI Security Standards Council.2. 2.2.2.2. the security level of the functions with higher security needs would be reduced due to the presence of the lower-security functions. 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. Additionally.2. As stated in Requirement 1.b If virtualization technologies are used. Testing Procedures 2. Page 31 April 2015 .2 Enable only necessary services.2. protocols. 2. Guidance If server functions that need different security levels are located on the same server. All Rights Reserved. etc. and protocols to verify that only necessary services or protocols are enabled.a Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server. By considering the security needs of different server functions as part of the system configuration standards and related processes. LLC.. Including this requirement as part of an organization's configuration standards and related processes ensures that only the necessary services and protocols are enabled.1.2. and DNS should be implemented on separate servers.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. implement only one primary function per virtual system component. daemons. web servers.) Note: Where virtualization technologies are in use. the server functions with a lower security level may introduce security weaknesses to other functions on the same server. Payment Card Industry (PCI) Data Security Standard.6.PCI DSS Requirements 2. daemons.b Identify any enabled insecure services.1. g. 2016. Description of processes to monitor for new vulnerabilities associated with SSL/early TLS. SSL and/or early TLS must not be introduced into environments where they don’t already exist.c For all other environments using SSL and/or early TLS: Refer to industry standards and best practices for information on strong cryptography and secure protocols (e. and it is up to the organization to remain up-to-date with vulnerability trends and determine whether or not they are susceptible to any known exploits. system/network configuration details.2. Enabling security features before new servers are deployed will prevent servers being installed into the environment with insecure configurations. protocols.2. and daemons are adequately secured with appropriate security features makes it more difficult for malicious individuals to take advantage of commonly used points of compromise within a network. existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. LLC.PCI DSS Requirements 2. types and number of systems that use and/or support SSL/early TLS. v3. new vulnerabilities could emerge at any time.3 Implement additional security features for any required services. Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.. FTP. Overview of migration project plan including target migration completion date no later than June 30. protocols. Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30. Risk-assessment results and risk-reduction controls in place. vendor documentation. daemons. new implementations must not use SSL or early TLS. TLS. or IPSec VPN to protect insecure services such as NetBIOS. S-FTP. Description of usage.3. OWASP. Confirm the entity has documentation (for example. 2.b For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols: Ensuring that all insecure services. Testing Procedures Guidance 2. Prior to this date. etc. Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. All Rights Reserved. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30. or daemons that are considered to be insecure—for example. Additionally. 2.3. At the time of publication.a Inspect configuration settings to verify that security features are documented and implemented for all insecure services. Review the documented Risk Mitigation and Migration Plan to verify it includes: Payment Card Industry (PCI) Data Security Standard.1 © 2006-2015 PCI Security Standards Council.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS. 2016. etc. the known vulnerabilities are difficult to exploit in POS POI payment environments. NIST SP 800-52 and SP 800-57. type of environment. Telnet. However. etc. or protocols.3. Page 32 April 2015 .2. use secured technologies such as SSH. including what data is being transmitted. file-sharing.2. Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments. 2016.). Effective immediately. 1 © 2006-2015 PCI Security Standards Council. making it easy for an eavesdropper to intercept this information.2.5. 2.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components. become administrator. subsystems. etc. telnet. In order for systems to be configured securely.c. subsystems. and unnecessary web servers. 2. such as scripts.b Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.a Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example.3 Select a sample of system components and verify that non-console administrative access is encrypted by performing the following: Guidance System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use. by removing/disabling FTP or the web server if the server will not be performing those functions). By removing unnecessary functionality. 2. 2. If non-console (including remote) administration does not use secure authentication and encrypted communications. v3. 2.2. Use technologies such as SSH. drivers.b Examine the system configuration standards to verify that common security parameter settings are included.2. Examine the documentation and security parameters to verify that only documented functionality is present on the sampled system components. (Continued on next page) Payment Card Industry (PCI) Data Security Standard. features. and steal data. 2.2.3. 2.2. features.4 Configure system security parameters to prevent misuse. or TLS for web-based management and other non-console administrative access.3 Encrypt all non-console administrative access using strong cryptography.) is removed.) do not encrypt traffic or logon details. LLC. (Continued on next page) Page 33 April 2015 . Testing Procedures 2. file systems. 2. scripts.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested. VPN. personnel responsible for configuration and/or administering systems must be knowledgeable in the specific security parameters and settings that apply to the system. drivers.b. sensitive administrative or operational level information (like administrator’s IDs and passwords) can be revealed to an eavesdropper.5.2. 2.3. 2.PCI DSS Requirements 2.2.2.4. etc.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards. organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited.4. file systems.4.5 Remove all unnecessary functionality. Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example. Unnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. Clear-text protocols (such as HTTP. A malicious individual could use this information to access the network.5. Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration. All Rights Reserved. PCI DSS Requirements Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30. and it is up to the organization to remain up-to-date with vulnerability trends and determine whether or not they are susceptible to any known exploits.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.” industryrecognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. Guidance To be considered “strong cryptography. 2.3. 2016.e For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols: Confirm the entity has documentation (for example. LLC. 2016. Abbreviations.3. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30. and industry standards and best practices such as NIST SP 800-52 and SP 800-57. Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments. Testing Procedures 2. All Rights Reserved. 2.3. including what data is being transmitted. existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. OWASP. Description of processes to monitor for new vulnerabilities associated with SSL/early TLS. type of environment. system/network configuration details.f For all other environments using SSL and/or early TLS: Review the documented Risk Mitigation and Migration Plan to verify it includes: Description of usage.3. Page 34 April 2015 . Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS. Overview of migration project plan including target migration completion date no later than June 30. Effective immediately. v3.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS. vendor documentation. 2.) Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. etc. the known vulnerabilities are difficult to exploit in POS POI payment environments. Risk-assessment results and risk-reduction controls in place. Prior to this date. etc. (Refer to "strong cryptography” in the PCI DSS and PA-DSS Glossary of Terms. Additionally.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography. However.1 © 2006-2015 PCI Security Standards Council. new vulnerabilities could emerge at any time. new implementations must not use SSL or early TLS. Payment Card Industry (PCI) Data Security Standard. At the time of publication. and Acronyms. types and number of systems that use and/or support SSL/early TLS. 2016. SSL and/or early TLS must not be introduced into environments where they don’t already exist. Page 35 April 2015 .6 Perform testing procedures A. This allows clients to add insecure functions and scripts that impact the security of all other client environments. Testing Procedures 2. and Known to all affected parties. and be inadvertently excluded from the organization’s configuration standards. LLC.1. to verify that shared hosting providers protect their entities’ (merchants and service providers) hosted environment and data. 2.1 through A.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. and thereby make it easy for a malicious individual to compromise one client's data and thereby gain access to all other clients' data.1. Personnel need to be aware of and following security policies and daily operational procedures to ensure vendor defaults and other security parameters are continuously managed to prevent insecure configurations. and known to all affected parties. See Appendix A for details of requirements. All Rights Reserved.4. Documented. in use. 2.a Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each.4 detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers.PCI DSS Requirements 2.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing vendor defaults and other security parameters are: 2. often the settings on these shared servers are not manageable by individual clients. Without an inventory.1 © 2006-2015 PCI Security Standards Council.4. This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. v3. In use. When all data is on the same server and under control of a single environment. Guidance Maintaining a current list of all system components will enable an organization to accurately and efficiently define the scope of their environment for implementing PCI DSS controls.b Interview personnel to verify the documented inventory is kept current. 2. 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented. Payment Card Industry (PCI) Data Security Standard. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers. some system components could be forgotten.4 Maintain an inventory of system components that are in scope for PCI DSS. Protect Cardholder Data Requirement 3: Protect stored cardholder data Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging. Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI DSS terms. PCI DSS Requirements 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements Specific retention requirements for cardholder data Processes for secure deletion of data when no longer needed A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention. Testing Procedures 3.1.a Examine the data retention and disposal policies, procedures and processes to verify they include the following for all cardholder data (CHD) storage: Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements. Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons). Processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons. A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements. 3.1.b Interview personnel to verify that: Guidance 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. 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. Understanding where cardholder data is located is necessary so it can be properly retained or disposed of when 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. All locations of stored cardholder data are included in the data retention and disposal processes. Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data. The quarterly automatic or manual process is performed for all locations of cardholder data. Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. (Continued on next page) Page 36 April 2015 PCI DSS Requirements Testing Procedures Guidance 3.1.c For a sample of system components that store cardholder data: Identifying and deleting stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated or manual or a combination of both. For example, a programmatic procedure (automatic or manual) to locate and remove data and/or a manual review of data storage areas could be performed. Examine files and system records to verify that the data stored does not exceed the requirements defined in the data retention policy Observe the deletion mechanism to verify data is deleted securely. Implementing secure deletion methods ensure that the data cannot be retrieved when it is no longer needed. Remember, if you don't need it, don't store it! 3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process. 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 includes the data as cited in the following Requirements 3.2.1 through 3.2.3: 3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data. Sensitive authentication data consists of full track data, card validation code or value, and PIN data. 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. 3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured. Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. 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. 3.2.c For all other entities, if sensitive authentication data is received, review policies and procedures, and examine system configurations to verify the data is not retained after authorization. Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. 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 all PCI DSS and specific payment brand requirements. Page 37 April 2015 PCI DSS Requirements Testing Procedures 3.2.d For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable. 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) after authorization. This data is alternatively called full track, track, track 1, track 2, and magneticstripe data. Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: The cardholder’s name Primary account number (PAN) Expiration date Service code To minimize risk, store only these data elements as needed for business. 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) after authorization. 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 after authorization: Guidance For non-issuing entities, retaining sensitive authentication data post-authorization is not permitted. If full track data is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions. 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 three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization: Incoming transaction data All logs (for example, transaction, history, debugging, error) The purpose of the card validation code is to protect "card-not-present" transactions—Internet or mail order/telephone order (MO/TO) transactions—where the consumer and the card are not present. If this data is stolen, malicious individuals can execute fraudulent Internet and MO/TO transactions. History files Trace files Several database schemas Database contents. Payment Card Industry (PCI) Data Security Standard, v3.1 © 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved. Page 38 April 2015 3. examine data sources. or paper reports can result in this data being obtained by unauthorized individuals and used fraudulently.3. All logs (for example. paper receipts. on screen. 3.3. error) History files Trace files Several database schemas Database contents. Testing Procedures 3. etc.2. transaction. etc. such that only personnel with a legitimate business need can see the full PAN.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).3.c Examine displays of PAN (for example. including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored after authorization: Incoming transaction data Guidance These values should be known only to the card owner or bank that issued the card.3 For a sample of system components. legal or payment card brand requirements for point-of-sale (POS) receipts. All Rights Reserved. LLC.a Examine written policies and procedures for masking the display of PANs to verify: A list of roles that need access to displays of full PAN is documented. Ensuring that full PAN is only displayed for those with a legitimate business need to see the full PAN minimizes the risk of unauthorized persons gaining access to PAN data. 3. Page 39 April 2015 . and is not to be confused with Requirement 3. Payment Card Industry (PCI) Data Security Standard. history. If this data is stolen. All other roles not specifically authorized to see the full PAN must only see masked PANs. and that only those with a legitimate business need are able to see full PAN. and that PAN is masked for all other requests.PCI DSS Requirements 3. v3. printouts. faxes. on paper receipts) to verify that PANs are masked when displaying cardholder data. The display of full PAN on items such as computer screens. databases. malicious individuals can execute fraudulent PIN-based debit transactions (for example.1 © 2006-2015 PCI Security Standards Council.b Examine system configurations to verify that full PAN is only displayed for users/roles with a documented business need. payment card receipts.2.4 for protection of PAN when stored in files. together with a legitimate business need for each role to have such access.. PAN must be masked when displayed such that only personnel with a legitimate business need can see the full PAN.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization. 3. Note: This requirement does not supersede stricter requirements in place for displays of cardholder data—for example. This requirement relates to protection of PAN displayed on screens. ATM withdrawals). debugging. One-way hashes based on strong cryptography. type of system/process. audit logs. not stored in plain-text). Where hashed and truncated versions of the same PAN are present in an entity’s environment. All Rights Reserved. and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the following methods: PANs stored in primary storage (databases. v3. but not currently a requirement. Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. with the pads being securely stored Strong cryptography. One-way hashes based on strong cryptography. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible).4. It is recommended. An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. exception or troubleshooting logs) must all be protected. (hash must be of the entire PAN) Truncation (hashing cannot be used to replace the truncated segment of PAN) Index tokens and pads (pads must be securely stored) Strong cryptography with associated key-management processes and procedures. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key. including the vendor.4.c Examine a sample of removable media (for example.1 © 2006-2015 PCI Security Standards Council.e If hashed and truncated versions of the same PAN are present in the environment. backup media. By correlating hashed and truncated versions of a given PAN.4 Render PAN unreadable anywhere it is stored (including on portable digital media. LLC. 3. and in logs) by using any of the following approaches: 3. The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms. Page 40 April 2015 . back-up tapes) to confirm that the PAN is rendered unreadable.4. random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of precomputed hash values.PCI DSS Requirements Testing Procedures Guidance 3. Truncation Index tokens and pads.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs. with associated key-management processes and procedures. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable. Payment Card Industry (PCI) Data Security Standard. The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored.4. 3. 3. a malicious individual may easily derive the original PAN value.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is. One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. or flat files such as text files spreadsheets) as well as non-primary storage (backup. Abbreviations. and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "homegrown" algorithm) with strong cryptographic keys. examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.4. additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.a Examine documentation about the system used to protect the PAN. that an additional. 3. 4. Decryption keys must not be associated with user accounts. Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. or Use a decryption key that is associated with or derived from the system’s local user account database or general network login credentials. All Rights Reserved. Keys are stored securely in the fewest possible locations and forms. v3. logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example.or column-level database encryption). Note: If disk encryption is not used to encrypt removable media. Key-encrypting keys.4.b Observe processes and interview personnel to verify that cryptographic keys are stored securely (for example. Many diskencryption solutions intercept operating system read/write operations and carry out the appropriate cryptographic transformations without any special action by the user other than supplying a password or pass phrase upon system startup or at the beginning of a session.4. the data stored on this media will need to be rendered unreadable through some other method. 3. and also applies to key-encrypting keys used to protect data-encrypting keys— such key-encrypting keys must be at least as strong as the data-encrypting key. Key-encrypting keys are stored separately from dataencrypting keys.5 Examine key-management policies and procedures to verify processes are specified to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following: Access to keys is restricted to the fewest number of custodians necessary. stored on removable media that is adequately protected with strong access controls). Based on these characteristics of disk-level encryption. to be compliant with this requirement.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse: Note: This requirement applies to keys used to encrypt stored cardholder data. by not using local user account databases or general network login credentials). 1) 2) Use the same user account authenticator as the operating system. 3.1.4. 3.1 © 2006-2015 PCI Security Standards Council. Key-encrypting keys are at least as strong as the dataencrypting keys they protect.a If disk encryption is used. The intent of this requirement is to address the acceptability of disk-level encryption for rendering cardholder data unreadable.PCI DSS Requirements Testing Procedures Guidance 3. The requirement to protect keys from disclosure and misuse applies to both data-encrypting keys and key-encrypting keys. not using local user account databases or general network login credentials).1. inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example. Page 41 April 2015 . the method cannot: 3. Because one keyencrypting key may grant access to many dataencrypting keys. the key-encrypting keys require strong protection measures. Payment Card Industry (PCI) Data Security Standard.1. 3. Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data. 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.1 If disk encryption is used (rather than file.c Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored. Disk-level encryption encrypts the entire disk/partition on a computer and automatically decrypts the information when an authorized user requests it. if used. LLC. 3. Payment Card Industry (PCI) Data Security Standard.5. in accordance with an industry-accepted method 3.5. Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key.5. however they are to be protected against disclosure and misuse as defined in Requirement 3. 3. Cryptographic keys must be stored securely to prevent unauthorized or unnecessary access that could result in the exposure of cardholder data.5.5.PCI DSS Requirements Testing Procedures 3. 3.1 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary. storing the key-encrypting keys in physically and/or logically separate locations from the dataencrypting keys reduces the risk of unauthorized access to both keys. examine system configurations and key storage locations to verify: Key-encrypting keys are at least as strong as the dataencrypting keys they protect Key-encrypting keys are stored separately from dataencrypting keys.2 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times: 3. in accordance with an industryaccepted method Note: It is not required that public keys be stored in one of these forms.2. and that is stored separately from the dataencrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTSapproved point-of-interaction device) As at least two full-length key components or key shares.1 © 2006-2015 PCI Security Standards Council.5.2.a Examine documented procedures to verify that cryptographic keys used to encrypt/decrypt cardholder data must only exist in one (or more) of the following forms at all times. Page 42 April 2015 . If key-encrypting keys are used. and that is stored separately from the data-encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) As key components or key shares. in accordance with an industry-accepted method Guidance It is not intended that the key-encrypting keys be encrypted. There should be very few who have access to cryptographic keys (reducing the potential for rending cardholder data visible by unauthorized parties).2. v3.1 Restrict access to cryptographic keys to the fewest number of custodians necessary. All Rights Reserved. usually only those who have key custodian responsibilities.c Wherever key-encrypting keys are used.5.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of the following form at all times. LLC. Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key. Encrypted with a key-encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) As key components or key shares. LLC. as defined in the PCI DSS and PA-DSS Glossary of Terms.gov. including the following: Note: Numerous industry standards for key management are available from various resources including NIST.b Examine the key-management procedures and processes for keys used for encryption of cardholder data and perform the following: Providing guidance to customers on how to securely transmit. is based on industry standards and addresses all key elements at 3. v3. A good keymanagement process.6. The encryption solution must distribute keys securely.1. All Rights Reserved.5. 3.2.5.b Observe the method for generating keys to verify that strong keys are generated. Abbreviations. and Acronyms under "strong cryptography.6. 3. Payment Card Industry (PCI) Data Security Standard.8 below." Use of strong cryptographic keys significantly increases the level of security of encrypted cardholder data.6.1 © 2006-2015 PCI Security Standards Council.3 Store cryptographic keys in the fewest possible locations. 3.a Additional testing procedure for service provider assessments only: If the service provider shares keys with their customers for transmission or storage of cardholder data. 3. 3.6.6. 3.2.PCI DSS Requirements Testing Procedures Guidance 3. The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. whether it is manual or automated as part of the encryption product.6.6.8. meaning the keys are distributed only to custodians identified in 3.6.3 Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations.6. and are never distributed in the clear. Note: Testing Procedure 3. The encryption solution must generate strong keys.6.a Verify that key-management procedures specify how to securely distribute keys. Storing cryptographic keys in the fewest locations helps an organization to keep track and monitor all key locations. Page 43 April 2015 . 3.b Observe the method for distributing keys to verify that keys are distributed securely.1.6. store. 3.5.6. examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit.1 through 3.1.a is an additional procedure that only applies if the entity being assessed is a service provider. and any respective keyencrypting keys.1 through 3. store and update cryptographic keys can help prevent keys from being mismanaged or disclosed to unauthorized entities. which can be found at http://csrc.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.2 Secure cryptographic key distribution 3. and minimizes the potential for keys to be exposed to unauthorized parties. and update customers’ keys.nist.6. in accordance with Requirements 3. This requirement applies to keys used to encrypt stored cardholder data.a Verify that key-management procedures specify how to generate strong keys.1 Generation of strong cryptographic keys 3. Considerations for defining the cryptoperiod include.a Verify that key-management procedures specify processes for the following: The retirement or replacement of keys when the integrity of the key has been weakened The replacement of known or suspected compromised keys. 3.6. size or length of the key.6. for example. 3. after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key). Any keys retained after retiring or replacing are not used for encryption operations 3.3. but are not limited to. or keys are suspected of being compromised. the strength of the underlying algorithm. compromised.a Verify that key-management procedures specify how to securely store keys. All Rights Reserved. or suspected of being. and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example.6. Payment Card Industry (PCI) Data Security Standard.PCI DSS Requirements 3. The encryption solution should provide for and facilitate a process to replace keys that are due for replacement or that are known to be.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example. risk of key compromise. 3.5. as defined by the associated application vendor or key owner.4. to support archived. 3. by using a key-encryption key). should be revoked and/or destroyed to ensure that the keys can no longer be used.6. Periodic changing of encryption keys when the keys have reached the end of their cryptoperiod is imperative to minimize the risk of someone’s obtaining the encryption keys. or keys that are known or suspected to be compromised. resulting in the decryption and exposure of cardholder data. NIST Special Publication 800-57). Keys are replaced if known or suspected to be compromised.6.5. v3. and based on industry best practices and guidelines (for example. Page 44 April 2015 . encrypted data) they should be strongly protected. Archived cryptographic keys should only be used for decryption/verification purposes.3 Secure cryptographic key storage Testing Procedures Guidance 3. and the sensitivity of the data being encrypted. these keys must be securely archived (for example.6. 3. including when someone with knowledge of the key leaves the company.5 Retirement or replacement (for example. by encrypting them with a keyencrypting key.b Interview personnel to verify that keys are changed at the end of the defined cryptoperiod(s). Keys are retired or replaced as necessary when the integrity of the key has been weakened. Any keys retained after retiring or replacing are not used for encryption operations.6. LLC. If such keys need to be kept (for example. archiving.4. Note: If retired or replaced cryptographic keys need to be retained. destruction.1 © 2006-2015 PCI Security Standards Council. A cryptoperiod is the time span during which a particular cryptographic key can be used for its defined purpose. Storing keys without proper protection could provide access to attackers.a Verify that key-management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined cryptoperiod(s). and using them to decrypt data.3.b Observe the method for storing keys to verify that keys are stored securely.6. The encryption solution must store keys securely. 3.b Interview personnel to verify the following processes are implemented: Keys that are no longer used or needed. departure of an employee with knowledge of a clear-text key component).6. LLC. The encryption solution should not allow for or accept substitution of keys coming from unauthorized sources or unexpected processes.6.7. Split knowledge is a method in which two or more people separately have key components.6. This process will help ensure individuals that act as key custodians commit to the key-custodian role and understand and accept the responsibilities.7. AND Note: Examples of manual keymanagement operations include.a Verify that manual clear-text key-management procedures specify processes for the use of the following: Split knowledge of keys. where each person knows only their own key component.6. and no single person can access or use the authentication materials of another. Dual control requires two or more people to perform a function. loading. passwords or keys) of another.6.6 b Interview personnel and/or observe processes to verify that manual clear-text keys are managed with: Split knowledge. 3.8. Guidance Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key. 3. and Known to all affected parties.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented.6.PCI DSS Requirements 3. Payment Card Industry (PCI) Data Security Standard. and the individual key components convey no knowledge of the original cryptographic key). Page 45 April 2015 .b Observe documentation or other evidence showing that key custodians have acknowledged (in writing or electronically) that they understand and accept their keycustodian responsibilities.6.6. 3. transmission. In use.1 © 2006-2015 PCI Security Standards Council. All Rights Reserved.6.a Verify that key-management procedures specify processes to prevent unauthorized substitution of keys.6 If manual clear-text cryptographic key-management operations are used.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities. or where key management is not implemented by the encryption product. Dual control of keys.7 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting stored cardholder data are: Documented.8. 3. such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example.7 Prevention of unauthorized substitution of cryptographic keys.6. 3. and known to all affected parties. in use. but are not limited to: key generation. storage and destruction. such that key components are under the control of at least two people who only have knowledge of their own key components. AND Dual control 3. v3. 3. Personnel need to be aware of and following security policies and documented operational procedures for managing the secure storage of cardholder data on a continuous basis. 3. these operations must be managed using split knowledge and dual control. Testing Procedures 3.6.a Verify that key-management procedures specify processes for key custodians to acknowledge (in writing or electronically) that they understand and accept their keycustodian responsibilities. This control is applicable for manual key-management operations.b Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented. 3. public networks. ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example. 2016. existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. 4. SSH. including the following: Only trusted keys and certificates are accepted. a secure protocol for transport. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations. should not be accepted.1. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30. because it is easy and common for a malicious individual to intercept and/or divert data while in transit.1. Effective immediately.1.b Review documented policies and procedures to verify processes are specified for the following: For acceptance of only trusted keys and/or certificates For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported) For implementation of proper encryption strength per the encryption methodology in use Guidance Sensitive information must be encrypted during transmission over public networks.1 Use strong cryptography and security protocols (for example. Secure transmission of cardholder data requires using trusted keys/certificates. The encryption strength is appropriate for the encryption methodology in use.1. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments. by using only trusted certificates and supporting only strong encryption (not supporting weaker. Note that some protocol implementations (such as SSL. Whichever security protocol is used. The protocol in use only supports secure versions or configurations.c Select and observe a sample of inbound and outbound transmissions as they occur to verify that all cardholder data is encrypted with strong cryptography during transit. 2016. SSH v1. new implementations must not use SSL or early TLS. (Continued on next page) 4.) to safeguard sensitive cardholder data during transmission over open. and proper encryption strength to encrypt cardholder data. 4.1. Verifying that certificates are trusted (for example. and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system.d Examine keys and certificates to verify that only trusted keys and/or certificates are accepted.) (Continued on next page) Payment Card Industry (PCI) Data Security Standard. Prior to this date. public networks Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. TLS.Requirement 4: Encrypt transmission of cardholder data across open. public networks. All Rights Reserved. insecure protocols or methods). Connection requests from systems that do not support the required encryption strength. 4. v3. 4.f Examine system configurations to verify that the proper encryption strength is implemented for the encryption methodology in use. and that would result in an insecure connection.1. Testing Procedures PCI DSS Requirements 4. Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30. Page 46 April 2015 . have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection. IPSEC.e Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations. (Check vendor recommendations/best practices. LLC.0. 4.1 © 2006-2015 PCI Security Standards Council.a Identify all locations where cardholder data is transmitted or received over open. etc. g.i For all other environments using SSL and/or early TLS: Review the documented Risk Mitigation and Migration Plan to verify it includes: Description of usage. examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received. Overview of migration project plan including target migration completion date no later than June 30. including what data is being transmitted.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS. and Cardholder data is only requested if “HTTPS” appears as part of the URL. Risk-assessment results and risk-reduction controls in place. etc. 2016. Additionally. NIST SP 800-52 and SP 800-57. types and number of systems that use and/or support SSL/early TLS. Description of processes to monitor for new vulnerabilities associated with SSL/early TLS.1. including 802. etc. the known vulnerabilities are difficult to exploit in POS POI payment environments.1. Refer to the PCI SSC Information Supplement: Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS. public networks include but are not limited to: The Internet Wireless technologies. For example. Guidance Generally. system/network configuration details.) Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Payment Card Industry (PCI) Data Security Standard.Testing Procedures PCI DSS Requirements Examples of open." or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website.11 and Bluetooth Cellular technologies. for example. SSL and/or early TLS must not be introduced into environments where they don’t already exist.” "secure site seal. However. Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments. for browser-based implementations: “HTTPS” appears as the browser Universal Record Locator (URL) protocol. LLC. Refer to industry standards and best practices for information on strong cryptography and secure protocols (e. 4. the web page URL should begin with "HTTPS" and/or the web browser display a padlock icon somewhere in the window of the browser.g For TLS implementations. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal. new vulnerabilities could emerge at any time.1 © 2006-2015 PCI Security Standards Council.1. Page 47 April 2015 . type of environment. Code division multiple access (CDMA) General Packet Radio Service (GPRS) Satellite communications 4. At the time of publication. OWASP. 4. v3. vendor documentation. Global System for Mobile communications (GSM). All Rights Reserved. and it is up to the organization to remain up-to-date with vulnerability trends and determine whether or not they are susceptible to any known exploits.h For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols: Confirm the entity has documentation (for example. Additionally. WEP. v3. 4. 4. 4. SMS.1. All Rights Reserved. 4.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Use of strong cryptography can help limit disclosure of sensitive information across wireless networks. 4. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption. IEEE 802. Page 48 April 2015 . SSL) is not used as a security control for authentication or transmission. if an entity requests PAN via enduser messaging technologies.a If end-user messaging technologies are used to send cardholder data. LLC. observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.11i) to implement strong encryption for authentication and transmission.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented. the entity should provide a tool or method to protect these PANs using strong cryptography or render PANs unreadable before transmission.). SMS.3 Examine documentation and interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are: Personnel need to be aware of and following security policies and operational procedures for managing the secure transmission of cardholder data on a continuous basis.2. and Known to all affected parties.PCI DSS Requirements Testing Procedures Guidance 4.2 Never send unprotected PANs by enduser messaging technologies (for example.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment.b Review written policies to verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies.2. E-mail. Documented. chat. instant messaging.1. and known to all affected parties.1 © 2006-2015 PCI Security Standards Council. etc. Strong cryptography for authentication and transmission of cardholder data is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data. in use. Weak encryption (for example. and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. instant messaging. email. 4. Industry best practices (for example. Payment Card Industry (PCI) Data Security Standard. In use. Note: The use of WEP as a security control is prohibited. IEEE 802.11i) are used to implement strong encryption for authentication and transmission. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified: Malicious users use free and widely available tools to eavesdrop on wireless communications. use industry best practices (for example. Page 49 April 2015 . It is important to protect against ALL types and forms of malicious software.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.Maintain a Vulnerability Management Program Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs Malicious software. removing. such additional solutions do not replace the need for anti-virus software to be in place. 5. resulting in the exploitation of system vulnerabilities. and rootkits. Without an anti-virus solution that is updated regularly. Examples of types of malicious software include viruses. Payment Card Industry (PCI) Data Security Standard. and storage devices.1. 5. spyware. mobile computers. disable a network. worms. commonly referred to as “malware”—including viruses. and Trojans—enters the network during many businessapproved activities including employee e-mail and use of the Internet. or lead to compromise of data. and protecting against all known types of malicious software.1 © 2006-2015 PCI Security Standards Council.1. Trojans.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. adware.1 Review vendor documentation and examine anti-virus configurations to verify that anti-virus programs. Detect all known types of malicious software. against otherwise secured systems. There is a constant stream of attacks using widely published exploits. these new forms of malicious software can attack systems. 5. All Rights Reserved. Additional anti-malware solutions may be considered as a supplement to the anti-virus software. and Protect against all known types of malicious software. LLC.1 Ensure that anti-virus programs are capable of detecting. however. worms. Remove all known types of malicious software. PCI DSS Requirements Testing Procedures Guidance 5. often called "zero day" (an attack that exploits a previously unknown vulnerability). v3. 5. to verify that: Anti-virus software log generation is enabled.b Examine anti-virus configurations.d Examine anti-virus configurations.2. industry trends for malicious software can change quickly. mid-range computers (such as AS/400) and similar systems may not currently be commonly targeted or affected by malware. perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software. Payment Card Industry (PCI) Data Security Standard. mainframes. 5. Trends in malicious software should be included in the identification of new security vulnerabilities. Thus. 5.7.2. Guidance Typically. in order to confirm whether such systems continue to not require anti-virus software. including the master installation of the software and a sample of system components.2 Ensure that all anti-virus mechanisms are maintained as follows: Are kept current. Page 50 April 2015 . including all operating system types commonly affected by malicious software. and methods to address new trends should be incorporated into the company's configuration standards and protection mechanisms as needed 5. Periodic scans are performed. so it is important for organizations to be aware of new malware that might affect their systems—for example. and Configured to perform periodic scans. and Logs are retained in accordance with PCI DSS Requirement 10.Testing Procedures PCI DSS Requirements 5. to verify that: Even the best anti-virus solutions are limited in effectiveness if they are not maintained and kept current with the latest security updates. v3. 5.2 Interview personnel to verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software. Perform periodic scans Generate audit logs which are retained per PCI DSS Requirement 10.c Examine a sample of system components. or malware protections. All Rights Reserved. LLC. The anti-virus software and definitions are current. However.1 © 2006-2015 PCI Security Standards Council. Audit logs provide the ability to monitor virus and malware activity and anti-malware reactions.2 For systems considered to be not commonly affected by malicious software. including the master installation of the software to verify anti-virus mechanisms are: Configured to perform automatic updates. signature files. by monitoring vendor security notices and anti-virus news groups to determine whether their systems might be coming under threat from new and evolving malware.a Examine policies and procedures to verify that anti-virus software and definitions are required to be kept up to date.2. it is imperative that anti-malware solutions be configured to generate audit logs and that these logs be managed in accordance with Requirement 10. 5.1.2.7.1. All Rights Reserved.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users. Use of policy-based controls on all systems to ensure anti-malware protections cannot be altered or disabled will help prevent system weaknesses from being exploited by malicious software. Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need. it must be formally authorized. 5. v3. disconnecting the unprotected system from the Internet while the anti-virus protection is disabled.4 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting systems against malware are: Documented. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active—for example. and known to all affected parties. and running a full scan after it is re-enabled. In use. LLC. unless specifically authorized by management on a case-by-case basis for a limited time period. Payment Card Industry (PCI) Data Security Standard.4 Ensure that security policies and operational procedures for protecting systems against malware are documented. If anti-virus protection needs to be disabled for a specific purpose. 5.b Examine anti-virus configurations. Anti-virus that continually runs and is unable to be altered will provide persistent security against malware. PCI DSS Requirements 5. unless specifically authorized by management on a case-by-case basis for a limited time period. in use.3. 5.1 © 2006-2015 PCI Security Standards Council. to verify the anti-virus software is actively running.a Examine anti-virus configurations. Page 51 April 2015 . Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active. Personnel need to be aware of and following security policies and operational procedures to ensure systems are protected from malware on a continuous basis. including the master installation of the software and a sample of system components.Testing Procedures Guidance 5. as authorized by management on a case-by-case basis. and Known to all affected parties. to verify that the anti-virus software cannot be disabled or altered by users.3.c Interview responsible personnel and observe processes to verify that anti-virus software cannot be disabled or altered by users. 5.3. including the master installation of the software and a sample of system components. databases. Guidance The intent of this requirement is that organizations keep up to date with new vulnerabilities that may impact their environment. which must be installed by the entities that manage the systems. Classifying the risks (for example. To use reputable outside sources for security vulnerability information.” or “low”) allows organizations to identify. process. LLC. at a minimum.1.1 Establish a process to identify security vulnerabilities. v3. using reputable outside sources for security vulnerability information. The organization must therefore have a method in place to evaluate vulnerabilities on an ongoing basis and assign risk rankings to those vulnerabilities. Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. criteria for ranking vulnerabilities may include consideration of the CVSS base score. Risk rankings should. Once an organization identifies a vulnerability that could affect their environment.Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems.” “medium. identify all vulnerabilities considered to be a “high risk” to the environment.b Interview responsible personnel and observe processes to verify that: New security vulnerabilities are identified. Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information. Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and riskassessment strategy. as “high. All Rights Reserved. industry news groups. A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities. mailing list. or RSS feeds. Sources for vulnerability information should be trustworthy and often include vendor websites. prioritize. Testing Procedures 6. numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques. and/or would result in a potential compromise if not addressed. and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited. vulnerabilities may be considered “critical” if they pose an imminent threat to the environment. as “high. public-facing devices and systems. Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. In addition to the risk ranking. or transmit cardholder data. rather this requires a process to actively monitor industry sources for vulnerability information.1 © 2006-2015 PCI Security Standards Council.” or “low”) to newly discovered security vulnerabilities. the risk that the vulnerability poses must be evaluated and ranked. Page 52 April 2015 . Many of these vulnerabilities are fixed by vendorprovided security patches. impact critical systems. and/or type of systems affected. For example. 6. Examples of critical systems may include security systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.a Examine policies and procedures to verify that processes are defined for the following: To identify new security vulnerabilities To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities. and/or the classification by the vendor. and other systems that store. and assign a risk ranking (for example. This is not achieved by an ASV scan or internal vulnerability scan. PCI DSS Requirements 6.1. For in-house developed applications. Payment Card Industry (PCI) Data Security Standard.” “medium. Prioritizing patches for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released.PCI DSS Requirements 6. analysis. design. security vulnerabilities can be inadvertently or maliciously introduced into the production environment.3.b Examine written software-development processes to verify that information security is included throughout the life cycle. 6. Without the inclusion of security during the requirements definition. Incorporating information security throughout the software-development life cycle Installation of applicable critical vendor-supplied security patches within one month of release. Testing Procedures 6. secure authentication and logging) Based on industry standards and/or best practices. Page 53 April 2015 .3.2. Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example. often called "zero day" (an attack that exploits a previously unknown vulnerability). transmitted. 6. That applicable critical vendor-supplied security patches are installed within one month of release. Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party. Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days. Payment Card Industry (PCI) Data Security Standard. against otherwise secured systems. a malicious individual can use these exploits to attack or disable a system. Understanding how sensitive data is handled by the application—including when stored. 6. All applicable vendor-supplied security patches are installed within an appropriate time frame (for example. to verify the following: 6.1. All Rights Reserved. Install critical security patches within one month of release. or gain access to sensitive data.1 © 2006-2015 PCI Security Standards Council. v3. within three months). as follows: In accordance with PCI DSS (for example. within three months). and other lower-risk patches are installed within 2-3 months.a Examine written software-development processes to verify that the processes are based on industry standards and/or best practices.d Interview software developers to verify that written software-development processes are implemented.c Examine written software-development processes to verify that software applications are developed in accordance with PCI DSS.3.3 Develop internal and external software applications (including web-based administrative access to applications) securely. compare the list of security patches installed on each system to the most recent vendor security-patch list. 6. and when in memory—can help identify where data needs to be protected.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendorsupplied security patches. Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6. Guidance There is a constant stream of attacks using widely published exploits. LLC.3.b For a sample of system components and related software. and testing phases of software development.2. If the most recent patches are not implemented on critical systems as soon as possible.a Examine policies and procedures related to securitypatch installation to verify processes are defined for: 6. This requirement applies to applicable patches for all installed software. Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6. Code changes are reviewed by individuals other than the originating code author. Including a formal review and signoff by management prior to release helps to ensure that code is approved and has been developed in accordance with policies and procedures. Code changes are reviewed by individuals other than the originating code author. Code-review results are reviewed and approved by management prior to release. and by individuals who are knowledgeable in code-review techniques and secure coding practices. and passwords should be removed from production code before the application becomes active or is released to customers.3. Guidance Correcting coding errors before the code is deployed into a production environment or released to customers prevents the code exposing the environments to potential exploit. objective review. Code reviews should be performed by someone other than the developer of the code to allow for an independent.1 Examine written software-development procedures and interview responsible personnel to verify that preproduction and/or custom application accounts.3. LLC. Development. Automated tools or processes may also be used in lieu of manual reviews. user IDs. user IDs and/or passwords are removed before an application goes into production or is released to customers. and by individuals knowledgeable about code-review techniques and secure coding practices.PCI DSS Requirements Testing Procedures 6. All Rights Reserved. Page 54 April 2015 .5). Faulty code is also far more difficult and expensive to address after it has been deployed or released into production environments. since these items may give away information about the functioning of the application.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: 6. (Continued on next page) Payment Card Industry (PCI) Data Security Standard. and passwords before applications become active or are released to customers. Code reviews ensure code is developed according to secure coding guidelines Appropriate corrections are implemented prior to release. test and/or custom application accounts. 6.1 Remove development. Code-review results are reviewed and approved by management prior to release. Possession of such information could facilitate compromise of the application and related cardholder data. but keep in mind that it may be difficult or even impossible for an automated tool to identify some coding issues. v3. An individual knowledgeable and experienced in code-review techniques should be involved in the review process. test and/or custom application accounts.2. user IDs. Appropriate corrections are implemented prior to release. 6.3.3.a Examine written software-development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows: Security vulnerabilities in custom code are commonly exploited by malicious individuals to gain access to a network and compromise cardholder data.1 © 2006-2015 PCI Security Standards Council. Testing Procedures Guidance 6. Code reviews can be conducted by knowledgeable internal personnel or third parties. v3.4. Due to the constantly changing state of development and test environments. Development/test environments are separate from production environments with access control in place to enforce separation. it may be possible for the production environment.2.a. to address ongoing threats and vulnerabilities after implementation.1 Separate development/test environments from production environments. Change control procedures related to implementing security patches and software modifications are documented. security features could be inadvertently or deliberately omitted or rendered inoperable.1. above. they tend to be less secure than the production environment. and cardholder data. All Rights Reserved.1 © 2006-2015 PCI Security Standards Council. A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.2.3.PCI DSS Requirements Note: This requirement for code reviews applies to all custom code (both internal and public-facing). Public-facing web applications are also subject to additional controls.6. and enforce the separation with access controls. processing irregularities could occur.b Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s). or malicious code could be introduced.4 Follow change control processes and procedures for all changes to system components. Page 55 April 2015 . to be compromised due to lessstringent security configurations and possible vulnerabilities in a test or development environment. 6.1. Production data (live PANs) are not used for testing or development. as part of the system development life cycle. 6. The processes must include the following: 6.4. as defined at PCI DSS Requirement 6. LLC. Test data and accounts are removed before a production system becomes active. Without properly documented and implemented change controls. Payment Card Industry (PCI) Data Security Standard.4 Examine policies and procedures to verify the following are defined: 6.3.b Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.a Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s). 6.4. Without adequate separation between environments. 2 Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.2 Separation of duties between development/test and production environments Testing Procedures 6. v3. Security controls are usually not as stringent in test or development environments.4 Removal of test data and accounts before production systems become active 6. All Rights Reserved. Payment Card Industry (PCI) Data Security Standard.4.4.4.4.4. LLC.a Observe testing processes and interview personnel to verify procedures are in place to ensure production data (live PANs) are not used for testing or development.4.b Examine a sample of data and accounts from production systems recently installed or updated to verify test data and accounts are removed before the system becomes active. 6. a developer may use an administrator-level account with elevated privileges in the development environment. Use of production data provides malicious individuals with the opportunity to gain unauthorized access to production data (cardholder data). Possession of such information could facilitate compromise of the system and related cardholder data. Test data and accounts should be removed from production code before the application becomes active.1 © 2006-2015 PCI Security Standards Council.4.b Examine a sample of test data to verify production data (live PANs) is not used for testing or development. 6. and have a separate account with user-level access to the production environment.3 Production data (live PANs) are not used for testing or development 6.4. For example. Page 56 April 2015 . 6.PCI DSS Requirements 6. 6.a Observe testing processes and interview personnel to verify test data and accounts are removed before a production system becomes active.3.4.3. Guidance 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.4. since these items may give away information about the functioning of the application or system. The intent of this requirement is to separate development and test functions from production functions. 5. 6. Thorough testing should be performed to verify that the security of the environment is not reduced by implementing a change. v3. Payment Card Industry (PCI) Data Security Standard.5.a For each sampled change.2 Documented change approval by authorized parties. 6.4.4.4.a Examine documented change control procedures related to implementing security patches and software modifications and verify procedures are defined for: If not properly managed. 6. verify that all updates are tested for compliance with PCI DSS Requirement 6. Documentation of impact Documented change approval by authorized parties Functionality testing to verify that the change does not adversely impact the security of the system Back-out procedures 6.4.PCI DSS Requirements 6.4 Verify that back-out procedures are prepared for each sampled change.5. For each change.4.4.5. or are strengthened after any change to the environment.5. to allow the system to be restored back to its previous state.1 © 2006-2015 PCI Security Standards Council. LLC. 6. are replaced with equally strong controls. 6.4.4. 6. perform the following: 6.5 Change control procedures for the implementation of security patches and software modifications must include the following: Testing Procedures Guidance 6. For each change examined.5.3 Functionality testing to verify that the change does not adversely impact the security of the system. the impact of software updates and security patches might not be fully realized and could have unintended consequences.b For custom code changes.4.4. verify that functionality testing is performed to verify that the change does not adversely impact the security of the system.4. Trace those changes back to related change control documentation.1 Verify that documentation of impact is included in the change control documentation for each sampled change.5. Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by the organization. there should be documented back-out procedures in case the change fails or adversely affects the security of an application or system. 6.3.5 before being deployed into production.5. The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes. Page 57 April 2015 . Testing should validate that all existing security controls remain in place.4.4 Back-out procedures. All Rights Reserved.1 Documentation of impact. interview responsible personnel to determine recent changes/security patches.5.5.b For a sample of system components.3.2 Verify that documented approval by authorized parties is present for each sampled change.5. 6. 1 through 6. Having staff knowledgeable of secure coding guidelines should minimize the number of security vulnerabilities introduced through poor coding practices. Payment Card Industry (PCI) Data Security Standard. Page 58 April 2015 .5. including how to avoid common coding vulnerabilities. The vulnerabilities identified in 6. Testing Procedures 6.5.10 are the minimum controls that should be in place.d. As industry-accepted secure coding practices change. Training for developers may be provided in-house or by third parties and should be applicable for technology used. Develop applications based on secure coding guidelines.5. It is up to the organization to remain up to date with vulnerability trends and incorporate appropriate measures into their secure coding practices. organizational coding practices and developer training should likewise be updated to address new threats—for example.10 were current with industry best practices when this version of PCI DSS was published.5. Note: The vulnerabilities listed at 6.PCI DSS Requirements 6.5 Address common coding vulnerabilities in software-development processes as follows: Train developers in secure coding techniques.10 provide a minimum baseline. v3. SANS CWE Top 25.1 through 6. LLC.c Examine records of training to verify that software developers received training on secure coding techniques.1 through 6.5. the OWASP Guide.5. and understanding how sensitive data is handled in memory. Application developers should be properly trained to identify and resolve issues related to these (and other) common coding vulnerabilities. the current best practices must be used for these requirements. and organizations should incorporate the relevant secure coding practices as applicable to the particular technology in their environment. etc.1 © 2006-2015 PCI Security Standards Council. 6. Verify that processes are in place to protect applications from. CERT Secure Coding. at a minimum.5. 6. as industry best practices for vulnerability management are updated (for example.).a Examine software-development policies and procedures to verify that training in secure coding techniques is required for developers. memory scraping attacks. based on industry best practices and guidance.b Interview a sample of developers to verify that they are knowledgeable in secure coding techniques. and understanding how sensitive data is handled in memory. Requirements 6. 6. including how to avoid common coding vulnerabilities. However.5.5.5. All Rights Reserved. the following vulnerabilities: Guidance The application layer is high-risk and may be targeted by both internal and external threats. below. 6. Information should be validated before being sent to the application—for example. 6. particularly SQL injection. and allows the attacker to attack components inside the network through the application.2 Buffer overflows 6. mix of alpha and numeric characters.5.1 Injection flaws.PCI DSS Requirements Testing Procedures Guidance Note: Requirements 6.1 © 2006-2015 PCI Security Standards Council.2 Examine software-development policies and procedures and interview responsible personnel to verify that buffer overflows are addressed by coding techniques that include: Validating buffer boundaries. 6.5.3 Insecure cryptographic storage 6.5.5. LLC. Page 59 April 2015 . Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised. Buffer overflows occur when an application does not have appropriate bounds checking on its buffer space. If an attacker is able to exploit weak cryptographic processes.5.6. to initiate attacks such as buffer overflows.5.3 Examine software-development policies and procedures and interview responsible personnel to verify that insecure cryptographic storage is addressed by coding techniques that: Prevent cryptographic flaws.1 Examine software-development policies and procedures and interview responsible personnel to verify that injection flaws are addressed by coding techniques that include: Validating input to verify user data cannot modify meaning of commands and queries. and exposing authentication credentials and/or cardholder data. Injection flaws. Utilizing parameterized queries. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system.1 through 6. This can cause the information in the buffer to be pushed out of the buffer’s 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. apply to all applications (internal or external). Truncating input strings. Use strong cryptographic algorithms and keys. 6. particularly SQL injection. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Also consider OS Command Injection. Payment Card Industry (PCI) Data Security Standard. etc. they may be able to gain clear-text access to encrypted data. All Rights Reserved.5. are a commonly used method for compromising applications. v3. or to reveal both confidential information and server application functionality.5. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data. LDAP and XPath injection flaws as well as other injection flaws. by checking for all alpha characters. both internally and externally (public) facing. or crash the server.5. Attackers use this weakness to steal sensitive data or compromise the system altogether.5. they may be able to gain control of an application or even gain clear-text access to encrypted data. XSS allows attackers to execute script in the victim's browser. the message "incorrect password provided" tells an attacker the user ID provided was accurate and that they should focus their efforts only on the password. LLC.7 Examine software-development policies and procedures and interview responsible personnel to verify that cross-site scripting (XSS) is addressed by coding techniques that include Validating all parameters before inclusion Utilizing context-sensitive escaping.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications. below.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6. XSS flaws occur whenever an application takes user-supplied data and sends it to a web browser without first validating or encoding that content. Use more generic error messages. as identified in PCI DSS Requirement 6. Page 60 April 2015 . Note: Requirements 6.5 Improper error handling 6.5. v3. cause security to fail. they can gain detailed system information.5 Examine software-development policies and procedures and interview responsible personnel to verify that improper error handling is addressed by coding techniques that do not leak information via error messages (for example. or expose privileged information through improper error handling methods. apply to web applications and application interfaces (internal or external): 6.5.1) to be “high risk” and that could affect the application should be identified and addressed during application development.7 Cross-site scripting (XSS) 6.1 © 2006-2015 PCI Security Standards Council. If an attacker is able to exploit weak cryptographic processes. deface web sites. which can hijack user sessions. 6. For example. have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise.5.6 Examine software-development policies and procedures and interview responsible personnel to verify that coding techniques address any “high risk” vulnerabilities that could affect the application.7 through 6.4 Insecure communications 6. All Rights Reserved. All vulnerabilities identified by an organization’s vulnerability risk-ranking process (defined in Requirement 6. create denialof-service interruptions.5. possibly introduce worms. Payment Card Industry (PCI) Data Security Standard. If a malicious individual can create errors that the application does not handle properly. like "data could not be verified. Applications can unintentionally leak information about their configuration or internal workings. Applications that fail to adequately encrypt network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data.PCI DSS Requirements Testing Procedures Guidance 6. 6. Web applications.10.1). by returning generic rather than specific error details).5.1.5.5.5. etc." 6. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. as a URL or form parameter.8 Examine software-development policies and procedures and interview responsible personnel to verify that improper access control—such as insecure direct object references. Attackers can manipulate those references to access other objects without authorization.PCI DSS Requirements 6. 6. A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application. v3. Only authorized users should be permitted to access direct object references to sensitive resources. failure to restrict URL access. If user interfaces permit access to unauthorized functions. directory traversal. failure to restrict URL access. LLC. Limiting access to data resources will help prevent cardholder data from being presented to unauthorized resources. and directory traversal—is addressed by coding technique that includes: A direct object reference occurs when a developer exposes a reference to an internal implementation object. or even authenticating to the application).5.5. Page 61 April 2015 .8 Improper access control (such as insecure direct object references. and failure to restrict user access to functions). directory. All Rights Reserved. Consistently enforce access control in presentation layer and business logic for all URLs. database record. the only way an application protects sensitive functionality is by preventing the display of links or URLs to unauthorized users. which then enables the attacker to perform any state-changing operations the victim is authorized to perform (such as updating account details. Frequently.1 © 2006-2015 PCI Security Standards Council. or key. this access could result in unauthorized individuals gaining access to privileged credentials or cardholder data. Payment Card Industry (PCI) Data Security Standard. Testing Procedures Guidance 6. making purchases.5. such as a file. Proper authentication of users Sanitizing input Not exposing internal object references to users User interfaces that do not permit access to unauthorized functions.9 Cross-site request forgery (CSRF) 6.9 Examine software development policies and procedures and interview responsible personnel to verify that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.5. An attacker may be able to enumerate and navigate the directory structure of a website (directory traversal) thus gaining access to unauthorized information as well as gaining further insight into the workings of the site for later exploitation. address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: 6. . as long as the reviewers specialize in application security and can demonstrate independence from the development team.5. a web-application firewall) is in place as follows: .10 Examine software development policies and procedures and interview responsible personnel to verify that broken authentication and session management are addressed via coding techniques that commonly include: Note: Requirement 6. All Rights Reserved. This can be achieved through a combination of technology and process.Is situated in front of public-facing web applications to detect and prevent web-based attacks. after which it becomes a requirement.6 For public-facing web applications.10 Broken authentication and session management 6.That the application is re-evaluated after the corrections. Used in conjunction with a network-based firewall.That all vulnerabilities are corrected . .PCI DSS Requirements Testing Procedures 6. Flagging session tokens (for example cookies) as “secure” Guidance Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials. Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities Web-application firewalls filter and block nonessential traffic at the application layer. or session tokens that would otherwise enable the intruder to assume the identity of an authorized user. or generate an alert that is immediately investigated. at least annually and after any changes Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.After any changes . a webapplication firewall) in front of publicfacing web applications. Payment Card Industry (PCI) Data Security Standard.That. all vulnerabilities in Requirement 6.5.At least annually .6 For public-facing web applications. at a minimum. interview personnel. Not exposing session IDs in the URL Incorporating appropriate time-outs and rotation of session IDs after a successful login.2.5 are included in the assessment . to continually check all traffic. ensure that either one of the following methods is in place as follows: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods. 6.10 is a best practice until June 30. 2015. Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example. Examine documented processes. keys. and examine records of application security assessments to verify that public-facing web applications are reviewed—using either manual or automated vulnerability security assessment tools or methods—as follows: . v3. The requirement for reviewing applications or installing web-application firewalls is intended to reduce the number of compromises on public-facing web applications due to poor coding or application management practices.Is configured to either block web-based attacks. . which is to prevent attacks. and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured.Is actively running and up to date as applicable. Process-based solutions must have mechanisms that facilitate timely responses to alerts in order to meet the intent of this requirement. Installing an automated technical solution that detects and prevents webbased attacks (for example.By an organization that specializes in application security .Is generating audit logs.1 © 2006-2015 PCI Security Standards Council.5. Page 62 April 2015 . Note: “An organization that specializes in application security” can be either a third-party company or an internal organization. LLC. Public-facing web applications are primary targets for attackers. All Rights Reserved. in use.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented. In use. Guidance Personnel need to be aware of and following security policies and operational procedures to ensure systems and applications are securely developed and protected from vulnerabilities on a continuous basis.7 Examine documentation and interview personnel to verify that security policies and operational procedures for developing and maintaining secure systems and applications are: Documented. LLC. Payment Card Industry (PCI) Data Security Standard. v3. Page 63 April 2015 .PCI DSS Requirements 6. Testing Procedures 6. and known to all affected parties. and Known to all affected parties.1 © 2006-2015 PCI Security Standards Council. 2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.1. administrator. Level of privilege required (for example. user.1 Select a sample of roles and verify access needs for each role are defined and include: System components and data resources that each role needs to access for their job function Identification of privilege necessary for each role to perform their job function.1 © 2006-2015 PCI Security Standards Council. call center personnel. When assigning privileged IDs.1.4 as follows: Defining access needs and privilege assignments for each role Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities Assignment of access based on individual personnel’s job classification and function Guidance The more people who have access to cardholder data. In order to limit access to cardholder data to only those individuals who need such access.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. and the level of privilege each role needs to effectively perform assigned tasks.) for accessing resources. the systems/devices/data each role needs access to. Documented approval (electronically or in writing) by authorized parties for all access. and verify that the policy incorporates 7. LLC. 7.1. 7. v3. 7. it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator. All Rights Reserved. store clerk).1 through 7.1.1. For example. individuals can be granted access accordingly.2. Payment Card Industry (PCI) Data Security Standard. systems and processes must be in place to limit access based on need to know and according to job responsibilities.Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need to know To ensure critical data can only be accessed by authorized personnel.1 Examine written policy for access control.1.a Interview personnel responsible for assigning access to verify that access to privileged user IDs is: Assigned only to roles that specifically require such privileged access Restricted to least privileges necessary to perform job responsibilities. etc. Once roles and corresponding access needs are defined. Testing Procedures 7. including listing of specific privileges approved. system administrator. PCI DSS Requirements 7. the more risk there is that a user’s account will be used maliciously. first it is necessary to define access needs for each role (for example. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice. “Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.1 Define access needs for each role. (Continued on next page) Page 64 April 2015 . including: System components and data resources that each role needs to access for their job function 7. 4 Require documented approval by authorized parties specifying required privileges.1.4 Select a sample of user IDs and compare with documented approvals to verify that: Documented approval (for example.b Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are: Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. 7.2. a user may unknowingly be granted access to cardholder data. 7.1).1.2. An access control system automates the process of restricting access and assigning privileges.2 Assignment of privileges to individuals based on job classification and function. 7.3 Assign access based on individual personnel’s job classification and function.1 Coverage of all system components 7. Page 65 April 2015 .2 Establish an access control system for systems components that restricts access based on a user’s need to know. 7.1. LLC. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID. Documented approval exists for the assigned privileges The approval was by authorized parties That specified privileges match the roles assigned to the individual.2.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows: This access control system must include the following: 7. Additionally. Without a mechanism to restrict access based on user’s need to know. 7. and that their access is necessary for their job function.1. 7.” thereby permitting access unless/until a rule is written to specifically deny it. and is set to “deny all” unless specifically allowed. it is easy to grant individuals access according to their job classification and function by using the already-created roles.1 © 2006-2015 PCI Security Standards Council. Note: Some access control systems are set by default to “allow-all. 7.1. 7.2. a default “deny-all” setting ensures no one is granted access until and unless a rule is established specifically granting such access.2.2.3 Confirm that the access control systems have a default “deny-all” setting. in writing or electronically) assures that those with access and privileges are known and authorized by management.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function. Once needs are defined for user roles (per PCI DSS requirement 7. 7. 7. Necessary for that individual’s job function Restricted to least privileges necessary to perform job responsibilities. v3.3 Default “deny-all” setting.2. Payment Card Industry (PCI) Data Security Standard.1. All Rights Reserved.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.1 Confirm that access control systems are in place on all system components.PCI DSS Requirements Testing Procedures Guidance 7. and known to all affected parties. v3. All Rights Reserved.PCI DSS Requirements 7. on a continuous basis.3 Examine documentation and interview personnel to verify that security policies and operational procedures for restricting access to cardholder data are: Documented. LLC. Guidance Personnel need to be aware of and following security policies and operational procedures to ensure that access is controlled and based on needto-know and least privilege. In use. and Known to all affected parties.1 © 2006-2015 PCI Security Standards Council. in use.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented. Payment Card Industry (PCI) Data Security Standard. Page 66 April 2015 . Testing Procedures 7. 1. To ensure that user accounts granted access to systems are all valid and recognized users. including adding new ones and modifying or deleting existing ones.1. 8.5. v3.1 Interview administrative personnel to confirm that all users are assigned a unique ID for access to system components or cardholder data.1.8 are not intended to apply to user accounts within a point-ofsale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts). 8.1.a Review procedures and confirm they define processes for each of the items below at 8.b Verify that procedures are implemented for user identification management. for support or maintenance).2 For a sample of privileged user IDs and general user IDs. 8. etc. strong processes must manage all changes to user IDs and other authentication credentials. examine associated authorizations and observe system settings to verify each user ID and privileged user ID has been implemented with only the privileges specified on the documented approval. Page 67 April 2015 . and review current user access lists—for both local and remote access—to verify that their IDs have been deactivated or removed from the access lists. actions taken on critical data and systems are performed by.6 through 8.2.1.3. and while in storage. with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. including point-of-sale accounts.2 Control addition.1. Requirements 8. 8. Payment Card Industry (PCI) Data Security Standard. However.1.b Verify all physical authentication methods—such as. credentials.1. and modification of user IDs. and the security methods to protect user passwords at the point of entry. LLC.2. 8.1. tokens. Note: These requirements are applicable for all accounts.1.3 through 8. how frequently password attempts can be made by an attacker. 8. known and authorized users and processes.Requirement 8: Identify and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions.2. 8.1.8 8. 8. smart cards.1 Define and implement policies and procedures to ensure proper user identification management for nonconsumer users and administrators on all system components as follows: Testing Procedures 8.1.5. during transmission. 8.1. To prevent unauthorized access. 8. and can be traced to. All Rights Reserved. This will help speed issue resolution and containment when misuse or malicious intent occurs.1 through 8. deletion. and other identifier objects.1. unnecessary or malicious access to cardholder data could occur—either by the former employee or by a malicious user who exploits the old and/or unused account. If an employee has left the company and still has access to the network via their user account.a Select a sample of users terminated in the past six months.3.1.—have been returned or deactivated.3 Immediately revoke access for any terminated users. When such accountability is in place. This includes accounts used by vendors and other third parties (for example.1 © 2006-2015 PCI Security Standards Council. PCI DSS Requirements 8. and 8.1 Assign all users a unique ID before allowing them to access system components or cardholder data. user credentials and other authentication methods therefore need to be revoked promptly (as soon as possible) upon the employee’s departure. The effectiveness of a password is largely determined by the design and implementation of the authentication system—particularly. by performing the following: Guidance By ensuring each user is uniquely identified— instead of using one ID for several employees—an organization can maintain individual responsibility for actions and an effective audit trail per employee. 1. If an account is locked out due to someone continually trying to guess a password.1. 8. or maintain system components to verify that accounts used by vendors for remote access are: Allowing vendors to have 24/7 access into your network in case they need to support your systems increases the chances of unauthorized access.1 © 2006-2015 PCI Security Standards Council. until they achieve success and gain access to a user’s account. 8.4 Observe user accounts to verify that any inactive accounts over 90 days old are either removed or disabled.b Interview personnel and observe processes to verify that vendor remote access accounts are monitored while being used. the admin or help desk can validate that it is the actual account owner requesting reactivation.1. 8. inspect system configuration settings to verify that password parameters are set to require that once a user account is locked out. As such. 8. inspect system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than six invalid logon attempts.1. 8. and disabled when not in use. support.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation.1. Payment Card Industry (PCI) Data Security Standard.4 Remove/disable inactive user accounts within 90 days.6. and disabling it as soon as it is no longer needed.b is an additional procedure that only applies if the entity being assessed is a service provider. Note: Testing Procedure 8. it remains locked for a minimum of 30 minutes or until a system administrator resets the account. Monitoring of vendor access provides assurance that vendors are accessing only the systems necessary and only during approved time frames. Additionally. 8. Enabled only during the time period needed and disabled when not in use. or maintain system components via remote access as follows: 8. support. and observe implemented processes to verify that non-consumer customer user accounts are temporarily locked-out after not more than six invalid access attempts.7 For a sample of system components.a Interview personnel and observe processes for managing accounts used by vendors to access. 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). if reactivation must be requested. Disabled when not in use Enabled only when needed by the vendor.6.5 Manage IDs used by vendors to access.6.5.a For a sample of system components.1. password cracking). 8. helps prevent misuse of these connections.5.PCI DSS Requirements Testing Procedures Guidance 8.1. All Rights Reserved.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. Enabling access only for the time periods needed. Without account-lockout mechanisms in place.1. these accounts may be more easily exploited and used to access cardholder data.1. LLC. Accounts that are not used regularly are often targets of attack since it is less likely that any changes (such as a changed password) will be noticed.1. v3. an attacker can continually attempt to guess a password through manual or automated tools (for example. either from a user in the vendor’s environment or from a malicious individual who finds and uses this always-available external entry point into your network. Page 68 April 2015 . Monitored when in use. 8.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.1. resulting in unauthorized account access and/or misuse. These authentication methods. such as a password or passphrase Something you have. a password/phrase) for access to the cardholder data environment. LLC. 8.8 If a session has been idle for more than 15 minutes. Note that a digital certificate is a valid option for “something you have” as long as it is unique for a particular user. it is important to implement good processes for authentication management. Guidance When users walk away from an open machine with access to critical system components or cardholder data.1. 8. when used in addition to unique IDs. such as a biometric.1. or at the application level. require the user to re-authenticate to re-activate the terminal or session.8 For a sample of system components. The re-authentication can be applied either at the system level to protect all sessions running on that machine. ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: Something you know. Page 69 April 2015 .1 © 2006-2015 PCI Security Standards Council.2 In addition to assigning a unique ID. inspect system configuration settings to verify that system/session idle time out features have been set to 15 minutes or less.PCI DSS Requirements 8. since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used). v3. help protect users’ IDs from being compromised. All Rights Reserved. such as a token device or smart card Something you are. perform the following: Examine documentation describing the authentication method(s) used. Payment Card Industry (PCI) Data Security Standard. For each type of authentication method used and for each type of system component. Since one of the first steps a malicious individual will take to compromise a system is to exploit weak or nonexistent passwords. that machine may be used by others in the user’s absence.2 To verify that users are authenticated using unique ID and additional authentication (for example. observe an authentication to verify authentication is functioning consistent with documented authentication method(s). Testing Procedures 8. 1. web.a Examine vendor documentation and system configuration settings to verify that passwords are protected with strong cryptography during transmission and storage. readable passwords across the network and/or store passwords without encryption.1 © 2006-2015 PCI Security Standards Council. Consider use of a “secret question” that only the proper user can answer to help administrators identify the user prior to re-setting or modifying authentication credentials.2.PCI DSS Requirements 8.b For a sample of system components.” or directly access unencrypted passwords in files where they are stored.2 Examine authentication procedures for modifying authentication credentials and observe security personnel to verify that. 8.2. 8. LLC. provisioning new tokens.2.1. Testing Procedures 8. examine password files to verify that passwords are unreadable during storage.1 Using strong cryptography.1. if a user requests a reset of an authentication credential by phone.2.d and 8.d Additional testing procedure for service provider assessments only: Observe password files to verify that nonconsumer customer passwords are unreadable during storage. 8. Many malicious individuals use "social engineering”—for example.1.2. examine data transmissions to verify that passwords are unreadable during transmission.1.2.1. Page 70 April 2015 . A malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer. performing password resets. All Rights Reserved. 8.2. calling a help desk and acting as a legitimate user—to have a password changed so they can utilize a user ID. the user’s identity is verified before the authentication credential is modified.2 Verify user identity before modifying any authentication credential—for example. Guidance Many network devices and applications transmit unencrypted.e are additional procedures that only apply if the entity being assessed is a service provider. and use this data to gain unauthorized access. render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. 8.e Additional testing procedure for service provider assessments only: Observe data transmissions to verify that non-consumer customer passwords are unreadable during transmission.2. Payment Card Industry (PCI) Data Security Standard. or generating new keys.c For a sample of system components. Note: Testing Procedures 8. e-mail.2.1.2. v3. 8. or other non-face-to-face method. For cases where this minimum cannot be met due to technical limitations. inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least once every 90 days. 8.2.” This document and others that discuss “password entropy” can be referred to for more information on applicable entropy value and for understanding equivalent password strength variability for passwords/phrases of different formats.2. NIST SP 80063-1 defines “entropy” as “a measure of the difficulty of guessing or determining a password or key.2.PCI DSS Requirements Testing Procedures Guidance 8. If passwords are short or simple to guess.b is an additional procedure that only applies if the entity being assessed is a service provider. Require a minimum length of at least seven characters.3a For a sample of system components. Note: Testing Procedure 8. Non-consumer customer user passwords are required to change periodically. All Rights Reserved.1 © 2006-2015 PCI Security Standards Council. v3. passwords must change.b is an additional procedure that only applies if the entity being assessed is a service provider. 8. and Non-consumer customer users are given guidance as to when. inspect system configuration settings to verify that user password parameters are set to require at least the following strength/complexity: Strong passwords/phrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or nonexistent passwords.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that non-consumer customer passwords are required to meet at least the following strength/complexity: Require a minimum length of at least seven characters. Contain both numeric and alphabetic characters.4. Note: Testing Procedure 8.2. LLC.3.2. 8. Require a minimum length of at least seven characters.4. and under what circumstances.a For a sample of system components. This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/phrases.2.2. Contain both numeric and alphabetic characters.3.4 Change user passwords/passphrases at least once every 90 days. Alternatively. 8.4.2.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that: Passwords/phrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase. Page 71 April 2015 . Payment Card Industry (PCI) Data Security Standard.3 Passwords/phrases must meet the following: 8. entities can use “equivalent strength” to evaluate their alternative. Contain both numeric and alphabetic characters. it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID. the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above. 8. 8.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that new non-consumer customer user passwords cannot be the same as the previous four passwords.b is an additional procedure that only applies if the entity being assessed is a service provider. and reset passwords for existing users. Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens. and change immediately after the first use.6 Set passwords/phrases for firsttime use and upon reset to a unique value for each user. as previous passwords can be reused over and over. the effectiveness of changing passwords is reduced. Using one factor twice (for example. Two-factor authentication requires two forms of authentication for higher-risk accesses. 8.2. and other technologies that facilitate two-factor authentication.3 Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties.6 Examine password procedures and observe security personnel to verify that first-time passwords for new users. Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8. Payment Card Industry (PCI) Data Security Standard. such that remote users cannot access or impact the cardholder data environment.3. v3.2. All Rights Reserved. Note: Testing Procedure 8.b Observe a sample of personnel (for example. terminal access controller access control system (TACACS) with tokens. two-factor authentication for remote access to that network would not be required. 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.1 © 2006-2015 PCI Security Standards Council.5. two-factor authentication is required for any remote access to networks with access to the cardholder data environment. LLC. If remote access is to an entity’s network that has appropriate segmentation. users and administrators) connecting remotely to the network and verify that at least two of the three authentication methods are used.2. Requiring that passwords cannot be reused for a period of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future. an internal user. and vendors (for support or maintenance) with remote access to the network—where that remote access could lead to access to the cardholder data environment.2.2. If the same password is used for every new user. Page 72 April 2015 . are set to a unique value for each user and changed after first use. 8. such as those originating from outside the network This requirement is intended to apply to all personnel—including general users.2 for descriptions of authentication methods) be used for authentication. and use it to gain access to accounts. (including vendor access for support or maintenance). former employee. However. and is recommended for all remote access to the entity’s networks. Testing Procedures 8. Guidance If password history isn’t maintained.a For a sample of system components.5. 8.3.5.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.a Examine system configurations for remote access servers and systems to verify two-factor authentication is required for: All remote access by personnel All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes). or malicious individual may know or easily discover this password. using two separate passwords) is not considered two-factor authentication. 8.PCI DSS Requirements 8.2. administrators. user account and password).PCI DSS Requirements Testing Procedures 8. Instructing users to change passwords if there is a chance the password is no longer secure can prevent malicious users from using a legitimate password to gain unauthorized access.4. Shared user IDs do not exist for system administration and other critical functions. or having effective logging of. and that don’t contain information about the user (such as the user ID.c Interview system administrators to verify that group and shared IDs and/or passwords or other authentication methods are not distributed. v3.4.5. by calling an employee and asking for their password so the caller can “troubleshoot a problem”). 8. All Rights Reserved. Shared and generic user IDs are not used to administer any system components. an individual’s actions. examine user ID lists to verify the following: Generic user IDs are disabled or removed.).b Examine authentication policies and procedures to verify that use of group and shared IDs and/or passwords or other authentication methods are explicitly prohibited. For example. This in turn prevents an entity from assigning accountability for.b Review authentication policies and procedures that are distributed to users and verify they include: Guidance on selecting strong authentication credentials Guidance for how users should protect their authentication credentials. 8. Guidance on selecting strong authentication credentials Guidance for how users should protect their authentication credentials Instructions not to reuse previously used passwords Instructions to change passwords if there is any suspicion the password could be compromised. 8. etc. it becomes impossible to trace system access and activities to an individual.4.c Interview a sample of users to verify that they are familiar with authentication policies and procedures.a Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users. LLC.1 © 2006-2015 PCI Security Standards Council. Guidance for protecting authentication credentials may include not writing down passwords or saving them in insecure files. or other authentication methods as follows: Generic user IDs are disabled or removed. Payment Card Industry (PCI) Data Security Standard.a For a sample of system components. 8. date of birth. passwords. 8.5. shared.5 Do not use group. Page 73 April 2015 . guidance on selecting strong passwords may include suggestions to help personnel select hard-to-guess passwords that don’t contain dictionary words. names of family members. Shared and generic user IDs are not used to administer any system components. Instructions for users not to reuse previously used passwords Instructions to change passwords if there is any suspicion the password could be compromised.5. 8.4 Document and communicate authentication policies and procedures to all users including: 8. since a given action could have been performed by anyone in the group that has knowledge of the authentication credentials. and being alert for malicious individuals who may attempt to exploit their passwords (for example. or generic IDs. Guidance Communicating password/authentication policies and procedures to all users helps those users understand and abide by the policies. even if requested. Shared user IDs for system administration activities and other critical functions do not exist. If multiple users share the same authentication credentials (for example. To prevent the compromise of multiple customers through the use of a single set of credentials. it may be impossible to identify the individual using the authentication mechanism. via a single-use password) could also meet the intent of this requirement. or a password) to uniquely identify the user of the account will prevent unauthorized users from gaining access through use of a shared authentication mechanism. Guidance Note: This requirement applies only when the entity being assessed is a service provider.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example.6. 2015. If user authentication mechanisms such as tokens. such as two-factor mechanisms. after which it becomes a requirement. for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.a Examine authentication policies and procedures to verify that procedures for using authentication mechanisms such as physical security tokens. that provide a unique credential for each connection (for example. Technologies. Note: Requirement 8. and certificates can be used by multiple accounts. smart cards. where multiple customer environments are hosted.6 Where other authentication mechanisms are used (for example.1 © 2006-2015 PCI Security Standards Council. Payment Card Industry (PCI) Data Security Standard.5. Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access. physical or logical security tokens. certificates. a PIN. 8. etc. smart cards. v3. Page 74 April 2015 . Physical and/or logical controls are defined to ensure only the intended account can use that mechanism to gain access. All Rights Reserved. vendors with remote access accounts to customer environments should use a different authentication credential for each customer. Having physical and/or logical controls (for example.5. Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment. use of these mechanisms must be assigned as follows: Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. 8.5.). biometric data.1 is a best practice until June 30.PCI DSS Requirements 8.1 Additional testing procedure for service provider assessments only: Examine authentication policies and procedures and interview personnel to verify that different authentication credentials are used for access to each customer. and certificates are defined and include: Authentication mechanisms are assigned to an individual account and not shared among multiple accounts. Testing Procedures 8. smart cards. LLC. c Examine database access control settings and database application configuration settings to verify that user direct access to or queries of databases are restricted to database administrators. 8.a Review database and application configuration settings and verify that all users are authenticated prior to access. 8. rather than via direct access to the database by end users (except for DBAs. Payment Card Industry (PCI) Data Security Standard. Also. the potential for unauthorized or malicious access increases.b Examine database and application configuration settings to verify that all user access to.b Interview security personnel to verify authentication mechanisms are assigned to an account and not shared among multiple accounts. database access should be granted through programmatic methods only (for example. in use.6. Personnel need to be aware of and following security policies and operational procedures for managing identification and authorization on a continuous basis. All Rights Reserved. to verify that controls are implemented to ensure only the intended account can use that mechanism to gain access.7.d Examine database access control settings. through stored procedures). Without user authentication for access to databases and applications. and user actions on databases are through programmatic methods. v3.8 Examine documentation and interview personnel to verify that security policies and operational procedures for identification and authentication are: Documented. and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes). 8. who may need direct access to the database for their administrative duties).7. Page 75 April 2015 . copy.7. user queries of. and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. and Known to all affected parties.7 All access to any database containing cardholder data (including access by applications. 8.c Examine system configuration settings and/or physical controls. 8. LLC. and user actions on (for example. 8. Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes). database application configuration settings. 8. In use. and known to all affected parties. delete). Only database administrators have the ability to directly access or query databases. as applicable.8 Ensure that security policies and operational procedures for identification and authentication are documented. move. and all other users) is restricted as follows: All user access to.6. through stored procedures).1 © 2006-2015 PCI Security Standards Council.7. administrators. the database are through programmatic methods only (for example. 8.PCI DSS Requirements Testing Procedures Guidance 8. user queries of. or destroying records.Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies. Criminals attempting to gain physical access to sensitive areas will often attempt to disable or bypass the monitoring controls. (Continued on next page) Payment Card Industry (PCI) Data Security Standard. or anyone who needs to enter the facility for a short duration. Similarly. unless otherwise restricted by law. service workers. as well as when they entered and exited. data center.1 Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas. temporary employees. disrupt. Review collected data and correlate with other entries. PCI DSS Requirements 9. server room or any area that houses systems that store.1 © 2006-2015 PCI Security Standards Council. and should be appropriately restricted. such as the cashier areas in a retail store. 9. disable. A “visitor” refers to a vendor.1. video cameras could be positioned so they are out of reach and/or be monitored to detect tampering. “onsite personnel” refers to full-time and part-time employees.1. process. For the purposes of Requirement 9. usually not more than one day.a Verify that video cameras and/or access control mechanisms are in place to monitor the entry/exit points to sensitive areas. Guidance Without physical access controls. Verify that access is controlled with badge readers or other devices including authorized badges and lock and key. “Media” refers to all paper and electronic media containing cardholder data. altering system configurations. access control mechanisms could be monitored or have physical protections installed to prevent them being damaged or disabled by malicious individuals. v3. or destroy critical systems and cardholder data. unauthorized persons could potentially gain access to the facility to steal. Note: “Sensitive areas” refers to any data center. When investigating physical breaches.1.1.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. Store for at least three months. guest of any onsite personnel.b Verify that video cameras and/or access control mechanisms are protected from tampering or disabling.1. such as badge systems and door controls. LLC. or transmit cardholder data. This excludes public-facing areas where only point-ofsale terminals are present.1 Verify the existence of physical security controls for each computer room. Locking console login screens prevents unauthorized persons from gaining access to sensitive information. contractors and consultants who are physically present on the entity’s premises. Page 76 April 2015 . 9. these controls can help identify the individuals that physically accessed the sensitive areas. 9. All Rights Reserved. To protect these controls from tampering. and other physical areas with systems in the cardholder data environment. introducing vulnerabilities into the network. Testing Procedures 9. Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder environment and verify that they are “locked” to prevent unauthorized use. Restricting access to network jacks (or network ports) will prevent malicious individuals from plugging into readily available network jacks and gain access into internal network resources.1. and telecommunication lines is appropriately restricted. Payment Card Industry (PCI) Data Security Standard. Whether logical or physical controls. Sensitive areas should be identified by each organization to ensure the appropriate physical monitoring controls are implemented. and storage areas for large quantities of cardholder data. handheld devices.2 Interview responsible personnel and observe locations of publicly accessible network jacks to verify that physical and/or logical controls are in place to restrict access to publicly accessible network jacks. back-office rooms at retail locations that store cardholder data. LLC. Alternatively. 9. and telecommunication lines. gateways. gateways.3 Verify that physical access to wireless access points. Examples of sensitive areas include corporate database server rooms. Page 77 April 2015 . Testing Procedures Guidance 9.1. they should be sufficient to prevent an individual or device that is not explicitly authorized from being able to connect to the network. For example.1. v3.3 Restrict physical access to wireless access points.1.1. processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks. All Rights Reserved.c Verify that data from video cameras and/or access control mechanisms is reviewed. Additionally. or a combination of both. 9.1 © 2006-2015 PCI Security Standards Council. and that data is stored for at least three months. are used.1. networking/communications hardware. 9.PCI DSS Requirements 9. network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks. networking/communications hardware. malicious users could use an organization’s unattended wireless devices to access network resources. securing networking and communications hardware prevents malicious users from intercepting network traffic or physically connecting their own devices to wired network resources. or even connect their own devices to the wireless network to gain unauthorized access. handheld devices. Without security over access to wireless components and devices. and It is easy to distinguish between onsite personnel and visitors.. Controlling physical access to sensitive areas helps ensure that only authorized personnel with a legitimate business need are granted access.3. 9.b Observe personnel accessing sensitive areas to verify that all personnel are authorized before being granted access. interview responsible personnel and observe access control lists to verify that: Access to the sensitive area is authorized. v3. Verify procedures include the following: Identifying onsite personnel and visitors (for example. Access is required for the individual’s job function.2. 9.1 © 2006-2015 PCI Security Standards Council.c Select a sample of recently terminated employees and review access control lists to verify the personnel do not have physical access to sensitive areas.2 Develop procedures to easily distinguish between onsite personnel and visitors. 9.3. and all physical access mechanisms. assigning badges). LLC.b Examine identification methods (such as ID badges) and observe processes for identifying and distinguishing between onsite personnel and visitors to verify that: Visitors are clearly identified.a For a sample of onsite personnel with physical access to sensitive areas.Testing Procedures Guidance 9. all physical access mechanisms should be returned or disabled promptly (as soon as possible) upon their departure. 9. etc.2. assigning badges) Changes to access requirements Revoking or terminating onsite personnel and expired visitor identification (such as ID badges). PCI DSS Requirements 9. such as keys. Changing access requirements. When personnel leave the organization. Payment Card Industry (PCI) Data Security Standard. access cards.3 Control physical access for onsite personnel to sensitive areas as follows: Access must be authorized and based on individual job function. 9. are returned or disabled. to include: Identifying onsite personnel and visitors (for example.a Review documented processes to verify that procedures are defined for identifying and distinguishing between onsite personnel and visitors. Access is revoked immediately upon termination. and Revoking terminated onsite personnel and expired visitor identification (such as ID badges) 9.2. to ensure personnel cannot gain physical access to sensitive areas once their employment has ended. Page 78 April 2015 .3. Identifying authorized visitors so they are easily distinguished from onsite personnel prevents unauthorized visitors from being granted access to areas containing cardholder data.c Verify that access to the identification process (such as a badge system) is limited to authorized personnel. All Rights Reserved. PCI DSS Requirements 9. areas where cardholder data is processed or maintained.4. and escorted at all times within. 9.c Verify that the log is retained for at least three months.4 Implement procedures to identify and authorize visitors.2. Testing Procedures 9. 9. areas where cardholder data is processed or maintained. 9.a Observe people within the facility to verify the use of visitor badges or other identification.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted.4. and potential access to cardholder data.a Observe procedures and interview personnel to verify that visitors must be authorized before they are granted access to.1 © 2006-2015 PCI Security Standards Council. All Rights Reserved. Document the visitor’s name.4. Ensuring that visitor badges are returned upon expiry or completion of the visit prevents malicious persons from using a previously authorized pass to gain physical access into the building after the visit has ended. Retain this log for a minimum of three months. 9.2 Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel. LLC.1 Visitors are authorized before entering. 9.4. and escorted at all times within. 9. Payment Card Industry (PCI) Data Security Standard. and the onsite personnel authorizing physical access on the log.4. 9.4. Page 79 April 2015 .4.4.4.b Observe the use of visitor badges or other identification to verify that a physical token badge does not permit unescorted access to physical areas where cardholder data is processed or maintained.4. Guidance Visitor controls are important to reduce the ability of unauthorized and malicious persons to gain access to facilities (and potentially.2.a Verify that a visitor log is in use to record physical access to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted. unless otherwise restricted by law. 9. 9. 9.1. 9. A visitor log documenting minimum information on the visitor is easy and inexpensive to maintain and will assist in identifying physical access to a building or room.4. Visitor controls ensure visitors are identifiable as visitors so personnel can monitor their activities.4.1.4.b Verify that visitor badges or other identification expire. and The onsite personnel authorizing physical access.b Verify that the log contains: The visitor’s name.4.4 Verify that visitor authorization and access controls are in place as follows: Procedures should include the following: 9.3 Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration. to cardholder data). and that their access is restricted to just the duration of their legitimate visit. v3. the firm represented. and that visitors are easily distinguishable from onsite personnel.3 Observe visitors leaving the facility to verify visitors are asked to surrender their badge or other identification upon departure or expiration. The firm represented. PCI DSS Requirements 9.6 Verify that a policy exists to control distribution of media.b Verify that the storage location security is reviewed at least annually. or scanning if it is unprotected while it is on removable or portable media. or a commercial storage facility. or left on someone’s desk. and that the policy covers all distributed media including that distributed to individuals.6. preferably an off-site facility. All Rights Reserved.1 Store media backups in a secure location.6. Procedures and processes help protect cardholder data on media distributed to internal and/or external users. backups that contain cardholder data may easily be lost. Periodically reviewing the storage facility enables the organization to address identified security issues in a timely manner.5 Physically secure all media. copying. and verify tracking details are documented. the intent is that the organization has identified media that contains sensitive data so it can protect it. It is important that media be identified such that its classification status can be easily discernible.a Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked. Controls for physically securing media are intended to prevent unauthorized persons from gaining access to cardholder data on any type of media.5.2 Send the media by secured courier or other delivery method that can be accurately tracked. paper receipts.1.6. paper reports. Page 80 April 2015 . Without such procedures data can be lost or stolen and used for fraudulent purposes. and faxes). such as an alternate or backup site. If stored in a non-secured facility. minimizing the potential risk. v3. including the following: 9. 9. 9. printed out.5. Testing Procedures Guidance 9. Cardholder data is susceptible to unauthorized viewing. 9. Use of secure couriers to deliver any media that contains cardholder data allows organizations to use their tracking systems to maintain inventory and location of shipments.1. Media may be lost or stolen if sent via a nontrackable method such as regular postal mail.5 Verify that procedures for protecting cardholder data include controls for physically securing all media (including but not limited to computers.b Select a recent sample of several days of offsite tracking logs for all media. removable electronic media. 9.5.6.6 Maintain strict control over the internal or external distribution of any kind of media.2.6.2. 9.1 © 2006-2015 PCI Security Standards Council. 9. 9. LLC. Payment Card Industry (PCI) Data Security Standard. or copied for malicious intent.a Observe the storage location’s physical security to confirm that backup media storage is secure. Media not identified as confidential may not be adequately protected or may be lost or stolen. Review the location’s security at least annually. stolen.1 Classify media so the sensitivity of the data can be determined. 9. 9. Note: This does not mean the media needs to have a “Confidential” label attached.1 Verify that all media is classified so the sensitivity of the data can be determined. If steps are not taken to destroy information contained on hard disks.6. Payment Card Industry (PCI) Data Security Standard. 9. For example.b Examine storage containers used for materials that contain information to be destroyed to verify that the containers are secured.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements for the following: Hard-copy materials must be crosscut shredded. For example. CD/DVDs.a Interview personnel and examine procedures to verify that hard-copy materials are crosscut shredded. or physical destruction (such as grinding or shredding hard disks).1 © 2006-2015 PCI Security Standards Council. If media is not inventoried. Securing storage containers used for materials that are going to be destroyed prevents sensitive information from being captured while the materials are being collected. and its location would be unknown. Cardholder data on electronic media must be rendered unrecoverable (e. Storage containers used for materials that are to be destroyed must be secured. or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed. 9. All Rights Reserved.7.1. stolen or missing media could go unnoticed for an indefinite amount of time.2 Verify that cardholder data on electronic media is rendered unrecoverable (e.g.1 Shred. Page 81 April 2015 . 9. 9.8.8. Examples of methods for securely destroying electronic media include secure wiping. v3. or paper prior to disposal.. leading to lost or stolen media. or by physically destroying the media).8.3 Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals). incinerate. From examination of the logs and interviews with responsible personnel. degaussing. 9. incinerated. 9. or pulp hardcopy materials so that cardholder data cannot be reconstructed.7 Maintain strict control over the storage and accessibility of media..3 Select a recent sample of several days of offsite tracking logs for all media.8. malicious individuals may use a technique known as “dumpster diving.1. “to-be-shredded” containers could have a lock preventing access to its contents or physic ally prevent access to the inside of the container.8 Destroy media when it is no longer needed for business or legal reasons as follows: 9.7. LLC. 9. verify proper management authorization is obtained whenever media is moved from a secured area (including when media is distributed to individuals).7 Obtain and examine the policy for controlling storage and maintenance of all media and verify that the policy requires periodic media inventories. 9.6.8. incinerated. Guidance Without a firm process for ensuring that all media movements are approved before the media is removed from secure areas. stolen or lost media may not be noticed for a long time or at all. Without careful inventory methods and storage controls. the media would not be tracked or appropriately protected. portable drives. or pulped such that there is reasonable assurance the hardcopy materials cannot be reconstructed. or by physically destroying the media).PCI DSS Requirements Testing Procedures 9. via a secure wipe program in accordance with industry-accepted standards for secure deletion. 9. 9. Secure storage containers used for materials that are to be destroyed. malicious individuals may be able to retrieve information from the disposed media.g.” where they search through trashcans and recycle bins looking for information they can use to launch an attack.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed.1 Properly maintain inventory logs of all media and conduct media inventories at least annually. leading to a data compromise.1 Review media inventory logs to verify that logs are maintained and media inventories are performed at least annually. 9. via a secure wipe program in accordance with industry-accepted standards for secure deletion. 9. Note: Requirement 9. transactions may still be completed without interruption while the criminal is “skimming” the payment card information during the process. 2015. after which it becomes a requirement. decommissioned.9.9 Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. Note: These requirements apply to cardreading devices used in card-present transactions (that is. a device-management system) or manual (for example.1. the address of the site or facility where the device is located) Device serial number or other method of unique identification.9 is a best practice until June 30.c Interview personnel to verify the list of devices is updated when devices are added. Device serial number or other method of unique identification. Testing Procedures 9. for manual key-entry components such as computer keyboards and POS keypads. 9.1.1 © 2006-2015 PCI Security Standards Council.1 Maintain an up-to-date list of devices. they will try to steal devices so they can learn how to break into them.PCI DSS Requirements 9. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.b Select a sample of devices from the list and observe devices and device locations to verify that the list is accurate and up to date. etc. The list should include the following: 9. which are designed to capture payment card details before they even enter the device—for example. the location may include the name of the personnel to whom the device is assigned. For example. v3.9 Examine documented policies and procedures to verify they include: Maintaining a list of devices Periodically inspecting devices to look for tampering or substitution Training personnel to be aware of suspicious behavior and to report tampering or substitution of devices. All Rights Reserved. Criminals will also try to add “skimming” components to the outside of devices. model of device Make. LLC. Page 82 April 2015 . model of device Location of device (for example. Keeping an up-to-date list of devices helps an organization keep track of where devices are supposed to be.1. and they often try to replace legitimate devices with fraudulent devices that send them payment card information every time a card is entered. 9. and quickly identify if a device is missing or lost. For on-the-road devices. The method for maintaining a list of devices may be automated (for example. but not required.9. Guidance Criminals attempt to steal cardholder data by stealing and/or manipulating card-reading devices and terminals. Payment Card Industry (PCI) Data Security Standard. 9. by attaching an additional card reader on top of the legitimate card reader so that the payment card details are captured twice: once by the criminal’s component and then by the device’s legitimate component. the address of the site or facility where the device is located) Location of device (for example.a Examine the list of devices to verify it includes: Make. documented in electronic or paper records). In this way.9. This requirement is recommended. card swipe or dip) at the point of sale. Additional best practices on skimming prevention are available on the PCI SSC website. relocated. Page 83 April 2015 . photographs of devices that are known to be secure can be used to compare a device’s current appearance with its original appearance to see whether it has changed. or changes to the serial number or other external markings.1 © 2006-2015 PCI Security Standards Council. All Rights Reserved. devices left in public areas without supervision by the organization’s personnel may have more frequent inspections than devices that are kept in secure areas or are supervised when they are accessible to the public. v3. and these methods may help to detect such activities. broken or differently colored casing. by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).9.9.2. For example. or substitution (for example. Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device. and thereby minimize the potential impact of using fraudulent devices. Payment Card Industry (PCI) Data Security Standard. Device vendors may also be able to provide security guidance and “how to” guides to help determine whether the device has been tampered with. The type of inspection will depend on the device— for example. Guidance Regular inspections of devices will help organizations to more quickly detect tampering or replacement of a device. addition of card skimmers to devices). The frequency of inspections will depend on factors such as location of device and whether the device is attended or unattended. missing or changed security labels.2 Periodically inspect device surfaces to detect tampering (for example. such as a UV light marker. Testing Procedures 9. All devices are periodically inspected for evidence of tampering and substitution. as defined by their annual risk-assessment process. to mark device surfaces and device openings so any tampering or replacement will be apparent.b Interview responsible personnel and observe inspection processes to verify: Personnel are aware of procedures for inspecting devices.a Examine documented procedures to verify processes are defined to include the following: Procedures for inspecting devices Frequency of inspections. LLC. Criminals will often replace the outer casing of a device to hide their tampering.9. Another option may be to use a secure marker pen. 9.2. The type and frequency of inspections is determined by the merchant.PCI DSS Requirements 9. Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example. attempts by unknown persons to unplug or open devices) Do not install. replace. attempts by unknown persons to unplug or open devices) Another trick criminals like to use is to send a “new” POS system with instructions for swapping it with a legitimate system and “returning” the legitimate system to a specified address. Many criminals will try to fool personnel by dressing for the part (for example.b Interview a sample of personnel at point-of-sale locations to verify they have received training and are aware of the procedures for the following: Verifying the identity of any third-party persons claiming to be repair or maintenance personnel. 9.9. to a manager or security officer). Not to install.3. Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example. Personnel need to be aware of and following security policies and operational procedures for restricting physical access to cardholder data and CDE systems on a continuous basis. Be aware of suspicious behavior around devices (for example. in use. and Known to all affected parties. attempts by unknown persons to unplug or open devices). Page 84 April 2015 . prior to granting them access to modify or troubleshoot devices.3. prior to granting them access to modify or troubleshoot devices Not to install. so it’s important personnel are trained to follow procedures at all times. and could also be knowledgeable about locations of devices. Payment Card Industry (PCI) Data Security Standard.9.a Review training materials for personnel at point-of-sale locations to verify they include training in the following: Verifying the identity of any third-party persons claiming to be repair or maintenance personnel. All third parties requesting access to devices should always be verified before being provided access—for example. to a manager or security officer). and known to all affected parties. to a manager or security officer). v3.10 Examine documentation and interview personnel to verify that security policies and operational procedures for restricting physical access to cardholder data are: Documented. Personnel always verify with their manager or supplier that the device is legitimate and came from a trusted source before installing it or using it for business. 9.PCI DSS Requirements Testing Procedures Guidance 9. 9. replace. by checking with management or phoning the POS maintenance company (such as the vendor or acquirer) for verification. All Rights Reserved.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. or return devices without verification Being aware of suspicious behavior around devices (for example. The criminals may even provide return postage as they are very keen to get their hands on these devices. LLC. Training should include the following: 9. prior to granting them access to modify or troubleshoot devices Criminals will often pose as authorized maintenance personnel in order to gain access to POS devices. carrying toolboxes and dressed in work wear). replace. Verify the identity of any third-party persons claiming to be repair or maintenance personnel. or return devices without verification. or return devices without verification Being aware of suspicious behavior around devices (for example.10 Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented. Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example.1 © 2006-2015 PCI Security Standards Council. In use.9. 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 in preventing. or they could create a new. It is critical to have a process or system that links user access to system components accessed. v3. and analysis when something does go wrong. Page 85 April 2015 . that: 10. have the potential to greatly impact the security or operational functionality of a system. Without a log of the activities performed.1 Verify all individual access to cardholder data is logged. such as the “administrator” or “root” account.2 Verify all actions taken by any individual with root or administrative privileges are logged. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user. through observation and interviewing the system administrator. Malicious individuals could obtain knowledge of a user account with access to systems in the CDE.2. or minimizing the impact of a data compromise. sends data to other monitoring mechanisms (like intrusion detection systems).2 All actions taken by any individual with root or administrative privileges 10. unauthorized account in order to access cardholder data. The presence of logs in all environments allows thorough tracking. Accounts with increased privileges. All Rights Reserved. and examination of audit log settings. LLC. Logging of the following events enables an organization to identify and trace potentially malicious activities 10.2.2 Implement automated audit trails for all system components to reconstruct the following events: 10. and provides a history trail for postincident follow-up. detecting. without system activity logs.1 Verify.2.1 © 2006-2015 PCI Security Standards Council.2.1 All individual user accesses to cardholder data 10. alerting. if not impossible.1 Implement audit trails to link all access to system components to each individual user. 10. observation of audit logs. perform the following: Generating audit trails of suspect activities alerts the system administrator. Audit trails are enabled and active for system components. 10. Access to system components is linked to individual users. PCI DSS Requirements Testing Procedures Guidance 10. an organization is unable to trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and individual. Payment Card Industry (PCI) Data Security Standard. A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused.2 Through interviews of responsible personnel. Determining the cause of a compromise is very difficult. PCI DSS Requirements Testing Procedures Guidance 10.5. 10.6 Initialization.3 Access to all audit trails 10. Additionally. additions.7 Verify creation and deletion of system level objects are logged.3 Verify access to all audit trails is logged.1 © 2006-2015 PCI Security Standards Council.2.2.2. stopping.2. are created or deleted.2.b Verify all elevation of privileges is logged. it will be easier to determine whether such modifications were authorized. or pausing of the audit logs 10. Malicious individuals will often perform multiple access attempts on targeted systems. LLC.2.2. additions. Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection.2.c Verify all changes. v3. and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account.2. By logging when system-level objects.2. 10. such as malware.4 Verify invalid logical access attempts are logged. it is impossible to identify the accounts that may have been used. All Rights Reserved. Without knowing who was logged on at the time of an incident.4 Invalid logical access attempts 10. additions. Malicious users often attempt to alter audit logs to hide their actions. malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account. 10. or deletions to accounts with root or administrative privileges 10. Page 86 April 2015 . often creates or replaces system level objects on the target system in order to control a particular function or operation on that system. 10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes. Payment Card Industry (PCI) Data Security Standard.2. and deletions can help retrace steps made by unauthorized personnel. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions. Initialization of audit logs Stopping or pausing of audit logs. such as database tables or stored procedures.7 Creation and deletion of systemlevel objects 10.6 Verify the following are logged: 10. Multiple invalid login attempts may be an indication of an unauthorized user’s attempts to “brute force” or guess a password. or deletions to any account with root or administrative privileges are logged.5. Malicious software.a Verify use of identification and authentication mechanisms is logged. 10.5. Having access to logs identifying changes. synchronize all critical system clocks and times and ensure that the following is implemented for acquiring. it can be difficult.4 Verify success or failure indication is included in log entries.3.6 Identity or name of affected data. a potential compromise can be quickly identified. 10. 10. 10.1 User identification 10.1 and 6. Where there is more than one designated time server.3 Record at least the following audit trail entries for all system components for each event: Testing Procedures 10. 10. Guidance By recording these details for the auditable events at 10.3.1 © 2006-2015 PCI Security Standards Council.3.5 Verify origination of event is included in log entries. distributing and storing the correct time within the organization to verify that: Only the designated central time server(s) receives time signals from external sources. what. 10. and storing time.PCI DSS Requirements 10. All Rights Reserved. when.5 Origination of event 10. 10. Time synchronization technology is used to synchronize clocks on multiple systems.3. where. the accuracy and consistency of time across all systems and the time of each activity is critical in determining how the systems were compromised.2. When clocks are not properly synchronized. system component.4. 10.3 Verify date and time stamp is included in log entries.3. distributing. for each auditable event (from 10.4 Examine configuration standards and processes to verify that time-synchronization technology is implemented and kept current per PCI DSS Requirements 6. 10.2 Type of event 10. Systems receive time information only from designated central time server(s). Note: One example of time synchronization technology is Network Time Protocol (NTP).3.4 Using time-synchronization technology.3.a Examine the process for acquiring.2). or resource.3 Date and time 10.1 Critical systems have the correct and consistent time. 10. Payment Card Industry (PCI) Data Security Standard.2. v3.4.3. and with sufficient detail to know who.3.4 Success or failure indication 10. or resources is included in log entries.3. and how. 10. if not impossible.6 Verify identity or name of affected data. Page 87 April 2015 . and time signals from external sources are based on International Atomic Time or UTC.1 Verify user identification is included in log entries.3. perform the following: 10. LLC.3 Through interviews and observation of audit logs. For post-incident forensics teams.3. to compare log files from different systems and establish an exact sequence of event (crucial for forensic analysis in the event of a breach). the time servers peer with one another to keep accurate time.1. system component.2 Verify type of event is included in log entries. 10. Page 88 April 2015 . and time signals from external sources are based on International Atomic Time or UTC. 10.4. accuracy. time synchronization settings and logs.4. LLC.b Observe the time-related system-parameter settings for a sample of system components to verify: 10. 10.1. Only the designated central time server(s) receives time signals from external sources. industry-accepted external sources (to prevent a malicious individual from changing the clock).b Examine system configurations. and reviewed.4. and integrity cannot be guaranteed. All Rights Reserved.3 Time settings are received from industry-accepted time sources.4. 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). monitored.5 Secure audit trails so they cannot be altered.4. those updates can be encrypted with a symmetric key. the designated central time server(s) peer with one another to keep accurate time. and processes to verify that any changes to time settings on critical systems are logged.PCI DSS Requirements Testing Procedures Guidance 10. and the audit logs can be rendered useless as an investigation tool after a compromise. 10. Where there is more than one designated time server. their completeness.4. Optionally.2. 10.2.a Examine system configurations and timesynchronization settings to verify that access to time data is restricted to only personnel with a business need to access time data. Without adequate protection of audit logs. v3. Often a malicious individual who has entered the network will attempt to edit the audit logs in order to hide their activity.1 © 2006-2015 PCI Security Standards Council.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered as follows: Payment Card Industry (PCI) Data Security Standard. Systems receive time only from designated central time server(s). 10.2 Time data is protected.3 Examine systems configurations to verify that the time server(s) accept time updates from specific. 5. mail) are written onto a secure. as they are more secure within the internal network.5. The use of log harvesting.5.1 © 2006-2015 PCI Security Standards Council. Payment Card Industry (PCI) Data Security Standard. and alerting tools may be used to meet this Requirement.5. internal log server or media.1 Limit viewing of audit trails to those with a job-related need. 10. 10.5. 10. and results from monitoring activities to verify the use of file-integrity monitoring or change-detection software on logs. and use of physical or network segregation to make the logs harder to find and modify. centralized. 10.4 Write logs for external-facing technologies onto a secure.3 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter. File-integrity monitoring or change-detection systems check for changes to critical files. and mail servers. physical segregation.5. v3. monitored files. an entity usually monitors files that don’t regularly change. 10.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). the risk of those logs being lost or altered is lowered.5. and notify when such changes are noted. 10.1 Only individuals who have a job-related need can view audit trail files.2 Protect audit trail files from unauthorized modifications.5. firewalls. wireless. and alerting tools can help facilitate the process by identifying log events that need to be reviewed. firewalls. to the secure internal system or media.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter.5.4 Logs for external-facing technologies (for example.5 Examine system settings. parsing. DNS. Guidance Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only). Page 89 April 2015 . and/or network segregation. 10. but when changed indicate a possible compromise. DNS. LLC.6 Perform the following: Note: Log harvesting. Regular log reviews by personnel or automated means can identify and proactively address unauthorized access to the cardholder data environment.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms. 10.PCI DSS Requirements Testing Procedures 10. 10. Logs may be written directly. or offloaded or copied from external systems. For fileintegrity monitoring purposes. 10. The log review process does not have to be manual.6 Review logs and security events for all system components to identify anomalies or suspicious activity.5. centralized. Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating the logs becomes compromised. Many breaches occur over days or months before being detected. 10. internal log server or media device. parsing. By writing logs from external-facing technologies such as wireless. All Rights Reserved. 10. or transmit CHD and/or SAD Logs of all servers and system components that perform security functions (for example. intrusion-detection systems/intrusion-prevention systems (IDS/IPS).6. authentication servers.a Examine security policies and procedures to verify that procedures are defined for following up on exceptions and anomalies identified during the review process.1 Review the following at least daily: All security events Testing Procedures Guidance 10. v3. 10. firewalls. e-commerce redirection servers.).3 Follow up exceptions and anomalies identified during the review process. 10.PCI DSS Requirements 10.b Observe processes and interview personnel to verify that the following are reviewed at least daily: All security events Daily review of security events—for example. 10. Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems.a Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily. either manually or via log tools: Checking logs daily minimizes the amount of time and exposure of a potential breach. location. If exceptions and anomalies identified during the log-review process are not investigated.1. and logs from systems that perform security functions.3.6. etc.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy.6. and function of the device. as determined by the organization’s annual risk assessment. authentication servers.6.a Examine security policies and procedures to verify that procedures are defined for reviewing logs of all other system components periodically—either manually or via log tools—based on the organization’s policies and risk management strategy. Payment Card Industry (PCI) Data Security Standard. intrusion-detection systems/intrusion-prevention systems (IDS/IPS).1 © 2006-2015 PCI Security Standards Council.2. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed. etc. etc. All Rights Reserved. e-commerce redirection servers. intrusion-detection systems/intrusion-prevention systems (IDS/IPS).b Examine the organization’s risk-assessment documentation and interview personnel to verify that reviews are performed in accordance with organization’s policies and risk management strategy.). or transmit CHD and/or SAD All security events Logs of all critical system components Logs of all critical system components Logs of all servers and system components that perform security functions (for example. Logs of all system components that store. Logs of all system components that store. or transmit CHD and/or SAD Logs of all critical system components Logs of all servers and system components that perform security functions (for example. Note that the determination of “security event” will vary for each organization and may include consideration for the type of technology.) 10. notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components.6. etc.3. IDS/IPS.1. e-commerce redirection servers.6. firewalls.6. the entity may be unaware of unauthorized and potentially malicious activities that are occurring within their own network. process. 10. 10.6. is necessary to identify potential issues.2. LLC. The frequency of the reviews should be determined by an entity’s annual risk assessment. file-integrity monitoring (FIM) systems. authentication servers. such as firewalls. firewalls.6. Page 90 April 2015 . process. Logs of all system components that store. process. 7 Retain audit trail history for at least one year. 10. online.7. All Rights Reserved. Audit log retention policies Procedures for retaining audit logs for at least one year. Testing Procedures Guidance 10. and identify impacted systems or data. an entity can quickly identify and minimize impact of a data breach. with a minimum of three months immediately available online. resulting in longer time frames to restore log data. 10. and known to all affected parties. with a minimum of three months immediately available for analysis (for example.b Interview personnel and examine audit logs to verify that audit logs are retained for at least one year.c Interview personnel and observe processes to verify that at least the last three months’ logs are immediately available for analysis. archived.7. perform analysis. By having three months of logs immediately available.8 Examine documentation and interview personnel to verify that security policies and operational procedures for monitoring all access to network resources and cardholder data are: Documented. In use. and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. Page 91 April 2015 . Storing logs in off-line locations could prevent them from being readily available.1 © 2006-2015 PCI Security Standards Council.7.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented. or restorable from backup). and Known to all affected parties.PCI DSS Requirements 10. v3. Personnel need to be aware of and following security policies and daily operational procedures for monitoring all access to network resources and cardholder data on a continuous basis. 10. Payment Card Industry (PCI) Data Security Standard. 10.a Examine security policies and procedures to verify that they define the following: 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. LLC. in use. etc. Page 92 April 2015 . Whichever methods are used. (Continued on next page) Payment Card Industry (PCI) Data Security Standard. Note: Methods that may be used in the process include but are not limited to wireless network scans. or wireless IDS/IPS. NAC. and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. Knowing which wireless devices are authorized can help administrators quickly identify nonauthorized wireless devices.) Wireless devices attached to a network port or network device. by USB.b Verify that the methodology is adequate to detect and identify any unauthorized wireless access points.c If wireless scanning is utilized. Due to the ease with which a wireless access point can be attached to a network.1 © 2006-2015 PCI Security Standards Council. System components. or be attached directly to a network port or network device. these processes must be performed even when a policy exists prohibiting the use of wireless technology. including at least the following: WLAN cards inserted into system components Portable or mobile devices attached to system components to create a wireless access point (for example.1 Implement processes to test for the presence of wireless access points (802.1.1.1. the difficulty in detecting their presence. it can allow an attacker to easily and “invisibly” enter the network. network access control (NAC). Implementation and/or exploitation of wireless technology within a network are some of the most common paths for malicious users to gain access to the network and cardholder data.a Examine policies and procedures to verify processes are defined for detection and identification of both authorized and unauthorized wireless access points on a quarterly basis. 11. physical/logical inspections of system components and infrastructure. LLC. and being introduced by new software.1. 11. wireless IDS/IPS.d If automated monitoring is utilized (for example. If a wireless device or network is installed without a company’s knowledge. Testing Procedures Guidance 11. such as a switch or router. they must be sufficient to detect and identify both authorized and unauthorized devices. Unauthorized wireless devices may be hidden within or attached to a computer or other system component. and responding to the identification of unauthorized wireless access points helps to proactively minimize the exposure of CDE to malicious individuals. PCI DSS Requirements 11. etc. and the increased risk presented by unauthorized wireless devices. v3.11).). All Rights Reserved. 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. and detect and identify all authorized and unauthorized wireless access points on a quarterly basis. examine output from recent wireless scans to verify that: Authorized and unauthorized wireless access points are identified. and The scan is performed at least quarterly for all system components and facilities. Vulnerabilities are being discovered continually by malicious individuals and researchers. verify the configuration will generate alerts to notify personnel. processes.Requirement 11: Regularly test security systems and processes. 11. Any such unauthorized device could result in an unauthorized access point into the environment. 1. detailed physical inspection is difficult. Page 93 April 2015 .PCI DSS Requirements Testing Procedures Guidance 11. LLC. 11. However.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected. 11. 11.2. For example: In the case of a single standalone retail kiosk in a shopping mall. Payment Card Industry (PCI) Data Security Standard.b Interview responsible personnel and/or inspect recent wireless scans and related responses to verify action is taken when unauthorized wireless access points are found.1 Examine documented records to verify that an inventory of authorized wireless access points is maintained and a business justification is documented for all authorized wireless access points.1. v3.10) to verify it defines and requires a response in the event that an unauthorized wireless access point is detected. such as performing physical system inspections in conjunction with the results of a wireless analyzer.1 Maintain an inventory of authorized wireless access points including a documented business justification. 11. All Rights Reserved.2. in an environment with multiple nodes (such as in a large retail store.1. 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. In this case.a Examine the organization’s incident response plan (Requirement 12. server room or data center). multiple methods may be combined to meet the requirement. where all communication components are contained within tamper-resistant and tamper-evident casings.1 © 2006-2015 PCI Security Standards Council. call center.1. PCI DSS Requirements 11. 11. it is not required that four quarters of passing scans be completed if the assessor verifies 1) the most recent scan result was a passing scan.b Review the scan reports and verify that the scan process includes rescans until all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 Perform quarterly internal vulnerability scans and rescans as needed. 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. the entity corrects them and repeats the scan until all vulnerabilities have been corrected. firewall rule modifications. ranked “High” per Requirement 6. All Rights Reserved. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.1. and/or methods run against external and internal network devices and servers. and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). four quarters of passing scans must have occurred.2 Examine scan reports and supporting documentation to verify that internal and external vulnerability scans are performed as follows: A vulnerability scan is a combination of automated or manual tools. Page 94 April 2015 . v3. product upgrades).1) should be resolved with the highest priority. Guidance Internal quarterly vulnerability scanning by qualified personnel (use of a PCI SSC Approved Scanning Vendor (ASV) is not required) External quarterly vulnerability scanning. 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. For subsequent years after the initial PCI DSS review. techniques.1. There are three types of vulnerability scanning required for PCI DSS: Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. until all “high-risk” vulnerabilities (as identified in Requirement 6. For initial PCI DSS compliance. 11.2.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12month period.1 © 2006-2015 PCI Security Standards Council. designed to expose potential vulnerabilities that could be found and exploited by malicious individuals. Testing Procedures 11. LLC. changes in network topology.1 are resolved. Payment Card Industry (PCI) Data Security Standard.2.1) are resolved. 2) the entity has documented policies and procedures requiring quarterly scanning. Scans must be performed by qualified personnel.2. An established process for identifying vulnerabilities on internal systems requires that vulnerability scans be conducted quarterly. Vulnerabilities posing the greatest risk to the environment (for example. which must be performed by an ASV Internal and external scanning as needed after significant changes Once these weaknesses are identified. 2. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment. The determination of what constitutes a significant change is highly dependent on the configuration of a given environment. scan preparation. 11. 11. approved by the Payment Card Industry Security Standards Council (PCI SSC). a firewall administrator should not be responsible for scanning the firewall). no vulnerabilities rated 4. 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. Scans must be performed by qualified personnel. then it could be considered significant. 11. Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV). after any significant change.2.2.3.c Review the scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).2.a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly external vulnerability scans occurred in the most recent 12month period. etc.3 Perform internal and external scans.2. Internal vulnerability scans can be performed by qualified.1 are resolved.2. 11. and no automatic failures).2. Perform rescans as needed. For internal scans. As external networks are at greater risk of compromise. and if applicable. and rescans as needed. 11.2. Testing Procedures Guidance 11. via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC).0 or higher by the CVSS.2. Page 95 April 2015 . organizational independence of the tester exists (not required to be a QSA or ASV).3.1. no vulnerabilities exist that are scored 4. until passing scans are achieved. internal staff that are reasonably independent of the system component(s) being scanned (for example. or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning.2.2 Perform quarterly external vulnerability scans. all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6. 11. quarterly external vulnerability scanning must be performed by a PCI SSC Approved Scanning Vendor (ASV). Payment Card Industry (PCI) Data Security Standard. v3.c Interview personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party. LLC. Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities.a Inspect and correlate change control documentation and scan reports to verify that system components subject to any significant change were scanned.0 or higher by the CVSS. All Rights Reserved.2.b Review scan reports and verify that the scan process includes rescans until: For external scans.1 © 2006-2015 PCI Security Standards Council. All system components affected by the change will need to be scanned.PCI DSS Requirements 11.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example. at a minimum. the vulnerabilities listed in Requirement 6. Note: This update to Requirement 11. All Rights Reserved. This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against attacks. Often the tester will chain several types of exploits together with a goal of breaking through layers of defenses.3. Penetration testing techniques will be different for different organizations. depth.3 Implement a methodology for penetration testing that includes the following: Is based on industry-accepted penetration testing approaches (for example. as a penetration test is an active process that may include exploiting identified vulnerabilities.2. if the tester finds a means to gain access to an application server.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party. 11. Prior to this date.3 Examine penetration-testing methodology and interview responsible personnel to verify a methodology is implemented that includes the following: Is based on industry-accepted penetration testing approaches (for example.1 © 2006-2015 PCI Security Standards Council. In this way. NIST SP800-115) Includes coverage for the entire CDE perimeter and critical systems Includes testing from both inside and outside the network Includes testing to validate any segmentation and scope-reduction controls Defines application-layer penetration tests to include. Conducting a vulnerability scan may be one of the first steps a penetration tester will perform in order to plan the testing strategy. and the type. Payment Card Industry (PCI) Data Security Standard. PCI DSS v2. the vulnerabilities listed in Requirement 6.0 requirements for penetration testing must be followed until version 3 is in place. and complexity of the testing will depend on the specific environment and the organization’s risk assessment. Page 96 April 2015 . Even if a vulnerability scan does not detect known vulnerabilities.5 Defines network-layer penetration tests to include components that support network functions as well as operating systems Includes review and consideration of threats and vulnerabilities experienced in the last 12 months Specifies retention of penetration testing results and remediation activities results. and if applicable. after which it becomes a requirement. NIST SP800-115) Includes coverage for the entire CDE perimeter and critical systems Testing from both inside and outside the network Includes testing to validate any segmentation and scopereduction controls Defines application-layer penetration tests to include. For example. Penetration testing is generally a highly manual process.PCI DSS Requirements Testing Procedures Guidance 11. the penetration tester will often gain enough knowledge about the system to identify possible security gaps. they will then use the compromised server as a point to stage a new attack based on the resources the server has access to.5 Defines network-layer penetration tests to include components that support network functions as well as operating systems Includes review and consideration of threats and vulnerabilities experienced in the last 12 months Specifies retention of penetration testing results and remediation activities results.3 is a best practice until June 30. 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. A penetration test differs from a vulnerability scan. 11. 2015. While some automated tools may be used. at a minimum. organizational independence of the tester exists (not required to be a QSA or ASV). a tester is able to simulate the methods performed by an attacker to identify areas of potential weakness in the environment. although it is not the only step. the tester uses their knowledge of systems to penetrate into an environment. LLC. v3. Per the defined methodology Guidance Penetration testing conducted on a regular basis and after significant changes to the environment is a proactive security measure that helps minimize potential access to the CDE by malicious individuals.3 Examine penetration testing results to verify that noted exploitable vulnerabilities were corrected and that repeated testing confirmed the vulnerability was corrected. or a web server added to the environment).2. a sub-network added to the environment. 11.3.b Verify that the test was performed by a qualified internal resource or qualified external third party. 11.1. and if applicable. organizational independence of the tester exists (not required to be a QSA or ASV).3.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed as follows. All Rights Reserved. At least annually After any significant changes to the environment.PCI DSS Requirements 11. 11.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections. then it could be considered significant. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment. and if applicable. or a web server added to the environment). 11. Page 97 April 2015 . Performing penetration tests after network upgrades and modifications provides assurance that the controls assumed to be in place are still working effectively after the upgrade or modification. LLC. Testing Procedures 11. 11. a sub-network added to the environment. v3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade.1.3.1 © 2006-2015 PCI Security Standards Council.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed as follows: Per the defined methodology At least annually After any significant changes to the environment.3.3. The determination of what constitutes a significant upgrade or modification is highly dependent on the configuration of a given environment.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade. 11.2. Payment Card Industry (PCI) Data Security Standard.3.3.b Verify that the test was performed by a qualified internal resource or qualified external third party. organizational independence of the tester exists (not required to be a QSA or ASV). attacks on (or misuse of) computer resources could go unnoticed in real time. 11. 11.a Examine system configurations and network diagrams to verify that techniques (such as intrusion-detection systems and/or intrusion-prevention systems) are in place to monitor all traffic: At the perimeter of the cardholder data environment At critical points in the cardholder data environment. Security alerts generated by these techniques should be monitored so that the attempted intrusions can be stopped. network testing and/or scanning for open ports. LLC.3. and send alerts and/or stop the attempt as it happens. both from outside the entity’s network and from inside the network but outside of the CDE.a Examine segmentation controls and review penetration-testing methodology to verify that penetrationtesting procedures are defined to test all segmentation methods to confirm they are operational and effective. 11.4.b Examine system configurations and interview responsible personnel to confirm intrusion-detection and/or intrusion-prevention techniques alert personnel of suspected compromises. Penetration testing is an important tool to confirm that any segmentation in place to isolate the CDE from other networks is effective.4 If segmentation is used to isolate the CDE from other networks. and isolate all out-of-scope systems from systems in the CDE.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective. maintained. Payment Card Industry (PCI) Data Security Standard. 11.1 © 2006-2015 PCI Security Standards Council.PCI DSS Requirements Testing Procedures Guidance 11. and isolate all out-of-scope systems from systems in the CDE. v3. 11.c Examine IDS/IPS configurations and vendor documentation to verify intrusion-detection and/or intrusionprevention techniques are configured. The penetration testing covers all segmentation controls/methods in use.3. 11. and signatures up to date. The penetration testing should focus on the segmentation controls. and isolate all out-of-scope systems from systems in the CDE. and updated per vendor instructions to ensure optimal protection. All Rights Reserved.4. For example. to confirm that they are not able to get through the segmentation controls to access the CDE.4.3. to verify no connectivity between in-scope and out-of-scope networks. baselines. and other malware). Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment.4.4. Trojans. The penetration testing verifies that segmentation controls/methods are operational and effective. Without a proactive approach to unauthorized activity detection. Intrusion detection and/or intrusion prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools. Page 98 April 2015 . and alert personnel to suspected compromises.b Examine the results from the most recent penetration test to verify that: Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods. Keep all intrusion-detection and prevention engines. Page 99 April 2015 . and Known to all affected parties. 11. log and audit files Additional critical files determined by entity (for example. and notify when such changes are detected. file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes. such as those for custom applications. 11.6 Examine documentation and interview personnel to verify that security policies and operational procedures for security monitoring and testing are: Documented. additions. as well as reviewing results from monitoring activities.1 Interview personnel to verify that all alerts are investigated and resolved. if undetected. through risk assessment or other means). additions.6 Ensure that security policies and operational procedures for security monitoring and testing are documented. or alter configuration file contents.5. All Rights Reserved. v3.b Verify the mechanism is configured to alert personnel to unauthorized modification (including changes. historical or archived. but the modification of which could indicate a system compromise or risk of compromise.PCI DSS Requirements Testing Procedures Guidance 11. Personnel need to be aware of and following security policies and operational procedures for security monitoring and testing on a continuous basis. Unauthorized changes. or content files. In use.5 Deploy a change-detection mechanism (for example. and known to all affected parties. LLC.a Verify the use of a change-detection mechanism within the cardholder data environment by observing system settings and monitored files.5.5. must be evaluated and defined by the entity (that is. configuration files. and configure the software to perform critical file comparisons at least weekly.5. the merchant or service provider). operating system programs. 11. and deletions) of critical system files. and deletions to critical files. If not implemented properly and the output of the change-detection solution monitored. Change-detection mechanisms such as file-integrity monitoring products usually come preconfigured with critical files for the related operating system.1 © 2006-2015 PCI Security Standards Council. remove. a malicious individual could add. 11.1 Implement a process to respond to any alerts generated by the changedetection solution. Note: For change-detection purposes. and deletions) of critical files. could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing. or application executables. 11. Other critical files. and to perform critical file comparisons at least weekly. Payment Card Industry (PCI) Data Security Standard. 11. additions. critical files are usually those that do not regularly change. in use. Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes. Examples of files that should be monitored: System executables Application executables Configuration and parameter files Centrally stored. relocation. trends.1 Review the security policy at least annually and update the policy when the environment changes. 12. Identifies critical assets.1. documented analysis of risk. threats. acquisition. Security threats and protection methods evolve rapidly.1 © 2006-2015 PCI Security Standards Council. temporary employees. etc. “personnel” refers to full-time and part-time employees. 12. Testing Procedures Guidance 12.1.b Review risk-assessment documentation to verify that the risk-assessment process is performed at least annually and upon significant changes to the environment. new protection measures to fight against these threats are not addressed. and vulnerabilities.1 Verify that the information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. publish. Examples of risk-assessment methodologies include but are not limited to OCTAVE. 12. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. documented analysis of risk 12. PCI DSS Requirements 12.1 Establish. Without updating the security policy to reflect relevant changes.a Verify that an annual risk-assessment process is documented that: Identifies critical assets.1 Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners).2.).2. v3. A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them.Maintain an Information Security Policy Requirement 12: Maintain a policy that addresses information security for all personnel. 12. merger. Performing risk assessments at least annually and upon significant changes allows the organization to keep up to date with organizational changes and evolving threats.2 Implement a risk-assessment process that: Is performed at least annually and upon significant changes to the environment (for example. All Rights Reserved. Resources can then be effectively allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized. threats. and vulnerabilities Results in a formal. maintain. contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environment. and disseminate a security policy. Page 100 April 2015 . ISO 27005 and NIST SP 800-30. For the purposes of Requirement 12. A company's information security policy creates the roadmap for implementing security measures to protect its most valuable assets. and technologies. LLC. and Results in a formal. A risk assessment enables an organization to identify threats and associated vulnerabilities with the potential to negatively impact their business. Payment Card Industry (PCI) Data Security Standard. PCI DSS Requirements Testing Procedures Guidance 12.2 Authentication for use of the technology 12. VPNs. tablets. Without requiring proper approval for implementation of these technologies. An accurate inventory with proper device labeling allows for quick identification of non-approved installations. tokens. v3. or provide guidance for personnel as to correct usage and implementation. malicious individuals may easily use this unprotected technology to access critical systems and cardholder data. but are not limited to.3. remote access and wireless technologies.).3.3. 12.3 A list of all such devices and personnel with access 12. Ensure these usage policies require the following: Payment Card Industry (PCI) Data Security Standard.” Personnel may also bypass procedures and install devices. email usage and Internet usage. etc. If technology is implemented without proper authentication (user IDs and passwords. 12. token).3 Examine the usage policies for critical technologies and interview responsible personnel to verify the following policies are implemented and followed: Personnel usage policies can either prohibit use of certain devices and other technologies if that is company policy. but also open a huge hole that subjects critical systems and data to malicious individuals.2 Verify that the usage policies include processes for all technology use to be authenticated with user ID and password or other authentication item (for example. removable electronic media.1 © 2006-2015 PCI Security Standards Council.3.3 Verify that the usage policies define a list of all devices and personnel authorized to use the devices. LLC.3. All Rights Reserved. personnel may use the technologies in violation of company policy.3. 12. individual personnel may innocently implement a solution to a perceived business need. If usage policies are not in place. laptops. Malicious individuals may breach physical security and place their own devices on the network as a “back door. 12. Note: Examples of critical technologies include.1 Explicit approval by authorized parties 12.1 Verify that the usage policies include processes for explicit approval from authorized parties to use the technologies.3 Develop usage policies for critical technologies and define proper use of these technologies. Page 101 April 2015 . thereby allowing malicious individuals to gain access to critical systems and cardholder data. to ensure a “back door” is not opened for a malicious individual to gain access to critical systems and cardholder data.3.4 A method to accurately and readily determine owner. and purpose (for example. contact information.3. By disconnecting remote-access technologies when not in use (for example. coding. An accurate inventory with proper device labeling allows for quick identification of non-approved installations. v3.3.8.8. 12.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity 12. coding.3.7 List of company-approved products 12. or business partners).a Verify that the usage policies require automatic disconnect of sessions for remote-access technologies after a specific period of inactivity. other vendors.b Examine configurations for remote access technologies to verify that remote access sessions will be automatically disconnected after a specific period of inactivity. and/or inventorying of devices). All Rights Reserved. Consider establishing an official naming convention for devices.3.5 Verify that the usage policies define acceptable uses for the technology. Logical labeling may be employed with information such as codes that can correlate the device to its owner. 12. and purpose (for example. those used to support your systems by your POS vendor. contact information.6 Acceptable network locations for the technologies 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. 12.3. contact information.6 Verify that the usage policies define acceptable network locations for the technology. Page 102 April 2015 .5 Acceptable uses of the technology 12. labeling. Payment Card Industry (PCI) Data Security Standard.3. LLC.1 © 2006-2015 PCI Security Standards Council. with immediate deactivation after use. the company is better able to manage and control gaps in configurations and operational controls. 12. labeling. 12.3. and purpose.PCI DSS Requirements Testing Procedures Guidance 12. 12.3.” Personnel may also bypass procedures and install devices. Malicious individuals may breach physical security and place their own devices on the network as a “back door. and log all devices with established inventory controls. 12. access and risk to networks is minimized. and/or inventorying of devices) 12.4 Verify that the usage policies define a method to accurately and readily determine owner.3.7 Verify that the usage policies include a list of company-approved products. with immediate deactivation after use Remote-access technologies are frequent "back doors" to critical resources and cardholder data.9 Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners. By defining acceptable business use and location of company-approved devices and technology.3.3. moving. 12.1 Verify that responsibility for establishing. moving. documenting. prohibit the copying.5. and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations. v3. Each person or team with responsibilities for information security management should be clearly aware of their responsibilities and related tasks.3.PCI DSS Requirements Testing Procedures 12. 12.1 Establish. 12.10. unless explicitly authorized for a defined business need.5 Examine information security policies and procedures to verify: 12. leading to unsecured implementation of technologies or use of outdated or unsecured technologies.5 Assign to an individual or team the following information security management responsibilities: 12. Guidance To ensure all personnel are aware of their responsibilities to not store or copy cardholder data onto their local personal computers or other media.a Verify that information security policies clearly define information security responsibilities for all personnel.3 Verify that responsibility for establishing. LLC. documenting and distributing security policies and procedures is formally assigned. 12. 12.5. and distribute to appropriate personnel. the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.3 Establish.3. Where there is an authorized business need.5. The formal assignment of information security to a Chief Security Officer or other security-knowledgeable member of management. 12.4. All Rights Reserved.b Interview a sample of responsible personnel to verify they understand the security policies.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.2 Monitor and analyze security alerts and information. document.5. document. your policy should clearly prohibit such activities except for personnel that have been explicitly authorized to do so. and distribute security policies and procedures. 12. 12. Without this accountability.10 For personnel accessing cardholder data via remote-access technologies.1 © 2006-2015 PCI Security Standards Council.3. gaps in processes may open access into critical resources or cardholder data. there could be inconsistent interaction with the security group. and distributing security incident response and escalation procedures is formally assigned. Storing or copying cardholder data onto a local hard drive or other media must be in accordance with all applicable PCI DSS requirements. The following information security responsibilities are specifically and formally assigned: 12. 12.5. verify that usage policies require the protection of cardholder data in accordance with PCI DSS Requirements.a Verify that the usage policies prohibit copying. through specific policy.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. Page 103 April 2015 . 12. Without clearly defined security roles and responsibilities assigned.10. and storage of cardholder data onto local hard drives and removable electronic media.b For personnel with proper authorization.5. Payment Card Industry (PCI) Data Security Standard. or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.4. deleting.6 Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security. including additions.1.1. and modifications. 12.4 Verify that responsibility for administering (adding. 12. 12. resulting in exposed critical resources and cardholder data. and promotions). Page 104 April 2015 .5. All Rights Reserved. Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data. 12. 12.5. that they have read and understand the information security policy.1 © 2006-2015 PCI Security Standards Council. 12.5 Verify that responsibility for monitoring and controlling all access to data is formally assigned.6. memos. 12. 12. and modifying) user account and authentication management is formally assigned. 12.5.1 Educate personnel upon hire and at least annually. in writing or electronically.6.PCI DSS Requirements Testing Procedures 12. meetings.5 Monitor and control all access to data. letters. deletions. Payment Card Industry (PCI) Data Security Standard.b Examine security awareness program procedures and documentation and perform the following: 12.a Verify that the security awareness program provides multiple methods of communicating awareness and educating personnel (for example.6. Guidance 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.b Verify that personnel attend security awareness training upon hire and at least annually. key security processes and procedures may be forgotten or bypassed.a Review the security awareness program to verify it provides awareness to all personnel about the importance of cardholder data security.5. and that they have made and will continue to make a commitment to comply with these policies.6. posters. LLC.1. web-based training. v3.c Interview a sample of personnel to verify they have completed awareness training and are aware of the importance of cardholder data security.6.2 Verify that the security awareness program requires personnel to acknowledge. at least annually. 12. Requiring an acknowledgement by personnel in writing or electronically helps ensure that they have read and understood the security policies/procedures.4 Administer user accounts.6.6.2 Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures.6. 12. If the security awareness program does not include periodic refresher sessions. PCI DSS Requirements Testing Procedures Guidance 12. managed service providers such as web-hosting companies or security service providers.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared.). 12. etc. credit history.7 Inquire with Human Resource department management and verify that background checks are conducted (within the constraints of local laws) prior to hire on potential personnel who will have access to cardholder data or the cardholder data environment. or that could affect the security of cardholder data (for example. 12.) 12. as follows: If a merchant or service provider shares cardholder data with a service provider. review of policies and procedures. (Examples of background checks include previous employment history. and review of supporting documentation. certain requirements apply to ensure continued protection of this data will be enforced by such service providers. as follows: 12. v3. or that could affect the security of cardholder data. Payment Card Industry (PCI) Data Security Standard.1 © 2006-2015 PCI Security Standards Council.8. 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. and reference checks. 12.8. LLC. 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. All Rights Reserved. Keeping track of all service providers identifies where potential risk extends to outside of the organization. backup tape storage facilities.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources.1 Maintain a list of service providers.8 Through observation. Page 105 April 2015 . verify that processes are implemented to manage service providers with whom cardholder data is shared. criminal record. those that receive data for fraud modeling purposes. this requirement is a recommendation only.1 Verify that a list of service providers is maintained. 1 © 2006-2015 PCI Security Standards Council.2 Observe written agreements and confirm they include an acknowledgement by service providers that they are responsible for the security of cardholder data the service providers possess or otherwise store. The process ensures that any engagement of a service provider is thoroughly vetted internally by an organization. For example.3 Verify that policies and procedures are documented and implemented including proper due diligence prior to engaging any service provider.8. v3.PCI DSS Requirements Testing Procedures Guidance 12. In conjunction with Requirement 12. details of how PCI DSS responsibilities are assigned between each party.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement. 12. the details of the service being provided. All Rights Reserved. 12. which should include a risk analysis prior to establishing a formal relationship with the service provider. 12. LLC. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. this requirement for written agreements between organizations and service provides is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities.8. and the responsibilities assigned to each party.8.9. or to the extent that they could impact the security of the customer’s cardholder data environment. The acknowledgement does not have to include the exact wording provided in this requirement.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store. how the provider validates their PCI DSS compliance and what evidence they will provide. etc. Specific due-diligence processes and goals will vary for each organization. Note: The exact wording of an acknowledgement will depend on the agreement between the two parties. the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service. or to the extent that they could impact the security of the customer’s cardholder data environment. Examples of considerations may include the provider’s reporting practices.8. breach-notification and incident response procedures. Payment Card Industry (PCI) Data Security Standard. process or transmit on behalf of the customer. Page 106 April 2015 . process or transmit on behalf of the customer. or transmits cardholder data on behalf of the customer.2. Payment Card Industry (PCI) Data Security Standard.8. the type of service. or to the extent that they could impact the security of the customer’s cardholder data environment. Note: This requirement is a best practice until June 30. Note: The exact wording of an acknowledgement will depend on the agreement between the two parties. 12. If the service provider offers a variety of services. 12. and the responsibilities assigned to each party.1 © 2006-2015 PCI Security Standards Council.5 Maintain information about which PCI DSS requirements are managed by each service provider. Knowing your service providers’ PCI DSS compliance status provides assurance and awareness about whether they comply with the same requirements that your organization is subject to. and those services in scope for the client’s PCI DSS assessment. or to the extent that they could impact the security of the customer’s cardholder data environment. All Rights Reserved. this requirement should apply to those services delivered to the client. 2015. The specific information an entity maintains will depend on the particular agreement with their providers.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.9 Additional testing procedure for service provider assessments only: Review service provider’s policies and procedures and observe templates used for written agreements to confirm the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores.8. this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities.8. The acknowledgement does not have to include the exact wording provided in this requirement. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. or transmits on behalf of the customer. v3.8. the details of the service being provided. processes.9 Additional requirement for service providers only: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores. 12. etc. and which are managed by the entity. In conjunction with Requirement 12.4 Verify that the entity maintains a program to monitor its service providers’ PCI DSS compliance status at least annually. processes. LLC. The intent is for the assessed entity to understand which PCI DSS requirements their providers have agreed to meet.PCI DSS Requirements Testing Procedures Guidance 12. after which it becomes a requirement. and which are managed by the entity.5 Verify the entity maintains information about which PCI DSS requirements are managed by each service provider. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers. The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to their customers.8. Note: This requirement applies only when the entity being assessed is a service provider. 12. 12. Page 107 April 2015 . read.10. Without proper testing.10. 12. Specific incident response procedures Business recovery and continuity procedures Data backup processes Analysis of legal requirements for reporting compromises (for example. Payment Card Industry (PCI) Data Security Standard.10 Examine the incident response plan and related procedures to verify entity is prepared to respond immediately to a system breach by performing the following: Without a thorough security incident response plan that is properly disseminated.10 Implement an incident response plan. v3.1 © 2006-2015 PCI Security Standards Council. California Bill 1386.2 Verify that the plan is tested at least annually. unnecessary public media exposure.10. confusion and lack of a unified response could create further downtime for the business.10. which could result in increased exposure during an incident.a Verify that the incident response plan includes: Roles. as well as new legal liabilities.PCI DSS Requirements Testing Procedures Guidance 12. LLC. 12. responsibilities. 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. and communication strategies in the event of a compromise including notification of the payment brands. Page 108 April 2015 . at a minimum: 12. 12.10. Roles.1 Create the incident response plan to be implemented in the event of system breach. All Rights Reserved. at a minimum 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.b Interview personnel and review documentation from a sample of previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed. Be prepared to respond immediately to a system breach.2 Test the plan at least annually. key steps may be missed. 12. responsibilities. and communication and contact strategies in the event of a compromise including notification of the payment brands. 12.1. and understood by the parties responsible. Ensure the plan addresses the following.1. at a minimum Specific incident response procedures Business recovery and continuity procedures Data backup 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. 5 Verify through observation and review of processes that monitoring and responding to alerts from security monitoring systems are covered in the incident response plan. 12. 12. and/or reports of unauthorized critical system or content file changes. 12.10. review of policies. detection of unauthorized wireless access points. Payment Card Industry (PCI) Data Security Standard.PCI DSS Requirements Testing Procedures Guidance 12.6 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. LLC. 12.6 Verify through observation. and critical data and systems may become “polluted” by inappropriate handling of the targeted systems.10.10. Without a trained and readily available incident response team. and interviews of responsible personnel that staff with responsibilities for security breach response are periodically trained. and must be included in the incident-response processes. Page 109 April 2015 .4 Provide appropriate training to staff with security breach response responsibilities. intrusionprevention. are critical in taking quick action to prevent a breach.10. and interviews of responsible personnel that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity.10. critical IDS alerts. firewalls.10. All Rights Reserved. and file-integrity monitoring systems. This can hinder the success of a post-incident investigation.5 Include alerts from security monitoring systems.10. review of policies. 12. extended damage to the network could occur.3 Verify through observation. These monitoring systems are designed to focus on potential risk to data.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts. v3. 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. 12. including but not limited to intrusion-detection.1 © 2006-2015 PCI Security Standards Council.4 Verify through observation. review of policies. and interviews of responsible personnel that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. 12. 1 Specifically for a PCI DSS assessment of a shared hosting provider. A.6 states that shared hosting providers must protect each entity’s hosted environment and data. A. All Rights Reserved. In addition. merchants or service providers) to run their own applications. Requirement 2. rather than as a privileged user. LLC. shared hosting providers must additionally comply with the requirements in this Appendix. Payment Card Industry (PCI) Data Security Standard. Requirements A.1. Note: Even though a hosting provider may meet these requirements.8 and 12. Page 110 April 2015 .1 If a shared hosting provider allows entities (for example. or other entity) hosted environment and data.9.1. merchant. If a merchant or service provider is allowed to run their own applications on the shared server.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment.4 below: Guidance Appendix A of PCI DSS is intended for shared hosting providers who wish to provide their merchant and/or service provider customers with a PCI DSS compliant hosting environment. all service providers with access to cardholder data (including shared hosting providers) must adhere to the PCI DSS.1 © 2006-2015 PCI Security Standards Council.1: Shared hosting providers must protect the cardholder data environment As referenced in Requirement 12. Testing Procedures A.1 through A.1.4: A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. the compliance of the entity that uses the hosting provider is not guaranteed.1. Therefore.1. All CGI scripts used by an entity must be created and run as the entity’s unique user ID. per A. service provider. select a sample of servers (Microsoft Windows and Unix/Linux) across a representative sample of hosted merchants and service providers. these should run with the user ID of the merchant or service provider. to verify that shared hosting providers protect entities’ (merchants and service providers) hosted environment and data.1 through A.1 Protect each entity’s (that is. Each entity must comply with the PCI DSS and validate compliance as applicable.Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers Requirement A. v3.1. verify these application processes run using the unique ID of the entity. For example: No entity on the system can use a shared web server user ID. and perform A. Privileges of the merchant’s or service provider’s web server user ID.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.3 Verify the shared hosting provider has enabled logging as follows. service provider) has read. Permissions granted to merchant’s and service provider’s log files. and execute files. Page 111 April 2015 .1.2. Permissions granted to write to system binaries. Permissions granted to read. for example. chroot.Requirements A.) Guidance To ensure that access and privileges are restricted such that each merchant or service provider has access only to their own environment. 2. 4.2. logs specific to their cardholder data environment.1. write. and A. LLC.c Verify that an entity’s users do not have write access to shared system binaries. access control lists. A. buffer overflows).1. A. jailshell. Disk space Bandwidth Memory CPU A.1. Logs are available for review by the owning entity.2.2. Logs are active by default. Controls to ensure one merchant or service provider cannot monopolize system resources. for each merchant and service provider environment: Logs are enabled for common third-party applications. and restart conditions resulting in. v3.2.a Verify the user ID of any application process is not a privileged user (root/admin).3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.1. A.1. write.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities (for example. and can review. A. race. down to the appropriate level of detail so that an individual merchant’s or service provider’s details are available. or execute permissions only for files and directories it owns or for necessary system files (restricted via file system permissions.1. A. Payment Card Industry (PCI) Data Security Standard.2 Restrict each entity’s access and privileges to its own cardholder data environment only. etc. Important: An entity’s files may not be shared by group. verify restrictions are in place for the use of these system resources: 5. Testing Procedures A. Logs should be available in a shared hosting environment so the merchants and service providers have access to. Log locations are clearly communicated to the owning entity. error.d Verify that viewing of log entries is restricted to the owning entity.1.1 © 2006-2015 PCI Security Standards Council.1.b Verify each entity (merchant.4 Verify the shared hosting provider has written policies that provide for a timely forensics investigation of related servers in the event of a compromise. 3.1. consider the following: 1. All Rights Reserved. Shared hosting providers must have processes to provide quick and easy response in the event that a forensic investigation is needed for a compromise. A. and (2) it is set up properly and in a secure environment. 4. and controls that address all of the following: (1) internal network segmentation. An entity cannot use other PCI DSS password requirements (intruder lockout. due to legitimate technical or documented business constraints. The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented. April 2015 Page 112 . and (3) two-factor authentication from within the internal network. the surrounding security controls. All compensating controls must be reviewed and validated for sufficiency by the assessor who conducts the PCI DSS review. since those other password requirements do not mitigate the risk of interception of clear-text passwords.) 3. Also.1 © 2006-2015 PCI Security Standards Council. c) Existing PCI DSS requirements may be combined with new controls to become a compensating control. by encryption). (Simply being in compliance with other PCI DSS requirements is not a compensating control. (See Navigating PCI DSS for the intent of each PCI DSS requirement. Two-factor authentication from within the internal network can also be considered as a compensating control for non-console administrative access when transmission of encrypted passwords cannot be supported. processes and controls must be in place to ensure compensating controls remain effective after the assessment is complete. Twofactor authentication may be an acceptable compensating control if: (1) it meets the intent of the original requirement by addressing the risk of intercepting clear-text administrative passwords. For example. Compensating controls must satisfy the following criteria: 1.) When evaluating “above and beyond” for compensating controls. applications. etc. passwords for non-console administrative access must be sent encrypted to mitigate the risk of intercepting clear-text administrative passwords. two-factor authentication is a PCI DSS requirement for remote access. per items 1-4 above. Be “above and beyond” other PCI DSS requirements. a) Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review. 2.4 (for example. LLC.) to compensate for lack of encrypted passwords. For example.Appendix B: Compensating Controls Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated. Payment Card Industry (PCI) Data Security Standard. such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. v3. if a company is unable to render cardholder data unreadable per Requirement 3. a compensating control could consist of a device or combination of devices. To maintain compliance. or compensating. (2) IP address or MAC address filtering. but has sufficiently mitigated the risk associated with the requirement through implementation of other. the other password controls are already PCI DSS requirements for the item under review (passwords). controls. Provide a similar level of defense as the original PCI DSS requirement. All Rights Reserved. Meet the intent and rigor of the original PCI DSS requirement. complex passwords. Companies should be aware that a particular compensating control will not be effective in all environments. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement The assessor is required to thoroughly evaluate compensating controls during each annual PCI DSS assessment to validate that each compensating control adequately addresses the risk the original PCI DSS requirement was designed to address. consider the following: Note: The items at a) through c) below are intended as examples only. but are not required for the item under review. b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area. For example. and the configuration of the control. v3. if any. Constraints List constraints precluding compliance with the original requirement. 3. Definition of Compensating Controls Define the compensating controls and explain how they address the objectives of the original control and the increased risk. identify the objective met by the compensating control. Identified Risk Identify any additional risk posed by the lack of the original control. 5. Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.1 © 2006-2015 PCI Security Standards Council. All Rights Reserved. Validation of Compensating Controls Define how the compensating controls were validated and tested. Payment Card Industry (PCI) Data Security Standard. Explanation Page 113 April 2015 . Note that compensating controls should also be documented in the Report on Compliance in the corresponding PCI DSS requirement section. Maintenance Define process and controls in place to maintain compensating controls. 6. Objective Define the objective of the original control. LLC. 4. Requirement Number and Definition: Information Required 1. 2.Appendix C: Compensating Controls Worksheet Use this worksheet to define compensating controls for any requirement where compensating controls are used to meet a PCI DSS requirement. they each require a “root” login. each user’s actions can be traced to an individual user account.Compensating Controls Worksheet – Completed Example Use this worksheet to define compensating controls for any requirement noted as being “in place” via compensating controls. it is not considered acceptable from a security perspective to share login credentials. Definition of Compensating Controls Define the compensating controls and explain how they address the objectives of the original control and the increased risk. Page 114 April 2015 . Payment Card Industry (PCI) Data Security Standard. having shared logins makes it impossible to state definitively that a person is responsible for a particular action. that only pre-defined commands can be run by specified users. It is not possible for Company XYZ to manage the “root” login nor is it feasible to log all “root” activity by each user. Identified Risk Identify any additional risk posed by the lack of the original control. 4. and then use the “sudo” command to run any administrative commands. Company XYZ documents processes and procedures to ensure sudo configurations are not changed. This allows use of the “root” account privileges to run pre-defined commands that are recorded by sudo in the security log. Company XYZ demonstrates to assessor that the sudo command is configured properly using a “sudoers” file. 6. The objective of requiring unique logins is twofold. First. and that all activities performed by those individuals using sudo are logged to identify the individual performing actions using “root” privileges. All Rights Reserved. Additional risk is introduced to the access control system by not ensuring all users have a unique ID and are able to be tracked. Objective Define the objective of the original control. Requirement Number: 8. Secondly.1 – Are all users identified with a unique user ID before allowing them to access system components or cardholder data? Information Required Explanation 1. if any. 3. v3.1 © 2006-2015 PCI Security Standards Council. Company XYZ employs stand-alone Unix Servers without LDAP. As such. 5. without the “root” password being shared with the users. Maintenance Define process and controls in place to maintain compensating controls. Constraints List constraints precluding compliance with the original requirement. tracked and logged.1. identify the objective met by the compensating control. 2. Company XYZ is going to require all users to log into the servers using their regular user accounts. LLC. In this way. or removed to allow individual users to execute root commands without being individually identified. altered. Validation of Compensating Controls Define how the compensating controls were validated and tested. Page 115 April 2015 .Appendix D: Segmentation and Sampling of Business Facilities/System Components Payment Card Industry (PCI) Data Security Standard. LLC.1 © 2006-2015 PCI Security Standards Council. v3. All Rights Reserved.
Copyright © 2024 DOKUMEN.SITE Inc.