Any time the Payment Card Industry (PCI) Security Standards Council releases an update to its Data Security Standard (DSS), it raises a new set of questions and concerns. The latest update, PCI DSS v3.2, came out on 4/28/16. It primarily impacts service providers and is focused on the implementation of best practices into the Standard. (For a detailed breakdown of the changes, check out Steve Levinson’s blog on the release.) One of the biggest changes in this update is the requirement to have penetration testing on the segmentation (if used) at least twice a year – this will have a significant impact on service providers and is something you need to understand and prepare for.
Do you know how to test segmentation?
The PCI DSS requirement 11.3 specifically addresses the need to complete thorough network and application penetration testing. According to the Standard, “a vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible. Penetration testing should include network and application layer testing as well as controls and processes around the networks and applications, and should occur from both outside the network trying to come in (external testing) and from inside the network.” Unfortunately, many companies are not sure how to properly test segmentation or what to look for when getting assistance testing segmentation.
Target, a lesson learned
One of the most famous examples of improper segmentation is the Target breach. In November 2013, hackers went undetected and gained access to Target's network using a third party’s credentials. Target had given this third party remote access to their network without segmenting the third party’s access to ensure that they were NOT able to access payment systems. It was Target’s responsibility to ensure that proper segmentation of networks was implemented and tested, and because of their failure to do so, they were in violation of several PCI DSS requirements, including some of the PCI DSS 11.3 requirements.
Don't be a “What not to do”
If you’re reading this and you are patting yourself on the back because you have segmentation policies in place, you need to ask yourself if they are implemented correctly and are part of your penetration testing methodology. The PCI DSS 11.3 is specific in that if you elect to segment your cardholder data networks to reduce the scope of your assessment, then you need to ensure that you are meeting the requirements of the standard and protecting your organization and consumers.
With that in mind, let me share two important areas that are often overlooked:
- If you are using segmentation to reduce your PCI scope, you need to ensure you are testing from multiple locations.
- You need to test from the perspective of a connected system. For example, use servers that are not located in the segmented cardholder data network, but rather where traffic is permitted to connect to systems in the CDE through a firewall.
To further this example, a server used to push application changes or security patches to systems within the cardholder data environment may be located in the corporate network. This server may not bring all of the corporate network into scope, but it’s managed as a system component for PCI DSS and a hole is poked through the firewall for connectivity. This connectivity may not be discovered during your test if your vendor only runs a general discovery scan against the networks behind the firewall, since only the IP address of the patching server is permitted. But if that server was compromised, it would give attackers a significant attack vector into the cardholder data environment. Significant thought needs to go into designing and documenting your penetration test methodology to ensure due diligence regarding all sources of attacks is considered during your testing of segmentation.
What can I do?
You do not have to be a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV) to perform the penetration tests. Your penetration testers must, however, be able to demonstrate that they are experienced and that organizational independence of the group performing the test is enforced. Given that there are several serious nefarious actors and nation-states attempting to compromise systems to obtain your high value digital assets, you do want to make sure that you are protecting your data, reputation, and business as much as possible. In this this scenario, “experienced” should be much more than someone fresh out of school with a pen test certification.
Hiring a qualified company experienced with penetration testing and information security gives you peace-of-mind and may provide the unbiased perspective needed protect your organization and consumers from malicious hackers. A qualified third party will bring experienced personnel, expertise, and the latest hacking techniques to the table as it’s their business to stay up-to-date on the latest threats and trends in the cybersecurity world. If you decide to use a third party for penetration testing, be selective. Not all third-party providers are the same. Find a partner that is prepared to assist you by documenting the methodology they used to perform the penetration tests. This should include, but not be limited to:
Identifying whether they used black box, gray box, or white box tests.
- Whether or not the tests leveraged application accounts.
- Defining what segmentation was tested and what techniques were used.
In addition, companies are now required to retain penetration tests for a specific period of time as deemed necessary by the documented methodology.
We recommend that you negotiate some limited retesting in your scope of work with any third parties so that any findings identified as exploitable can be retested upon remediation and your report updated to reflect the corrections.
For more information on the latest PCI DSS 3.2 requirements, visit our resource center to read our whitepaper.
Submit a Comment