Document Diff - PCI Watch

Added p. 2

March 2015 1.0 Initial release All

September 2017 1.1 A number of clarifications, including:

• Clarified intent of “social engineering” in Terminology.

• Clarified guidance on black-box testing.

• Restructured Section 2.2 for better flow, and clarified language describing intent of PCI DSS Requirement 11.3.

• Expanded guidance related to back-end APIs.

• Updated references to PCI SSC resources.

• Minor grammatical updates.

Added p. 6

 Network-layer testing: Testing that typically includes external/internal testing of networks (LANS/VLANS), between interconnected systems, and wireless networks.

 Social engineering: Manipulation or deception of individuals into divulging confidential or personal information.

Added p. 8

The scope of testing may include locations of cardholder data, applications that store, process, or transmit cardholder data, critical network connections, access points, and other targets appropriate for the complexity and size of the organization. This should include resources and assets utilized by personnel to maintain systems in the CDE or to access cardholder data, as the compromise of such assets could allow an attacker to obtain credentials with access to or a route into the CDE.

All penetration testing should only be conducted as defined by the rules of engagement agreed upon by both parties. See Section 4.1.3, “Rules of Engagement.” Information Supplement

Added p. 9

Where the CDE is also the only internal network and there is no internal CDE perimeter, the scope of testing will typically be focused on critical systems. For example, testing activities may include attempting to bypass internal access controls intended to prevent unauthorized access or use of systems that store, process, or transmit CHD from those that do not.

In cases where there is an internal CDE perimeter, the scope of testing will need to consider the CDE perimeter as well as critical systems within and outside of the CDE. For example, the testing may attempt to exploit permitted access paths from systems on an internal network segment into the CDE.

In all cases, the scope of internal testing should consider the specific environment and the entity’s risk assessment. Entities are encouraged to consult with their assessor and the penetration tester to ensure the scope of the penetration test is sufficient and …

Added p. 9

If segmentation controls are implemented, testing of the controls is required to confirm that the segmentation methods are working as intended and that all out-of-scope systems and networks are isolated from systems in the CDE. The scope of segmentation testing should consider any networks and systems considered as being out of scope for PCI DSS to verify they do not have connectivity to the CDE and cannot be used to impact the security of the CDE.

Added p. 14

Q How many years has the organization that employs the penetration tester been performing penetration tests?

• References from other customers may be useful in consideration.

Q Has the penetration tester performed assessments against organizations of similar size and scope?

• For environments with high availability constraints, unstable system components, or large infrastructures, it is important to evaluate a tester’s ability to handle those restrictions (bandwidth constraints, time constraints, etc.).

• Even if the penetration tester has not performed an assessment against certain specific technologies, if the tester has managed, maintained, been trained on, or developed said technologies, the tester may still be qualified to perform the penetration test.

• What type of experience does the penetration tester have conducting network-layer penetration testing? Discussion of examples of network penetration testing efforts conducted by the organization may be warranted.

Added p. 19

The tester should understand the interaction between the web application and the backend, the functionality exposed by the API, as well as any security controls implemented to protect access to the API. Those, and other factors, will help determine whether the back-end API should be tested independently from the web application.

Added p. 26

Dates the engagement was performed ☐ ☐ Date the report was issued ☐ ☐ Executive Summary Summarizes testing performed ☐ ☐ Summarizes results of testing ☐ ☐ Summarizes steps for remediation ☐ ☐ Is the scope clearly documented? ☐ ☐ How the scope was determined ☐ ☐ Is the attack perspective of the engagement clearly defined (internal, external, or both)? Information Supplement

Added p. 41

- Network-layer tests for network and OS 2.3, 4.2.2 Information Supplement

Accuvant, Inc Alaska Airlines A-lign Security and Compliance Services Allstate Insurance Aperia Solutions AT&T Consulting Solutions atsec (Beijing) Information Technology Co., Ltd Bally Total Fitness Bank Of New Zealand Bashas' Inc.

