PCI DSS

Penetration Testing of Segmentation Controls for PCI DSS

Recently I came across a penetration testing report (supplied as evidence for Payment Card Industry Data Security Standard (PCI DSS) compliance) that made a series of assumptions based on the company’s risk assessment as to whether segmentation controls (separating the cardholder data environment (CDE) from out-of-scope networks) should be tested or not.

Requirement 11.3.4 of PCI DSS 3.2.1 states “If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.” Essentially the penetration test is to identify ways to exploit vulnerabilities to bypass, get around or defeat the segmentation controls in place, which will enable access to the CDE.

To be clear, rather than consider penetration testing requirements as a whole for PCI DSS compliance we are going to concentrate on specific penetration testing of segmentation controls and requirement 11.3.4 mentioned above. Often times deciding if a PCI DSS requirement applies cannot be determined based on a risk assessment. A report on compliance (RoC) only allows a Qualified Security Assessor (QSA) to assess the requirement as either:

• In Place
• Not In Place
• In Place w/CCW (Compensating Controls Worsksheet)
• N/A
• Not Tested

Assessing something as “In Place” cannot be made on the basis of a risk assessment determining whether that PCI requirement is needed or not.

It either is “In Place” or it is not. A partial implementation or execution of a requirement doesn’t get you to compliance. You may have a compensating control but you have to have legitimate technological or documented business constraints to consider the use of compensating controls to achieve compliance, and those compensating controls have to meet the intent and rigor of the original PCI DSS requirement and be above and beyond other PCI DSS requirements. So, when it comes to penetration testing segmentation controls there is no real way around the requirement being fully met.

A good reference point for what is being discussed here is the Information Supplement • Penetration Testing Guidance • September 2017 from the PCI SSC (Security Standards Council) which can be found here.

Given penetration testing is a manual process, which may include the use of tools, the first question is who will do the penetration testing of the segmentation controls. Requirement 11.3.4c needs a QSA to “Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organisational independence of the tester exists (not required to be a QSA or ASV).” If you are utilising an internal resource to do the testing they must be organisationally separated from the management of the systems being targeted in the test. Even more important is their experience.

The PCI SSC Penetration Testing Guidance (see link above) section “3 Qualifications of a Penetration Tester” lays out a great guide for considering who you plan to use.

Interesting to note is that the guidance states “Certifications held by a penetration tester may be an indication of the skill level and competence of a potential penetration tester or company. While these are not required certifications, they can indicate a common body of knowledge held by the candidate.” Past experience may be a good indicator but again the guidance mentions “Appropriate penetration testing experience and qualifications cannot be met by certifications alone. Therefore, confirmation of additional criteria is necessary.” So a QSA will dig into the experience of a penetration tester including things like how many years’ experience they have, what technologies in the target environment they have experience with and what other skills they may have that will contribute to their ability to access the target environment.

Now that you have your tester – when it comes to segmentation controls, what needs to be tested?

PCI DSS requirement 11.3.4.b states that the “testing covers all segmentation controls/methods in use” and that the testing “verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.” Note that it states “all segmentation controls/methods” which means you can’t pick and choose which segmentation controls you plan to test. It must be all of them even if you deem one segmentation point as low risk. The aim is to ensure a segmented (out-of-scope) system component cannot impact the security of the CDE, even if an attacker obtained control of the out-of-scope system.

What if you have a large amount of internal LAN segments to test from and it may not be feasible for a penetration tester to conduct tests from every LAN segment? The Penetration Testing Guidance states “In this case, the testing needs to be planned to examine each type of segmentation methodology in use (i.e., firewall, VLAN ACL, etc.) in order to validate the effectiveness of the segmentation controls. The level of testing for each segmentation methodology should provide assurance that the methodology is effective in all instances of use.”

The methodology can also be found in the PCI SSC Penetration Testing Guidance document, but what I wanted to convey here is:

1. You can’t reduce the scope of a segmentation penetration test by assessing a segmentation point as low risk.
2. Make sure that your penetration tester is adequately qualified, and
3. If you have a large amount of LAN segments to test from, there is an alternative approach available.

___________________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.

___________________

Brian Odian is the Director of Asia Pacific Global Compliance & Risk Services Consulting at SecureTrust, based in Sydney. He has over 32 years IT industry experience including roles as a Security Delivery Manager and Global Security and Transformation Lead for large worldwide information technology corporations. During his career he has been across a wide range of industries and roles, including global management experience across multiple cultures and business environments.

Experienced in running global security programs, and some of the largest regional projects in Asia Pacific, Brian brings a mix of project management, security and compliance credentials together (CISM, CRISC, PMP, QSA, ISO27001 IA, CDPSE) to achieve the best results in delivering security solutions and compliance programs. He has been published by the Project Management Institute (PMI) and MSSP Alert along with conducting webinars on the General Data Protection Regulation (GDPR) and Compliance Intelligence. He has also presented on PCI Compliance for some of the “big four” banks and the Customer Owned Banking Association (COBA).