Internal penetration testing is a specific flavor of penetration testing that takes place from within your organization’s network. This testing is specifically designed to emulate a malicious insider or an external attacker that gains a foothold on the network. While the concept is pretty straightforward, there are some interesting nuances when you talk about internal penetration testing in order to meet the Payment Card Industry Data Security Standard (PCI DSS) requirements. A PCI internal penetration test has special considerations for scoping and perspective that are important to understand, to ensure you’re not only maintaining a strong security posture but also properly meeting requirements.
Scoping a PCI Internal Penetration Test
When it comes to PCI compliance, scoping a PCI internal penetration test can be pretty confusing. Do you test your whole environment? Do you only test systems that are in scope for PCI? In fact, the PCI Council has released specific penetration testing guidance to help clarify many of these issues, including testing scope. In this guidance, the council explains that a PCI internal penetration test should include:
- The internal perimeter of the cardholder data environment (CDE)
- Critical systems on the internal network
- Application-layer and network-layer assessments
- If/when access to the CDE is obtained as a result of the testing, the scope should allow the tester to continue exploring/attacking systems within the CDE
- Consideration of the specific environment and the entity’s risk assessment
In cases where segmentation is not used and there isn’t a defined CDE, or the entire internal network is considered the CDE, the scope of testing should be focused on critical systems. These critical systems are defined by the PCI DSS as those that are involved in the “processing or protection of cardholder data.” They can include systems inside or outside of the CDE such as databases that store CHD, applications that process CHD, firewalls, intrusion detection/prevention systems (IDS/IPS), authentication servers, or even workstations used by administrators to support/manage the CDE. These systems should be defined by your organization, but your penetration testing partner or PCI consultant should be able to help you through the identification process.
Just as critical as the scope of a PCI internal penetration test is the perspective from which the test is conducted. This is referring to where a penetration tester conducts testing from within your internal network. Different vulnerabilities or issues could be discovered depending on whether a tester is putting themselves in the CDE or outside the CDE, or even on one particular network segment vs. another. PCI guidance states that the CDE perimeter must be considered and that the goal of a PCI internal penetration test should be to gain access to the CDE. This would mean a tester should be situated outside of the CDE to conduct testing, and based on the risk profile of most organizations, it usually makes sense to be situated somewhere that mimics an internal employee as closely as possible. This decision will normally be based on the segmentation configuration, but may even require a tester to move around to different network segments during testing.
How to Prepare
Like most penetration tests, the goal of a PCI internal penetration test is to get full coverage of the environment through proper scoping and receive accurate results so realistic risks to your environment can be addressed, while the effective security controls can be confirmed. The best way to achieve these results is by working closely and openly with your penetration testing team prior to starting the engagement and making sure you’re using penetration testers with PCI-related experience. Having outside sources help confirm/justify your organization’s scope to ensure your penetration test is really meeting the intent of requirements is crucial to maintaining compliance over time. Additionally, make sure you understand what security testing is required of your organization and when you need to have it completed, to avoid rushing through the scoping process.