Business Security Technology

What You Should Know About PCI DSS Penetration Testing

Image courtesy of Pixabay

There are three penetration testing types for PCI DSS (Payment Card Industry Data Security Standard). Black-box assessments do not provide you with any information prior to the start of the tests. Companies typically offer penetration testers with application and network details meant for white-box assessments. On the other hand, grey-box assessments entail providing partial information pertaining to target systems.

During PCI DSS testing, grey-box and white-box assessments give organizations a deeper insight about their operations. The information that an organization will provide during testing goes a long way in streamlining the process thus making it less expensive. It also helps save time.

How Penetration Tests Differs From Vulnerability Scans

Vulnerability scans are intended to help you identify, categorize, and report any system susceptibilities that can compromise your system. Generally, it is advisable to undertake vulnerability scans quarterly. You also need to undertake the scans whenever you make any notable modifications to the data environment. In most cases, vulnerability scans employ automated tools, and are accompanied by manual verification to completely root out issues.

Penetration testing is designed to purposefully exploit vulnerabilities by pinpointing gaps within your security apparatus. More specifically, penetration tests involve the active process of attempting to break the system in an effort to exploit vulnerabilities. This is unlike the case in vulnerability scanning, which passively reviews your system for potential problems. Penetrative testing involves proactive manual processes that time-consuming. However, it provides a deeper insight. This is why you can only undertake penetrative testing once every year.

Establishing the Scope of Your Cardholder Data Environment

The PCI security standard officially defines CDE as “the process, people, and technologies that store, transmit, and process sensitive authentication or cardholder data.” Therefore, the first step that you must take during the penetration testing is determining the scope of the entire process for PCI compliance. There are a number of guidelines that you must consider.

Payment processors need to assess aspects regarding access to open networks. This includes regulated access to external IP addresses. You also need to focus on your internal critical systems, more so those that touch on access to information. If your company has segmented its information, it is advisable to tests all systems that are beyond the CDE environment. This helps eliminate cases of cross-contamination.

Testing systems that are outside your CDE environment also ensures that your company’s segmentation controls work effectively besides ensuring that information remains separated. Deeming your network or system “out of scope” means you must ensure that its compromise doesn’t have any effect on cardholder data. Therefore, undertaking penetration testing on “out of scope” environments verifies that segmentation controls not only work in policy but also in practice.

What are Critical Systems?

PCI DSS testing regards systems that are involved in the processing and protection of cardholder information as being “critical.” These may include public-facing devices, security systems, and all devices that store, process, or transmit cardholder data. With regard to penetration testing, intrusion detection systems, firewalls, e-commerce redirection servers, and authentication servers are all regarded to be “critical” to your operations. Generally, critical systems include all technology assets that privileged users within your organization use to support and manage CDE.

Differences Between Network-Layer and Application-Layer Testing

In recent years, malicious attackers have been increasingly focusing on vulnerabilities within the application layer. Most organizations use third-party software, legacy applications, open source components, web applications, and internally-developed software as crucial components of their payment processing strategies. Application-layer testing entails attempting to infiltrate software to pinpoint any weaknesses.

On the other hand, network-layer testing majorly focuses on devices within your company’s environment. For instance, network-layer testing can help you identify possible loopholes in your servers, firewalls, switches, and routers. Vulnerabilities that you can detect in your network layer include default passwords, misconfigured devices, and unpatched systems.

Network-Layer and Application-Layer Tests that PCI DSS Requires

Typically, PCI DSS penetration testing provisions require that your organization tests authentication, web applications, PA-DSS compliance applications, and a different testing environment. On matters pertaining to authentication, you need to regularly review roles and access to your employee environment. Nevertheless, you must also ensure that only customers can access their data

A penetration tester needs to evaluate both cardholder customer controls and workforce user controls. If your company uses PA-DSS validated application, PCI DSS penetration testing ought to be undertaken during the implementation of the application although the application itself doesn’t require testing. Therefore, testing must focus on exposed devices and the operating system rather than your payment application’s functionality.

Automating compliance greatly eases the burden of penetration testing. With an automated approach, it will be easier to deploy a governance system which provides in-depth insights. Add in a reporting dashboard and you’re enabled to conveniently review health control quickly while listing critical issues your organization faces. This can help you attain improved cross-enterprise outcomes.

About the author

avatar

Ken Lynch

Ken Lynch is an enterprise software startup veteran, who has always been fascinated about what drives workers to work and how to make work more engaging. Ken founded Reciprocity to pursue just that. He has propelled Reciprocity's success with this mission-based goal of engaging employees with the governance, risk, and compliance goals of their company in order to create more socially minded corporate citizens. Ken earned his BS in Computer Science and Electrical Engineering from MIT. Learn more at ReciprocityLabs.com.