What you should know about PCI DSS penetration testing

Just a heads up, if you buy something through our links, we may get a small share of the sale. It’s one of the ways we keep the lights on here. Click here for more.

If your business accepts credit card payments, you should ensure compliance with the Payment Card Industry Data Security Standard (PCI DSS) to safeguard cardholder data. PCI DSS has many facets, with penetration testing being the most challenging for companies.

To ensure your business is PCI DSS compliant, penetration testing should be carried out occasionally to ascertain whether your systems and processes are appropriately-configured to keep cardholder data safe.

PCI DSS Penetration Testing

There are three main types of penetration testing: black box, white box, and grey box.

• Black box penetration assessment does not provide any information before the tests begin
• White box assessment provides application and network details during the test
• Grey box assessment provides partial information about target systems

White box and grey box assessments offer the best insight on the security status of your cardholder data environment (CDE). The tests are less expensive, require fewer resources, and are more streamlined.

Difference Between Penetration Testing and Vulnerability Scanning

Penetration testing is not the same as vulnerability scanning.

The goal of a vulnerability scan is to identify, assess, and report weaknesses that can compromise your systems. Generally, companies should carry out vulnerability assessments every quarter or after making significant changes to the cardholder data environment. Vulnerability scans are often carried out using automated tools and later followed up by manual verification processes.

On the other hand, the goal of a penetration test is to exploit a system by looking for security flaws. Penetration testing is a deliberate process of trying to break the security of CDE or the network system. The process takes a longer time, is more manual, and provides a comprehensive overview of the security status of the network system. Penetration testing should be carried out annually rather than quarterly.

The scope of Cardholder Data Environment (CDE)

The PCI DSS defines cardholder data environment as the technology, people, and processes involved in the transmission, processing, and storage of sensitive credit card information. Penetration testing should cover all the systems and processes that handle cardholder data.

The first penetration test is evaluating the accessibility of your organization’s public networks. The evaluation should be done on all systems and processes that have access to restricted cardholder data. Next, the internal organization systems that have access to sensitive credit card information should be assessed.

Penetration testing should not only cover systems but also processes that access the company’s network. If part of your cardholder data is stored outside the CDE environment, the systems should be tested to ensure they do not have any vulnerabilities that could make the in-house systems prone to infiltration by unauthorized users.

Finally, any “out of scope” systems that are used to store, transmit or process cardholder data should also be tested to ensure they are secure.

Evaluating Critical Systems

According to the PCI DSS, critical systems refer to the infrastructure, hardware, and processes that handle cardholder data. The systems can be public-facing devices, security configurations and general hardware that can store, transmit, and process credit card information.

Penetration testing can be carried out on various components of your credit card handling system, including firewalls, e-commerce redirection servers, authentication services, intrusion detection/prevention systems, among others. All these technology assets, together with those accessed and managed by privileged users, fall under critical systems.

Difference Between Application-Layer and Network-Layer Testing

Recent credit card infrastructure attacks have been focused on exploiting vulnerabilities in the application layers.

Many businesses use legacy applications, web applications, mobile applications, open source components, and in-house developed software as part of their payment processing infrastructure. Application-layer testing involves trying to penetrate the applications used by the organization by taking advantage of their vulnerabilities.

On the other hand, network-layer testing involves gauging the integrity of the devices that are part of an organization’s network. For example, the testing may involve trying to break into switches, routers, firewalls, and servers by exploiting their weaknesses. Typical vulnerabilities that could be in a network layer include misconfigured devices, default passwords, and unpatched systems.

Application-Layer and Network-Layer Tests Required by PCI DSS

To be PCI DDS-compliant, organizations need to test authentication, PA-DSS compliance applications, web applications, and a separate testing environment.

1. i) Authentication. Here, businesses have to review the roles and access to their employee environment. Moreover, they should ensure customers only access their data. When carrying out penetration testing, both cardholder customer controls and employer user controls should be evaluated.
2. ii) PA-DDS compliance applications. These applications do not have to be tested but their implementation should. The testing should focus on the exposed services and operating systems rather than the functionality of the payment system.

iii) Web applications. For companies that use third-party or commercial applications, it is critical to ensure that the programs are properly implemented, secured, and configured.

The above is an overview of PCI DSS penetration testing. 

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.