BB&T Corporation Board of Trustees of the University of Arkansas Bridge Point Communications The Brick Group BrightLine CPAs & Associates, Inc.

British Airways PLC Canadian Tire Financial Services CBIZ Security & Advisory Services, LLC CDG Commerce CenturyLink Cisco Systems, Inc.

EVO Payments International Experian Information Services Exxon Mobil Corporation Fiscal Systems, Inc.

FishNet Security Foresight IT Consulting Pty Ltd.

Grant Thornton Groupement Interbancaire Monetique de L'uemoa (GIM-UEMOA) GuidePoint Security, LLC Information Supplement

Online Enterprises Payment Software Company (PSC) PayPal, Inc.

Pier1 Imports Princeton Payment Solutions LLC Progressive Casualty Insurance Company Promocion y Operacion SA de CV Rapid7 LLC RBC Royal Bank Right Time Limited Secured Net Solutions Inc.

Sikich LLP SIX Payment Services Ltd Solutionary, Inc.

Symantec Corporation …

Modified p. 4 → 5

 Penetration Testing Components: Understanding of the different components that make up a penetration test and how this differs from a vulnerability scan including scope, application and ~~network- layer~~ testing, segmentation checks, and social engineering.

 Penetration Testing Components: Understanding of the different components that make up a penetration test and how this differs from a vulnerability scan including scope, application and network-layer testing, segmentation checks, and social engineering.

Removed p. 5

 Network-layer testing: Testing that typically includes external/internal testing of networks (LANS/VLANS), between interconnected systems, wireless networks, and social engineering.

Removed p. 6

• March 2015 2 Penetration Testing Components The goals of penetration testing are:

Modified p. 6 → 7

2. To confirm that the applicable ~~controls, such~~ as scope, vulnerability management, methodology, and ~~segmentation, required in PCI DSS are~~ in place.

2. To confirm that the applicable controls required by PCI DSS

•such as scope, vulnerability management, methodology, and segmentation

•are in place.

Modified p. 6 → 7

There are three types of penetration tests: black-box, white-box, and grey-box. In a black-box assessment, the client provides no information prior to the start of testing. In a white-box assessment, the entity may provide the penetration tester with full and complete details of the network and applications. For grey-box assessments, the entity may provide partial details of the target systems. PCI DSS penetration tests are typically performed as either white-box or grey-box assessments. These types of assessments yield more accurate …

Modified p. 6 → 7

When At least quarterly or after significant ~~changes.~~

When At least quarterly and after significant changes1. At least annually and upon significant changes2.

Modified p. 6 → 7

~~At least annually and upon significant changes. (Refer to Section 2.6 of this document for information on significant changes.)~~ How Typically a variety of automated tools combined with manual verification of identified issues.

How Typically a variety of automated tools combined with manual verification of identified issues.

Removed p. 7

• March 2015 Vulnerability Scan Penetration Test Reports Potential risks posed by known vulnerabilities, ranked in accordance with NVD/CVSS base scores associated with each vulnerability.

The scope of a penetration test, as defined in PCI DSS Requirement 11.3, must include the entire CDE perimeter and any critical systems that may impact the security of the CDE as well as the environment in scope for PCI DSS. This includes both the external perimeter (public-facing attack surfaces) and the internal perimeter of the CDE (LAN-LAN attack surfaces). Guidance on penetration test scoping is as follows:

Modified p. 7 → 8

~~Note that~~ external vulnerability scans must be performed by an ASV and the risks ranked in accordance with the CVSS. Internal vulnerability scans may be performed by qualified personnel (does not require an ASV) and risks ranked in accordance with the organization’s risk-ranking process as defined in PCI DSS Requirement 6.1.

For PCI DSS, external vulnerability scans must be performed by an ASV and the risks ranked in accordance with the CVSS. Internal vulnerability scans may be performed by qualified personnel (does not require an ASV) and risks ranked in accordance with the organization’s risk-ranking process as defined in PCI DSS Requirement 6.1.

