What You Should Know About PCI DSS Penetration TestingPublished April 24, 2018 by Karen Walsh • 4 min read
Organizations who process payments need to comply with the Payment Card Industry Data Security Standard (PCS DSS) requirements to protect cardholder data. Although PCI DSS incorporates many prescriptive elements, penetration testing often confounds companies. Thus, to appropriately integrate PCI DSS compliance, organizations must find penetration testing methods that prove their controls protect their cardholder data environment.
Penetration Testing For PCI DSS
What are the primary components of penetration testing?
Three types of pen testing for PCI DSS exist. Black-box assessments provide no information before the test starts. Meanwhile, companies often provide penetration testers with network and application details for white-box assessments. Finally, grey-box assessments incorporate partial information about target systems.
For PCI DSS testing, white-box or grey-box assessments offer organizations better insight tint their environments. The information provided by the organization streamlines the testing thus being less expensive and requiring fewer resources and time.
How is a penetration test different a vulnerability scan?
Vulnerability scans intent to identify, rank, and report system vulnerabilities that can compromise a system. Traditionally, organizations must engage in quarterly vulnerability scans or after making significant changes to the data environment. Most often, vulnerability scans use automated tools followed up with manual verification of issues.
Penetration testing, however, purposefully seeks to exploit vulnerabilities by looking for gaps in security features. More specifically, penetration testing is an active process of trying to break a system while vulnerability scanning passively reviews a landscape for potential problems. This proactive manual process takes more time, provides a more comprehensive resource, and therefore, must only occur annually rather than quarterly.
How do organizations determine the scope of their cardholder data environment (CDE)?
Officially, the PCI security standard defines CDE as “the people, process, and technology that store, process, or transmit cardholder or sensitive authentication data.” Thus, determining the scope for PCI compliance must be an organization’s first step in the penetration testing process.
The guidance notes for aspects of CDE perimeter organizations can consider. First, payment processors must assess unique access to public networks, including restricted access to individual external IP addresses.
Next, organizations must look at the internal critical systems that access the information. Thus, testing must incorporate application and network assessments.
If organizations have segmented their information, then they must test the systems deemed outside the CDE environment to ensure no cross-contamination exists. This testing ensures that the organization’s segmentation controls work and do keep information separated.
Finally, deeming a system or network “out of scope” requires ensuring its compromise does not affect cardholder data. Thus, penetration testing of “out of scope” environments proves segmentation controls work in practice not just in policy.
What is a “critical system”?
PCI DSS labels systems involved in processing or protecting cardholder data as “critical.” These can be security systems, public-facing devices, and systems or anything that stores, process, or transmits cardholder data.
As regards penetration testing, firewalls, intrusion-detection systems/intrusion-prevention systems, authentication servers, or e-commerce redirection servers may fall within this definition. Critical systems incorporate all those technology assets privileged users use to manage and support CDE.
What is the difference between application-layer and network-layer testing?
Recently, malicious attackers focus on vulnerabilities in the application layer. Many companies use legacy applications, third-party software, open source components, mobile application, web applications, or internally developed software as part of their payment processing strategy. Application-layer testing involves trying to break software for weaknesses.
Meanwhile, network layer testing focuses on devices within an organization’s environment. For example, network layer testing seeks to identify weaknesses in servers, firewalls, routers, and switches. Vulnerabilities in this layer include unpatched systems, default passwords, and misconfigured devices.
What are the application-layer and network-layer tests required by PCI DSS?
PCI DSS penetration testing standards require that organizations test authentication, PA-DSS compliance applications, web applications, and a separate testing environment.
Regarding authentication, organizations should review the roles and access to their employee environment. However, they also need to ensure customers only access their data. Thus a penetration tester must evaluate both workforce user controls and cardholder customer controls.
Organizations using PA-DSS validated application, penetrations testing must be done on the implementation of the application, even though the application itself does not need testing. Thus, the testing should focus on the operating system and exposed services rather than the payment application’s functionality.
Web applications provide a different problem. Organizations use commercial interfaces, such as web-mail or document sharing tools, not specifically tailored to their needs. Thus, rather than an application layer penetration test, companies should focus on the network-layer analysis to ensure appropriate implementation, configuration, and maintenance.
Finally, the nature of penetration testing often disrupts daily processes. Thus, to avoid business interruption and speed the testing process, organizations should create a specific testing environment that mirrors reality.
What is a “significant change”?
The definition of a significant change requiring additional penetration testing rests on the organization’s risk assessment. Since PCI DSS does not prescribe a definition of significant change, organizations need to determine whether upgrades or modifications can impact network security or allow cardholder data access. If an upgrade or implementation can risk the CDE, then the organization should ensure penetration testing occurs.
How can automating compliance help ease the burden of PCI DSS penetration testing?
With ZenGRC, organizations can rapidly deploy a governance system that provides easy-to-read insights. For example, our PCI DSS compliance dashboard allows organizations to review control health at a glance while also listing critical issues facing the organization.
Penetration testing’s depth and cost means organizations must limit the time spent on it while meeting requirements. Meanwhile, vulnerability scanning limits a company’s insights to the point in time during which the scan was run.
ZenGRC’s ongoing monitoring abilities provide updated, in-the-moment insights enabling organizations to continually respond to changing threats and vulnerabilities in a continuously evolving threat environment. Moreover, organizations can store their penetration test and audit findings on the ZenGRC platform to help enable better cross-enterprise outcomes.
For more information about how ZenGRC can help ease the pain of PCI DSS penetration testing, schedule a demo today.