Penetration Testing as per PCI DSS version 3.2

As per PCI DSS v3.2, Requirement 11.3 addresses penetration testing activity for organizations following PCI DSS compliance.

The requirement is further divided into following sub requirements:

  • Requirement 11.3.1: Conduct external penetration testing at least annually or after any significant change has occurred in organization’s environment
  • Requirement 11.3.2: Conduct internal penetration testing at least annually or after any significant change has occurred in organization’s environment
  • Requirement 11.3.3: Exploitable vulnerabilities identified during testing shall be corrected and testing shall be repeated to verify corrections
  • Requirement 11.3.4: Perform network segmentation testing to validate if segmentation controls and methods are effective and operational

The major objective of penetration testing is to determine ways by which a malicious user can achieve unauthorized access to cardholder data.

Additionally, as per PCI DSS v3.2 Requirement 11.2 organizations are required to perform External (aka ASV scans) and internal vulnerability assessment at least quarterly.

The scope of work in a vulnerability scan is limited to identifying, ranking and reporting vulnerabilities. These vulnerabilities if exploited, may result in compromise of system whereas penetration testing is a step ahead where the scope is to identify ways to exploit vulnerabilities to overthrow security controls.

Scoping:

The first and foremost step before actually conducting penetration testing activity is “Scoping”. Before we discuss more about scoping let’s first understand some terms of PCI DSS:

Cardholder environment: As per PCI DSS v3.2, cardholder data environment (aka CDE) is “People, process and technology that store, process or transmit cardholder data and/or sensitive authentication data.

Critical system: System/technology that is “considered by the entity” to have an impact on the security of the CDE. Some examples of critical systems can be security systems such as firewalls, IPS/IDS, LDAP authentication servers, etc.

Connected systems : Systems which are “connected” to any other system present in the card holder environment shall also be considered to be in scope. For a system to fall in this category it should satisfy either of the following 2 conditions:

  • The system is on the same network segment as the system which is storing, processing or transmitting cardholder data
  • The system provides security service for a system which is storing, processing or transmitting cardholder data. Example of such security service, include:
    • Antivirus server
    • Patch management server
    • Authentication or access management servers
    • Log server

Following points shall be considered while deciding the scope of penetration testing activity:

  • Entire Cardholder data environment and all the network/systems connected to CDE which may impact the security of CDE
  • In case segmentation is implemented to isolate CDE from other network/systems then the scope of penetration testing can be limited to CDE. But this is only if the segmentation testing has verified that segmentation controls are operational and effective.
  • External penetration testing scope shall include:
    • Systems connected or accessible from the Internet
    • External perimeter of CDE
    • Remote access methods such as VPN
  • Internal penetration testing scope shall include:
    • Internal perimeter of CDE
    • System connected to internal perimeter of CDE which may impact security of CDE
  • ASV Scan scope: Systems accessible or connected to public network infrastructure for eg. Internet shall be in scope of ASV scan. It means that ASV scans should be conducted for public IPs present in the assessed entity’s PCI DSS scope.
  • Out of scope:
    • System isolated from CDE such that even if the system is compromised it cannot impact the security of CDE
Groundwork:

There are certain artifacts prepared for other PCI DSS requirements which can be used to extract information about systems, network and technology used in environment.

Some of the documents which can be used for the preparatory phase are:

  • Network Diagram
  • Cardholder dataflow Diagram
  • Business Justification document for ports, services and protocols used
  • List of network segments
  • Authorized wireless access point inventory
  • Results of network vulnerability scans
  • Results of last penetration testing activity
Methodology:

After obtaining necessary information from above mentioned documents, a methodology should be prepared to perform penetration testing activity. Organizations can have their own methodology to perform penetration testing, however following points should be considered while preparing a methodology for testing:

  • Methodology should be based on industry best practices such as but not limited to OWASP, NIST etc.
  • Testing should be appropriate for complexity and size of organization
  • Should include all cardholder data locations, critical network connections, critical access points, application storing, processing or transmitting cardholder data/sensitive authentication data
  • Attempt to penetrate at network level and application level
  • If any attempt to exploit the vulnerability results into unauthorized access to critical systems, then vulnerability shall be corrected and retesting shall be performed until the test is clean
Attention!

Testing of vulnerabilities leading to Denial of service (aka DoS) should not be taken into consideration.

Network Segregation Testing:

The prime objective of network segregation testing is to ensure that isolated networks do not have access to cardholder environment. The testing should ensure that each network segment which is considered to be isolated from cardholder data environment (CDE) indeed has no access to the CDE at all. Sampling of isolated network segments can be done for networks where a large number of network segments needs to be tested. The sample should be representative of the entire population to provide assurance and confidence that the same conclusion would have been reached had the entire population been reviewed.

Note:

If any testing outputs such as screenshots, data dumps, script results, etc. contain cardholder data then ensure that the cardholder data is protected as per PCI DSS guidelines.

Post testing cleanup:

Once the penetration testing activity is concluded, it is important that the assessor should divulge all modifications performed in the assessed environment. Some examples of such modifications can be:

  • File/script uploads
  • User account additions
  • Ports modifications
  • Starting/stopping any services
  • Any tools installed during the test

Such disclosures will help organizations ensure that these modifications could not be used in future to exploit its environment.

Results of penetration testing activity should be retained for at least 1 year or as defined in the organization policy.

 

References:

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf

https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf

https://www.pcisecuritystandards.org/pdfs/infosupp_11_3_penetration_testing.pdf

Author


Related Tags:

3 comments

Hi Nikhil,

Nice article. However one more critical point, specifically for Service Providers (SPs) for network segmentation. Penetration testing now needs to be conducted biannually in a certification year or after any changes in the segmentation controls/methods.

Regards,


Nikhil W.

Hi Nikhil,

Thanks !

As per requirement 11.3.4.1 of PCI DSS version 3.2, service providers need to perform penetration testing to validate segmentation controls at least every six months.This is the bare minimum period to validate segmentation controls during annual compliance.It should be noted that if there is any significant change in the infra then a separate round of testing shall be performed. This should be over and above the bare minimum requirement which is of six months. Hope this helps.

Regards,

Nikhil Raj Singh

Hi Nikhil,

Thanks for the clarification and I’m aware of this control right when the standard was at draft stage (before final release). My feedback was that you should add this critical point in your article, so that service providers can take note of it which may call for additional efforts / commercials to comply with this control.

Regards,


Nikhil W.

Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.