Modified p. 7 → 8

Description of each vulnerability verified and/or potential issue discovered. More specific risks that vulnerability may pose, including specific methods how and to what extent it may be exploited.

Description of each vulnerability verified and/or potential issue discovered. More specific risks that vulnerability may pose, including specific methods how and to what extent it may be exploited. Examples of vulnerabilities include but are not limited to SQL injection, privilege escalation, cross-site scripting, or deprecated protocols.

Modified p. 7 → 8

Engagements may last days or weeks depending on the scope of the test and size of the environment to be tested.

Engagements may last days or weeks depending on the scope of the test and size of the environment to be tested. Tests may grow in time and complexity if efforts uncover additional scope.

Modified p. 7 → 8

PCI DSS defines the cardholder data environment (CDE) as “the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication ~~data”.~~

PCI DSS defines the cardholder data environment (CDE) as “the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data.” The scope of a penetration test, as defined in PCI DSS Requirement 11.3, includes the entire CDE perimeter and any critical systems. This applies both to the external perimeter (public-facing attack surfaces) and the internal perimeter of the CDE (LAN-LAN attack surfaces).

Modified p. 7 → 9

External penetration tests also include remote access vectors such as dial-up and VPN connections.

Testing must include both application-layer and network-layer assessments. External penetration tests also include remote access vectors such as dial-up and VPN connections.

Removed p. 8

• March 2015  The scope of the internal penetration test is the internal perimeter of the CDE from the perspective of any out-of-scope LAN segment that has access to a unique type of attack on the CDE perimeter.

Critical systems or those systems that may impact the security of the CDE should also be included in the scope. Testing must include both application-layer and network-layer assessments.

 To be considered out of scope for PCI DSS, a system component must be isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE. Therefore, the penetration test may include systems not directly related to the processing, transmission or storage of cardholder data to ensure these assets, if compromised, could not impact the security of the CDE.

Testing may include locations of cardholder data, applications that store, process, or transmit cardholder …

Modified p. 8 → 9

 If segmentation controls have been implemented to separate environments, segmentation checks should be performed from any non-CDE environment that is intended to be completely segmented from the CDE perimeter. The intent of this assessment is to validate the effectiveness of the segmentation controls separating the ~~non-CDE~~ environments from the CDE and ensure the controls are ~~operational.~~

The intent of this assessment is to validate the effectiveness of the segmentation controls separating the out-of-scope environments from the CDE and to ensure the controls are operating as intended.

Modified p. 8 → 9

~~It is not a requirement to test from within the CDE to the servers inside the CDE; and testing exclusively from within the CDE perimeter will not satisfy the requirement. However, when~~ access to the CDE is obtained as a result of the testing, the penetration tester ~~may elect~~ to continue exploring inside the network and further the attack against other systems within the CDE, and may also include testing any data-exfiltration prevention (data-loss prevention) controls that are in place.

When access to the CDE is obtained as a result of the testing, the scope of the penetration test may allow the tester to continue exploring inside the network and further the attack against other systems within the CDE, and may also include testing any data-exfiltration prevention (data-loss prevention) controls that are in place.

Modified p. 11 → 12

~~• March 2015~~ Social-engineering tests are an effective method of identifying risks associated with end users’ failure to follow documented policies and procedures. There is no blanket approach to social-engineering engagements. If an organization chooses to include social-engineering testing as part of its annual security review, the tests performed should be appropriate for the size and complexity of the organization and should consider the maturity of the organization’s security awareness program. These tests might include in-person, ~~non-technological~~ interactions such as …

Social-engineering tests are an effective method of identifying risks associated with end users’ failure to follow documented policies and procedures. There is no blanket approach to social-engineering engagements. If an organization chooses to include social-engineering testing as part of its annual security review, the tests performed should be appropriate for the size and complexity of the organization and should consider the maturity of the organization’s security awareness program. These tests might include in-person, non- technological interactions such as persuading someone …

