If you're responsible for an application that handles credit cards for online retail, let's run through what you need to know about the penetration test, a critical piece of your system's security.
Understanding How Penetration Tests Differ From Vulnerability Scans
First, let's talk about how penetration tests go above and beyond a vulnerability scan.
Vulnerability scans help identify, categorize, and report any system susceptibilities that can compromise your system. Generally, it's advisable to undertake vulnerability scans quarterly, as well as 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 actively attempt to break the system in an effort to exploit vulnerabilities. This is unlike vulnerability scanning, which passively reviews your system for potential problems.
Whereas vulnerability scans are largely automated, penetrative testing involves proactive manual processes that are time-consuming, though it does provide a deeper insight. This is why you only undertake penetrative testing once a year.
Understanding the Three PCI DSS Penetration Tests
The PCI DSS (Payment Card Industry Data Security Standard) is the information security standard for any online retail that handles credit cards, and it specifies three penetration testing types:
Black box; these assessments do not provide you with any information prior to the start of the tests.
White box; companies typically offer penetration testers with application and network details meant for these assessments.
Gray box; these assessments provide partial information pertaining to target systems.
During PCI DSS testing, gray 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, making it less expensive and saving time.
Establishing the Scope of Your Cardholder Data Environment
The PCI DSS officially defines CDE as:
...the process, people, and technologies that store, transmit, and process sensitive authentication or cardholder data.
Therefore, your first step during penetration testing is to determine the scope of the 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 simply 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.
Defining 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, such as intrusion detection systems and firewalls
all devices that store, process, or transmit cardholder data, such as ecommerce redirection servers and authentication servers
All of the above are considered "critical" to your operations. Generally, critical systems include all technology assets that privileged users within your organization use to support and manage CDE.
Knowing the Difference Between Network-Layer and Application-Layer Testing
In recent years, malicious attackers have been increasing their focus 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 attempts to infiltrate this software to pinpoint any weaknesses.
On the other hand, network-layer testing majorly focuses on loopholes in devices within your company’s environment, such as:
servers
firewalls
switches
routers
Vulnerabilities that you can detect in your network layer include:
default passwords
misconfigured devices
unpatched systems
Fulfilling PCI DSS Requirements
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. Testing must focus on exposed devices and the operating system rather than your payment application’s functionality.
Conclusion
Of course, automating compliance greatly eases the burden of penetration testing. With an automated approach, it's easier to deploy a governance system that provides in-depth insights. Add in a reporting dashboard and you have the capability to conveniently review health control quickly while listing critical issues your organization faces.