When it comes to compliance, we find that most startups and small and medium-sized businesses have more questions than answers.
Some are existing pentesting customers who suddenly need to deal with a new audit. Others are new customers who come to us because their compliance framework requires penetration testing — or they think it may. Most are sorting out their responsibilities under at least one of the most common compliance frameworks: NIST 800-53, ISO 27001, SOC 2, PCI-DSS and HIPAA. In almost all cases, their questions are similar:
- What kind of pentesting must we do to achieve compliance?
- How should we set up a pentesting program?
- Does pentesting for one compliance framework matter for other frameworks?
- How can we scale our pentesting program without draining our IT security budget?
That’s why we’ve released a free ebook called the “Beginner’s Guide to Compliance-Driven Pentesting.” It pulls together your most common questions about the role of pentesting with the best approaches we’ve found to the compliance frameworks you’re likely to encounter. In this post I’ll highlight some of the main points of the ebook to show you what you’ll learn from it.
How does pentesting fit into compliance frameworks?
The world is full of compliance frameworks, and here are the five that come up most frequently in conversations with our customers: NIST 800-53, ISO 27001, SOC 2, PCI-DSS and HIPAA. They’re the ones of most interest to both US-based and international businesses, and many of their security controls — particularly where pentesting comes in — overlap. That’s good news for you, as I’ll explain below.
Even though security is at the heart of compliance, the role of pentesting is vague in many frameworks. So, when customers ask us where pentesting comes in, the answer is there, but it isn’t always clear.
-
NIST 800-53 is a set of security controls and procedures from the National Institute for Standards and Technology, designed for U.S. federal agencies. If you service such an agency, then you have to comply with NIST 800-53. “Penetration testing” is called out specifically in section CA-8, and other security assessments and controls are mentioned that pentesting can satisfy.
-
ISO 27001 is popular globally. Although it’s voluntary, if it’s important to your company to do business outside the U.S., then ISO 27001 certification will likely prove valuable. Pentesting is relevant to two of its controls in particular, which touch on application and network vulnerabilities.
-
System and Organization Controls (SOC) 2 is another voluntary framework. SOC 2 certification indicates that your company takes the protection of customer data seriously. If you provide cloud services, offer Software-as-a-Service (SaaS), or manage or host data for your customers, SOC 2 compliance is probably on your radar. CC4.1 COSO Principle 16 (page 26) specifically includes “penetration testing” among ongoing and separate evaluations.
-
If your company accepts payment cards, then it must comply with the Payment Card Industry Data Security Standard (PCI-DSS). Compliance requires that you “implement a methodology for penetration testing,” and the PCI Security Standards Council explains the requirement in considerable detail.
-
The Health Insurance Portability and Accountability Act (HIPAA) focuses on protecting patients’ “electronic protected health information” (e-PHI). It affects companies that provide medical services in the U.S. or work with U.S. medical providers. Its Security Rule calls for risk analysis and management, including regularly reviewing records to track access to e-PHI and detect security incidents, and periodically evaluating the effectiveness of security measures.
So, besides helping you comply with a framework that calls for it specifically, pentesting can bolster your compliance with other frameworks, both now and in the future.
Which systems and assets should you pentest, and how frequently?
These are two more areas that are over-questioned and under-answered. As an security professional, you appreciate the need to find, track and fix vulnerabilities. That, of course, is common to cybersecurity frameworks everywhere. Of the five I’ve outlined, only PCI-DSS specifies what to pentest: the cardholder data environment (CDE) and all systems and networks connected to it. It also specifies testing from both inside and outside the network perimeter.
As for frequency, PCI-DSS is the only major framework to specify, calling for pentesting “[...] at least annually and anytime there is a significant infrastructure or application upgrade or modification.” The others are more ambiguous, but best practices call for pentesting after major infrastructure changes or credible reports of new vulnerabilities.
That doesn’t give most security professionals much to go on. Pentesting just once a year is not often enough, though, for reasons I describe in the ebook.
Next step: Get the ebook & learn more about pentesting in compliance
Here’s one final question we often hear: “If the compliance framework we want doesn’t explicitly require or mention pentesting, then why should we do anything more than ordinary vuln scanning?”
Our rule of thumb is that compliance does not equal security, and companies should always think about how to evolve and continually improve their programs. As a layer of defense, pentesting does a more thorough job of uncovering security weaknesses than typical vuln scanning, particularly business logic flaws, chained vulnerabilities and complex multi-step operations. It enables you to strengthen your security posture actively.
Download the free ebook “Beginner’s Guide to Compliance-Driven Pentesting” now and find out more about the role of pentesting in your company’s compliance effort. It may not answer all of your questions, but it will surely get through the first round of them — and for the rest, we’re always available to help.