Modified p. 11 → 12

While PCI DSS does not require ~~use of~~ social-engineering techniques, an entity can incorporate it into its penetration testing methodology as an ongoing method ~~to determine~~ to determine the effectiveness of the security awareness program. The frequency of social-engineering tests would be determined by the entity when establishing its security awareness program. End-user security awareness re-education might be sufficient remediation for users who fail a social-engineering test. The objective is that, over time, fewer and fewer employees are making poor …

While PCI DSS does not require testing to include social-engineering techniques, an entity can incorporate it into its penetration testing methodology as an ongoing method to determine the effectiveness of the security awareness program. The frequency of social-engineering tests would be determined by the entity when establishing its security awareness program. End-user security awareness re-education might be sufficient remediation for users who fail a social-engineering test. The objective is that, over time, fewer and fewer employees are making poor decisions …

Modified p. 12 → 13

Note: The PCI SSC does not validate ~~nor~~ endorse these certifications.

Note: The PCI SSC does not validate or endorse these certifications.

Modified p. 12 → 13

 How many years’ experience does the penetration tester have? o If the penetration tester is in their first year of penetration testing, careful consideration should be given to the following questions to ensure the penetration tester has sufficient knowledge and is adequately trained to perform the penetration test. Consideration should also be given to the organization itself by verifying the training and QA processes to ensure penetration tester is qualified.

Q How many years’ experience does the penetration tester have? • If the penetration tester is in their first year of penetration testing, careful consideration should be given to the following questions to ensure the penetration tester has sufficient knowledge and is adequately trained to perform the penetration test. Consideration should also be given to the organization itself by verifying the training and QA processes to ensure penetration tester is qualified.

Removed p. 13

• March 2015  How many years has the organization that employs the penetration tester been performing penetration tests? o References from other customers may be useful in consideration  Has the penetration tester performed assessments against organizations of similar size and scope? o For environments with high availability constraints, unstable system components, or large infrastructures, it is important to evaluate a tester’s ability to handle those restrictions (bandwidth constraints, time constraints, etc.).

Modified p. 13 → 14

 What penetration testing experience has the penetration tester or team had with the technologies in the target environment (i.e., operating systems, hardware, web applications, highly customized applications, network services, protocols, etc.)? o When selecting a penetration tester, it is important to evaluate the past testing experience of the organization for which the tester works as it pertains to technologies specifically deployed within the target environment. ~~o Even if the penetration tester has not performed an assessment against certain specific …~~

Q What penetration testing experience has the penetration tester or team had with the technologies in the target environment (i.e., operating systems, hardware, web applications, highly customized applications, network services, protocols, etc.)? • When selecting a penetration tester, it is important to evaluate the past testing experience of the organization for which the tester works as it pertains to technologies specifically deployed within the target environment.

