Penetration testing, often referred to as simply “pen testing,” when done properly is a highly effective tool in identifying vulnerabilities in your information systems that require remediation. For many merchants, however, pen testing is a time consuming and expensive endeavor that they would just as soon avoid.
A skilled pen tester acts like an actual cyber attacker and attempts to exploit vulnerabilities they identify in your information systems. Pen testing has traditionally focused on vulnerabilities in the perimeter network and at the application tier. These are the vulnerabilities that enable attackers to exploit the outer layer defenses. While that is extremely important, the unaddressed issue remains at the database tier. Today many organizations lack instrumentation and logging at the database tier which severely limits the effectiveness of the pen test. As a result, there’s no way of knowing what attacks are actually getting through to the database tier. Pen testing is about to change, however, due to new requirements set forth by the Payment Card Industry-Data Security Standard (PCI-DSS).
The PCI’s 12 mandatory requirements are designed to protect cardholder data from the threat of fraud or theft. Requirement 11.3 gets to the heart of the pen test, and it was revised in PCI-DSS version 3.0. This requirement states, “Implement a methodology for penetration testing that is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)”. While NIST SP800-115 is specifically mentioned in the PCI-DSS, presumably other industry-accepted penetration testing approaches such as the Open Source Security Testing Methodology Manual (OSSTMM), Open Web Application Security Project (OWASP) Testing Guide, or the Penetration Testing Execution Standard (PTES) would also be acceptable.
Requirement 11.3 is technically not a new requirement because pen testing has always been part of the PCI-DSS. However previous versions of the PCI standard made the naive assumption that a Qualified Security Assessor (QSA) would always conduct legitimate and useful pen tests in the spirit of the requirement, including at the core network database layer. But it’s an open secret that requirement 11.3 is an area of the PCI DSS that has been excessively abused. There were certainly QSAs who cut corners on this requirement, for example by seeking out dodgy pen testers who conducted essentially meaningless scans instead of actual in-depth pen testing. They aren’t bad people, but the tools have not been available for a viable pen test at the core network layer. The 3.0 version of the PCI-DSS seeks to end this practice. Merchants can no longer skirt around this requirement with weak pen tests and will be required to develop and adopt an official methodology for testing. With no methodology set, pen testers had free range in certifying compliance. Some QSA’s pen test methodology basically centered on the practice of “hiring some kid with a Nessus scanner off of Craigslist.” No more Wild West anymore.
A viable pen test requires that the pen tester have in-depth expertise across a wide spectrum of information systems and also that they follow a mutually agreed upon industry-accepted pen testing procedure. Experienced pen testers typically work with a variety of tools of their choosing, often in combination with manual techniques they’ve developed over the years. A rigorous pen test differs significantly from a vulnerability scan. A vulnerability scan basically tests and reports potential exposures for known vulnerabilities in an information system, such as open ports, rogue devices on the network, misconfigurations, patches that haven’t been applied, etc. Think of this as the “low hanging fruit” of system vulnerabilities. A vulnerability scan is normally automated and run periodically by a technician. It’s a good idea to conduct a vulnerability scan and remediate any issues prior to a thorough pen test. You want your pen tester to focus primarily on targeted attacks against your information systems and not on opportunistic attacks that a vulnerability scan will identify.
An effective PCI-DSS strategy is to corral card data environment into the smallest footprint possible, to both reduce the attack surface and the compliance complexity, and then segment this now “in scope” network from the rest of your networks. The in scope segmented information is stored in a database, which brings us back to the core of the network. It’s a requirement that the segmentation gets pen tested annually. Unfortunately often this segmentation isn’t done correctly and over time mistakes could have occurred that exposed the card data environment to the Internet. Now, PCI DSS 3.0requires that organizations identify the scope of their card data environment and have a pen test conducted that proves the card data environment is truly segmented from the rest of their network and the open Internet. Specifically, the PCI-DSS requirement 11.3.4 reads, “If segmentation is used to isolate the card data environment from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective.”
To get the most out of a thorough pen test the system should be well instrumented including at the database tier. If the instrument fully decodes the incoming SQL transactions and, using advanced behavioral analysis, alerts in real time when it identifies anomalous activity, this information can be extremely valuable at the conclusion of a pen test. For example, if card data database traffic is identified outside the card data environment, it’s obvious there’s a segmentation issue. Also, without instrumentation at the database tier you may not know just how close a pen test was to exploiting your databases.
Clearly these new pen testing requirements were long overdue and merchants will certainly have their work cut out for them adopting the new requirements. However merchants need to begin planning now to ensure they're on track and prepared for their first PCI DSS 3.0 assessment next year. And using a Core IDS, they can ensure they are instrumenting properly to meet the requirements for testing and protecting payment card information at the database tier. Let’s be honest, no one wants to end up in PCI DSS jail!
About the Author: Michael Sabo has over 30 years of marketing and strategic planning experience. Prior to DB Networks, Michael was at Intel Corporation where he was responsible for strategic planning at several of their divisions. Previously, Michael held senior marketing, business development, and product engineering positions in the telecommunications industry, including at AirFiber, Rhythms NetConnections, US West, and Contel. Michael earned a B.S. in Computer Science from Wright State University and a Masters in Management Information Systems from the University of Denver.