.svg)
Introduction
Testing the security of any network infrastructure and applications which are involved in the storing, processing or transmitting of cardholder data is often a key part of maintaining compliance with Payment Card Industry Data Security Standard (PCI DSS) requirements.
Along with internal and external vulnerability scanning (only briefly covered here), penetration and segmentation testing form the bulk of Requirement 11: Regularly test security systems and processes.
However, despite their importance in helping to maintain a healthy security posture and therefore guard against attackers, there is often a lot of confusion about what the tests consist of and how they differ, both from each other and vulnerability scanning in general.
This article sets out to demystify the process by explaining some of the key terms used and assessing the requirements one by one. But before we do that, let's take a quick look at which self-assessment questionnaires require either penetration testing, segmentation testing or both:
Demystifying the terms
Frankly, there is a lot of jargon used within the field of penetration testing (pentesting for short) and for someone coming across the field for the first time, it can be quite daunting. Here are a few of the key terms which you may see:
White/grey/black box testing:
These terms are usually used to signify how much the tester knows about the organization/environment being tested. For example, in a full white-box test, the internal structure/design of the item being tested would be known to the tester beforehand, whereas in a purely black-box test, the tester would have no prior knowledge of the system/environment which they were focussing on and so would have to attempt to gather information themselves (for example from publicly available sources of information such as www.whois.com).
Most PCI DSS penetration testing falls somewhere in between these two extremes and can therefore be categorized as grey-box testing e.g. the tester has been provided with some information regarding the scope of the engagement and what they'll be expected to test but probably hasn't been provided with the full configuration/source code etc for every element to be tested.
It's worth pointing out at this stage that the PCI Security Standards Council advises against the use of black-box testing for PCI DSS compliance, as ensuring the scope of the test is correct is extremely difficult without providing the tester with information about the target systems themselves.
Application layer testing:
This style of pentesting focuses on identifying vulnerabilities within applications e.g. web applications, custom web services and custom software integrations (for example shopping carts, online forms, hotel booking applications etc). Typically, this type of testing isn't required for off-the-shelf software which hasn't been modified in some way.
Often based around the OWASP Top Ten (a consensus of the most critical security risks to web applications based on input from security experts), web application testing typically focuses on testing the functionality of the app and attempting to subvert it in order to achieve a goal e.g. compromising sensitive information or escalating privilege levels (for example gaining admin/root access in order to make changes to configuration/setup of certain systems).
Network layer testing:
This form of testing targets network infrastructure such as firewalls, routers, web servers, email servers, VPN servers, etc.
Internal/external testing:
These terms are purely used to differentiate between where the tests (either network or application) are originating from. External tests seek to mimic the actions of a remote attacker and therefore focus on infrastructure which is exposed to the internet.
Internal testing is carried out from within the organization and seeks to mimic the potential actions of an internal threat, such as a disgruntled employee or malicious contractor.
CVSS
The Common Vulnerability Scoring System (CVSS) is often used for assigning a severity rating to any identified vulnerabilities. Version 3.0 of CVSS (the latest) uses the severity ratings of low (score of 0.0-3.9), medium (4.0-6.9), high (7.0-8.9) and critical (9.0-10.0).
This system allows for testers to attach a significance to particular findings and further allows for the entities being tested to prioritise their remediation efforts accordingly. In terms of PCI DSS compliance, these ratings are often used to determine whether you have a passing or failing report.
Vulnerability scanning vs Penetration Testing
Often confused with penetration testing, vulnerability scanning also forms part of Requirement 11. The main difference between the two is that vulnerability scanning is primarily an automated procedure, where commercial or open-source software is used to scan applications/networks for known vulnerabilities, missing patches, etc.
Penetration testing on the other hand is mostly a manual process. Although part of the methodology often includes running vulnerability scans, the tester will attempt to exploit any discovered vulnerabilities to see how far they can get, often harnessing the power of custom scripts and/or combining several vulnerabilities in order to achieve the goal.
Given the complexity of the work involved, a typical penetration test will often take much longer than a vulnerability scan and be subject to a higher cost.
Segmentation Testing
This type of testing can also be referred to as segmentation penetration testing and shares similarities with traditional penetration testing in that it's also a manual process which requires skilled interpretation of the results.
The goal with segmentation testing however is to test any controls which are said to be in place and are being relied upon to separate (segment) areas of the network which are not in-scope for PCI DSS requirements from the parts of the network which are.
An example of this could be where a guest network has been created and separated from the main corporate network. A segmentation test in this case would focus on testing the connectivity between the guest and corporate network in order to confirm whether the controls restricting traffic between the two are working as intended.
Scoping
This term is used to describe the sum total of systems/components to be tested. Often an area of confusion, the scope for a PCI DSS penetration test should include both the internal and external perimeter of the cardholder data environment (CDE, e.g. the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data) and any critical systems which may impact the security of the in-scope environment.
Testing purely within the CDE itself is not considered sufficient to meet pentesting requirements. Rather, the focus should be on attempting to penetrate into the CDE (as an attacker would), whether that's through external (public-facing) systems or by compromising internal systems in order to gain unauthorized access.
Breaking down the requirements
This section of the article aims to provide a little extra guidance around the requirements themselves, however specifics are often dependent on the scope of an assessment and the type of environment being tested.
For more detailed guidance, it’s recommended to review the “Penetration Testing Guidance March 2015” document released by the PCI SSC, which is available in the documentation section of their website:
https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf
Requirement 11.3:
This requirement focuses on the need for a formal penetration methodology to be in place. Whether you’re outsourcing pentesting to a third-party or using a qualified internal resource (which is okay assuming the tester has appropriate qualifications/experience and has organizational independence) they’ll need to be following a prescribed methodology that is based on an industry-accepted approach (for example NIST SP 800-115), defines appropriate tests (network layer and application layer where required) and includes all systems that are within the defined scope (both external and internal).
The methodology in question should be formally documented and retained by the entity undergoing testing.
Requirement 11.3.1(a & b):
These requirements cover the need for external penetration testing. The important part to note is that testing is required on an annual basis or after a significant change to either infrastructure or an application. As referenced above, the tests can be carried out by a qualified third-party or qualified internal resource with organizational independence.
Requirement 11.3.2 (a & b):
These requirements match those detailed in 11.3.1, but are focused on internal testing rather than external.
Requirement 11.3.3:
This requirement states that if exploitable vulnerabilities are detected (e.g. vulnerabilities that the tester was able to exploit in order to achieve something e.g. greater access to systems, cardholder data, etc) then these should be fixed and re-testing carried out until the corrections can be verified.
Requirement 11.3.4 (a, b & c):
These requirements are applicable if segmentation has been used to isolate the in-scope network(s) from out-of-scope networks. Where required, the segmentation testing carried out must cover all segmentation methods and be performed annually (or after any significant change to segmentation methods) by a qualified person (either external or internal with organizational independence).
For more information about VikingCloud's penetration testing solutions, visit https://www.vikingcloud.com/security-testing/penetration-testing or contact the VikingCloud team.
.svg)