Modified p. 13 → 14

 Consider what other skills/qualifications the penetration tester has that will contribute to their ability to assess the environment. o Are there industry-standard penetration testing certifications held by the penetration tester? (See

Q Consider what other skills/qualifications the penetration tester has that will contribute to their ability to assess the environment. • Are there industry-standard penetration testing certifications held by the penetration tester? (See

Modified p. 13 → 14

Section 3.1.) o What type of experience does the penetration tester have conducting network-layer penetration testing? Discussion of examples of network penetration testing efforts conducted by the organization may be warranted. o Does the penetration tester have experience conducting application-layer penetration testing? Discussion of the penetration tester’s familiarity with testing to validate the OWASP Top 10 and other similar application secure-coding standards and examples of application penetration testing efforts conducted by the organization may be warranted.

• Does the penetration tester have experience conducting application-layer penetration testing? Discussion of the penetration tester’s familiarity with testing to validate the OWASP Top 10 and other similar application secure-coding standards and examples of application penetration testing efforts conducted by the organization may be warranted.

Modified p. 15 → 16

 Does the tester need to provide all IP addresses from which testing will originate?  Will sensitive data shown to be accessible during the test be retained by the tester during and after the penetration test? Only a proof-of-concept test should be performed, any cardholder data obtained must be secured in accordance with PCI DSS. (See Section 4.2.4 for more guidance.)  What steps will be taken if the tester detects a previous or active compromise to systems being …

Modified p. 16 → 17

~~• March 2015~~  The scope may not include the infrastructure provided by the third party to the entity. The scope may include any systems managed, built, or utilized by the organization.

 The scope may not include the infrastructure provided by the third party to the entity. The scope may include any systems managed, built, or utilized by the organization.

Removed p. 17

• March 2015  Identification of industry “state of existing vulnerabilities” for purposes of tracking vulnerabilities that may have not been detected at the time of the most recent penetration test The tester may gain additional insight of the target environment for this review by:

Modified p. 18 → 19

In instances where a web application utilizes a ~~backend API and~~ the API is in ~~scope, it is recommended that~~ the ~~API be tested independently of the web application.~~

In instances where a web application utilizes a back-end API, the API may be in scope for the testing.

Modified p. 18 → 20

If it is determined during the segmentation check that ~~the~~ LAN segment has access into the CDE, ~~either~~ the organization ~~needs~~ to ~~restrict~~ that ~~access~~ or a full network-layer penetration test ~~should be performed~~ to characterize the ~~access.~~

If it is determined during the segmentation check that a LAN segment thought to be out of scope has access into the CDE, the organization will either need to adjust the segmentation controls to block that access, or perform a full network-layer penetration test to characterize the access and the impact on PCI DSS scope.

Modified p. 20 → 21

~~• March 2015~~ In specific conditions, the flagged security issue may represent a fundamental flaw in an environment or application. The scope of a retest should consider whether any changes occurring as a result of remediation identified from the test are classified as significant. All changes should be retested; however, whether a complete system retest is necessary will be determined by the risk assessment of those changes.

In specific conditions, the flagged security issue may represent a fundamental flaw in an environment or application. The scope of a retest should consider whether any changes occurring as a result of remediation identified from the test are classified as significant. All changes should be retested; however, whether a complete system retest is necessary will be determined by the risk assessment of those changes.

Removed p. 22

• March 2015 5.1.2 Industry Standard References Some well-known, industry-standard references include:

Modified p. 23 → 24

- Vendor and/or researcher o Description of finding  Tools Used  Cleaning up the Environment Post-Penetration Test After testing there may be tasks the tester or customer needs to perform to restore the target environment (i.e., update/removal of test accounts or database entries added or modified during testing, uninstall of test tools or other artifacts, restoring active protection-system settings, and/or other activities the tester may not have permissions to perform, etc.). o Provide directions on how ~~clean up~~ should …

- Vendor and/or researcher o Description of finding  Tools Used  Cleaning up the Environment Post-Penetration Test After testing there may be tasks the tester or customer needs to perform to restore the target environment (i.e., update/removal of test accounts or database entries added or modified during testing, uninstall of test tools or other artifacts, restoring active protection-system settings, and/or other activities the tester may not have permissions to perform, etc.). o Provide directions on how cleanup should be …

Removed p. 24

• March 2015 The following is an example of the sections to include in a retest report as defined in Section 5.2.1:

Removed p. 25

• March 2015 5.4 Penetration Test Report Evaluation Tool This section is intended for entities that receive a penetration test report and need to interpret and evaluate the completeness of the report.

Removed p. 26

• March 2015 Report Question Included In Report Page Is the attack perspective of the engagement clearly defined (internal, external, or both)? ☐ ☐ Is the type of testing clearly defined (application layer, network layer, or both)? ☐ ☐ Were there any constraints put on the testing (time, bandwidth limitations, etc.)? ☐ ☐ Methodology Is the methodology clearly stated? ☐ ☐ Does the methodology reflect industry best practices (OWASP, NIST, etc.)? ☐ ☐ Is there a clear discussion of the automated and manual testing that was performed? ☐ ☐ Is there clear documentation of any problems that were encountered during the testing (interference from active protection systems, target environment controls blocking or dropping packets, etc.)?

Modified p. 29 → 30

~~• March 2015~~ With target enumeration complete, the tester performed vulnerability mapping of identified services using automated tools and by comparing the port and service fingerprint against well-known vulnerability databases.

With target enumeration complete, the tester performed vulnerability mapping of identified services using automated tools and by comparing the port and service fingerprint against well-known vulnerability databases.

Modified p. 29 → 30

 Apache Tomcat Manager Application Deployer Authenticated Code Execution  Cross-site scripting (reflective)  Directory traversal  Deprecated protocols - SSLv2, SSLv3  SSL weak ciphers  Internal IP address disclosure  IPS not enabled for disaster-recovery site  Slow HTTP denial-of-service attack Post-Engagement (Post-Execution Phase) At the completion of this examination, the penetration tester met with the Client to describe the preliminary results of the test and address any immediate concerns in advance of the report. The post-execution phase …

High:  Apache Tomcat Manager Application Deployer Authenticated Code Execution  Cross-site scripting (reflective)  Directory traversal Medium:  Deprecated protocols - SSLv2, SSLv3  SSL weak ciphers  Internal IP address disclosure Low:  IPS not enabled for disaster-recovery site  Slow HTTP denial-of-service attack Post-Engagement (Post-Execution Phase) At the completion of this examination, the penetration tester met with the Client to describe the preliminary results of the test and address any immediate concerns in advance of the report. …

Modified p. 30 → 31

 LOKE Network Zone: Guest network used for external consultants, other guests, BYOD devices, etc.

 LOKE Network Zone: Guest network used for external consultants, other guests, BYOD devices, etc. This is the only network that has wireless access points connected.

Modified p. 31 → 32

~~• March 2015~~ High-Level Network Diagram Success Criteria

• The success criteria for the penetration test is to gain access to the CDE.

High-Level Network Diagram Success Criteria

• The success criteria for the penetration test is to gain access to the CDE.

Modified p. 32 → 33

~~• March 2015~~ Scoping Discussion It was discussed with PCIData Hosting how they managed their CDE environment, including servers and databases. The operating systems are administrated by PCIData Hosting; all applications and development are handled by TechMerchant. Both PCIData Hosting and TechMerchant administer databases. Encrypted information in the database is only accessible with the encryption keys that are held by TechMerchant. All access to ODIN and THOR are authenticated by a two-factor solution. This also applies when accessed from internal …

Scoping Discussion It was discussed with PCIData Hosting how they managed their CDE environment, including servers and databases. The operating systems are administrated by PCIData Hosting; all applications and development are handled by TechMerchant. Both PCIData Hosting and TechMerchant administer databases. Encrypted information in the database is only accessible with the encryption keys that are held by TechMerchant. All access to ODIN and THOR are authenticated by a two-factor solution. This also applies when accessed from internal networks at PCIData …

Modified p. 33 → 34

~~• March 2015~~ Engagement Phase (Discovery and Attack/Execution) Discovery was performed on the LOKE (guest), HEJMDAL (management) and BALDER (office) networks to identify targets (servers, network components, workstations, etc.) on the networks, and analyzing techniques were used to get an understanding of the environment. The objectives of this phase were to identify systems, ports, services, and potential vulnerabilities. This phase was performed both manually and via automated tools including network discovery and port and service detection.

Engagement Phase (Discovery and Attack/Execution) Discovery was performed on the LOKE (guest), HEJMDAL (management) and BALDER (office) networks to identify targets (servers, network components, workstations, etc.) on the networks, and analyzing techniques were used to get an understanding of the environment. The objectives of this phase were to identify systems, ports, services, and potential vulnerabilities. This phase was performed both manually and via automated tools including network discovery and port and service detection.

Modified p. 33 → 34

 Internal attacker o Attacks from guest network were performed o Attacks from the management network were performed o Attacks from the office network were performed ~~Vulnerabilities were found on the different networks, and the tester was able to exploit these but was not able to use the vulnerabilities to gain access to ODIN or THOR.~~

 Internal attacker o Attacks from guest network were performed o Attacks from the management network were performed o Attacks from the office network were performed Information Supplement

Modified p. 34 → 35

~~• March 2015~~ Main vulnerabilities identified were:

Main vulnerabilities identified were:

Modified p. 34 → 35

• It was possible to perform a man-in-the-middle attack using ARP poisoning but the tester was not able to extract any sensitive information that could provide information on how to gain access to ODIN or THOR. ~~ Weak password policy implemented~~

 Man in the middle

• It was possible to perform a man-in-the-middle attack using ARP poisoning but the tester was not able to extract any sensitive information that could provide information on how to gain access to ODIN or THOR.

Modified p. 34 → 35

• Weak password settings on local servers on the BALDER network were used to compromise accounts on this network. The tester was not able to use these accounts to gain access to ODIN or THOR. As these servers are not in PCI scope, the weak password policy was not considered to have an impact on compliance. ~~ Old user accounts were compromised~~

 Weak password policy implemented

• Weak password settings on local servers on the BALDER network were used to compromise accounts on this network. The tester was not able to use these accounts to gain access to ODIN or THOR. As these servers are not in PCI scope, the weak password policy was not considered to have an impact on compliance.

Modified p. 34 → 35

• The tester was able to compromise user accounts that were created but had never been in use on the BALDER network. The compromised accounts did not grant access to ODIN or THOR. ~~ Others~~

 Old user accounts were compromised

• The tester was able to compromise user accounts that were created but had never been in use on the BALDER network. The compromised accounts did not grant access to ODIN or THOR.

Modified p. 34 → 35

• Other vulnerabilities were noted as zone transfer, outdated software, unencrypted protocols used; these vulnerabilities were all related to LOKE or BALDER network and did not grant access to ODIN or THOR even when exploited. Post-Engagement (Post-Execution phase) The post-execution phase focused on analyzing the identified vulnerabilities to determine root causes, establish recommendations and/or remediation activities, and develop a final report where all vulnerabilities noted during the test were documented even though they did not have an impact on the …

Post-Engagement (Post-Execution phase) The post-execution phase focused on analyzing the identified vulnerabilities to determine root causes, establish recommendations and/or remediation activities, and develop a final report where all vulnerabilities noted during the test were documented even though they did not have an impact on the cardholder data environment.

Modified p. 35 → 36

 POS Network

• Cardholder Data Environment (CDE) o 2 POS ~~Devices~~ o 1 POS server  General Store Network (Non-CDE) o 1 manager workstation o 1 CCTV server Corporate is made up of two network segments:

 POS Network

• Cardholder Data Environment (CDE) o 2 POS devices o 1 POS server  General Store Network (Non-CDE) o 1 manager workstation o 1 CCTV server Corporate is made up of two network segments:

Modified p. 38 → 39

 6 store public IPs Internal Penetration Testing Based on information that all stores are configured identically, internal testing was performed against two stores. Any vulnerabilities identified are assumed to exist in all stores. Testing included evaluation of the following unique testing perspectives targeting two store POS networks:

 Six store public IPs Internal Penetration Testing Based on information that all stores are configured identically, internal testing was performed against two stores. Any vulnerabilities identified are assumed to exist in all stores. Testing included evaluation of the following unique testing perspectives targeting two store POS networks:

Removed p. 39

• March 2015 Engagement Phase The success criteria for the penetration test were defined as getting access to the CDE environment and accessing cardholder data.

Modified p. 39 → 40

Vulnerability #1

• Segmentation failure Summary: It was found that firewall #2 (CDE firewall) was configured to allow unrestricted access (all ports and services) from the store General Network (10.0.0.0/24) into the store POS Network (192.168.0.0/24).

 Vulnerability #1

• Segmentation failure Summary: It was found that firewall #2 (CDE firewall) was configured to allow unrestricted access (all ports and services) from the store General Network (10.0.0.0/24) into the store POS Network (192.168.0.0/24).

Modified p. 39 → 40

Vulnerability #2

• Default user credentials on POS server Summary: Default credentials were enabled on the third-party application running on the POS server. Using these credentials, the penetration tester was able to obtain administrative-level access to the POS server.

 Vulnerability #2

• Default user credentials on POS server Summary: Default credentials were enabled on the third-party application running on the POS server. Using these credentials, the penetration tester was able to obtain administrative-level access to the POS server.

Removed p. 40

• March 2015 Appendix A: Quick-Reference Table to Guidance on PCI DSS Penetration Testing Requirements

Modified p. 40 → 41

- Coverage for CDE and critical systems 2.2, ~~2.2.1,~~ 4.1.1

- Coverage for CDE and critical systems 2.2, 2.2.4, 4.1.1

Modified p. 40 → 41

- Includes external and internal testing ~~2.2~~

- Includes external and internal testing 2.2.1, 2.2.2

Modified p. 40 → 41

- Test to validate ~~scope reduction 2.2~~

- Test to validate segmentation controls 2.2.3, 4.2.3

Removed p. 41

• March 2015 Acknowledgements

Accuvant, Inc Agio, LLC Alaska Airlines A-lign Security and Compliance Services Allstate Insurance American Express Aperia Solutions AT&T Consulting Solutions atsec (Beijing) Information Technology Co., Ltd Bally Total Fitness Bank Of New Zealand Bashas' Inc. BB&T Corporation Board of Trustees of the University of Arkansas Bridge Point Communications BrightLine CPAs & Associates, Inc. British Airways PLC BT PLC Canadian Tire Financial Services CBIZ Security & Advisory Services, LLC CDG Commerce CenturyLink Cisco Systems, Inc. Citigroup Inc. Clydesdale Bank PLC Coalfire Systems, Inc. Compass IT Compliance, LLC Computer Services, Inc. Comsec ControlScan Inc. Convergys Corp CradlePoint Crosskey Banking Solutions Crowe Horwath LLP DataFlight Europe AS Delhaize America Shared Services Group, LLC Dell, Inc.

Deluxe Corp. Diamond Resorts Corp. Digital Defense, Inc. Discover Financial Services Domino's Pizza, Inc. DST Output Enterprise Holdings, Inc. EVO Payments International EVRY A/S Experian Information Services Exxon Mobil Corporation Fiscal Systems, Inc. Fiserv Solutions, Inc. …

Modified p. 41 → 42

PCI SSC would like to acknowledge the contribution of the Penetration Testing Guidance Special Interest Group (SIG) in the preparation of ~~this document.~~ The Penetration Testing Guidance SIG ~~consists~~ of representatives from the following organizations:

PCI SSC would like to acknowledge the contribution of the Penetration Testing Guidance Special Interest Group (SIG) in the preparation of the original document published in 2015. The Penetration Testing Guidance SIG consisted of representatives from the following organizations:

Removed p. 42

• March 2015 National Australia Bank Nettitude, Ltd. NIC Inc Novacoast NRI Secure Technologies NTA Monitor Ltd. NTT Security Ltd. Online Enterprises Outerwall Payment Software Company (PSC) PayPal, Inc. Pier1 Imports Princeton Payment Solutions LLC Progressive Casualty Insurance Company Promocion y Operacion SA de CV Rapid7 LLC RBC Royal Bank RBS Right Time Limited Secured Net Solutions Inc. SecureNet SecurityMetrics, Inc. Sense of Security Pty Ltd. Sikich LLP SISA SIX Payment Services Ltd Solutionary, Inc. Starwood Hotels & Resorts Worldwide, Inc.

Document Comparison

From Revision History

Content Changes