Some regulatory frameworks explicitly require penetration testing from eligible parties. But even those that don’t require it outright may still have other mandates that would be met or exceeded efficiently by conducting penetration testing. Thus, penetration assessments are critical for your security infrastructure.
Is your organization ready to pen test for compliance? Request a consultation to learn how.
Regulatory Compliance Penetration Testing, Explained
Conducting a penetration assessment or pen test means simulating an attack on your systems to study the way cybercriminals would behave so that you can prevent a real-world attack. It’s one of the best ways to meet any cybersecurity objective, including regulatory compliance.
The best way to integrate penetration testing into compliance management is to consider:
- How to meet explicit guidelines for penetration testing laid out in regulatory guides
- How to penetration test strategically for implicit requirements and other concerns
- What other regulatory compliance-related obstacles pen testing can alleviate
Working with quality pen testing teams or augmented cybersecurity staff, such as a security advisor or virtual chief information security officer, will help you streamline your compliance.
Explicit Regulatory Pen Testing Requirements
Organizations that operate in protected industries are often subject to regulatory frameworks. In some of these frameworks, there are specific rules that require penetration vulnerability testing.
In particular, regulatory rules about pen testing typically require it to be conducted in specific ways, under certain conditions, or at prescribed frequencies. Following these rules generally requires working with service providers to conduct external, internal, or hybrid pen testing.
For reference, these three major varieties of pen testing operate as follows:
- External pen tests – These tests simulate attacks from unknown attackers who have little to no prior knowledge of an organization’s IT landscape. They assess perimeter defense efficacy, as testers typically try to enter into systems swiftly and undetected.
- Internal pen tests – These tests simulate attackers from insider threats such as a disgruntled current or former employee. They assess access control, communications infrastructure, and other mechanisms to detect and prevent illicit internal movement.
- Hybrid pen tests – These tests simulate attacks from the external phase into the internal phase, assessing holistic incident response and mitigation capacities.
All these tests ensure that controls maintain the required levels of data privacy under stress.
Typically, regulatory frameworks are concerned with one or more primary kinds of sensitive data. The enumerated controls govern visibility, access control, and risk mitigation tactics to prevent unauthorized access to that information. Pen testing generally falls under the risk mitigation category, ensuring that risks to protected information are known and accounted for.
Business Operations Regulations: PCI DSS
The Payment Card Industry (PCI) Data Security Standards (DSS) are some of the most widely applicable regulations, despite being overseen by a conglomerate of private interests rather than a governmental body. The Security Standards Council (SSC) requires most organizations that process credit card payments and/or cardholder data (CHD) to comply with the ruleset.
Requirement 11.4 of the PCI DSS requires all eligible organizations to conduct external and internal pen testing regularly and correct all security weaknesses and exploitable vulnerabilities.
PCI DSS Requirement 11.4 breaks down further into the following specifications:
- 11.4.1 – Pen testing methods are defined, documented, and implemented, including:
-
-
- Using approaches recognized within the industry
- Ensuring coverage for the entire cardholder data environment
- Testing both externally and internally and for
- Testing for validation and scope reduction
- Targeting the application layer
- Targeting the network layer
- Reviewing vulnerabilities from the prior 12 months
- Documenting approaches to addressing identified risks
- Retaining records for at least 12 months
-
- 11.4.2 – Internal penetration testing is performed according to defined methodology, at least once every 12 months, after major changes, and by qualified external providers.
- 11.4.3 – External penetration testing is performed according to defined methodology, at least once every 12 months, after major changes, and by qualified external providers.
- 11.4.4 – Vulnerabilities uncovered by penetration testing are corrected—
-
- Corrections adhere to internal risk assessments, per DSS Requirement 6.3.1
- Penetration assessments are repeated to certify that corrections worked
What this means is that, if your organization processes card payments or CHD, there is a good chance you need to integrate regular internal and external pen testing to maintain compliance.
Failing to can result in fines and seizure of service from financial service providers.
Governmental Regulations: CMMC and NIST
If your organization wants to work with the Department of Defense (DoD), you will need to achieve Cybersecurity Maturity Model Certification (CMMC). The specific level of compliance you need will be specified on the DoD contract you compete for; at present, Level 1 (the lowest) does not require penetration testing. However, Level 2 (intermediate) does in many cases.
The CMMC framework, which is based on the National Institue for Standards and Technology (NIST) Special Publications (SP) 800-171 and 800-172, specifies in Practice RA.L2-3.11.2 that eligible organizations need to scan for vulnerabilities across systems and applications regularly.
Unlike PCI DSS Requirement 11.4, CMMC Practice RA.L2-3.11.2 does not require penetration testing in all cases. However, the documentation does explicitly state that penetration testing may be required if custom software is used. The rule’s discussion also clearly states that the required vulnerability assessment and penetration testing should be an ongoing practice.
Furthermore, the exact specifications required for Level 3 (highest security) have not yet been finalized. There is a good chance that they will require more stringent protections, including pen testing, across all systems that come into contact with Controlled Unclassified Information (CUI).
If your organization anticipates working with the DoD, you should consider pen testing.
Implicit Regulatory Pen Testing Requirements
Some regulations do not require penetration testing. Others mandate it only in some cases, and still others may suggest it without actually obligating eligible organizations to conduct pen tests.
As the CMMC’s present rules regarding vulnerability testing at Level 2 illustrate, regulatory requirements often touch on penetration assessments without requiring them outright. Often, language about vulnerability scanning or vulnerability tests suggests that penetration testing might be a best practice if not an actual requirement. And, in many cases (see below), pen testing is a de facto requirement that most organizations opt into to ensure their compliance.
On another level entirely, many organizations are faced with multiple compliance frameworks simultaneously—some of which require penetration testing, and others of which do not.
In all of these cases, targeted compliance pen testing is highly recommended.
Industry-Specific Requirements: HIPAA / HITECH
A regulation with surprisingly wide reach is the Health Insurance Portability and Accountability Act of 1996 (HIPAA). While seemingly an industry-specific ruleset, HIPAA applies far beyond covered entities such as healthcare providers, insurance plans, and clearinghouses. Business associates of covered entities, such as legal service providers, may also be subject to its rules.
HIPAA does not explicitly require penetration testing. However, as part of the HIPAA Security Rule, covered entities and business associates need to account for risks and vulnerabilities to protected health information (PHI) under their purview. Depending on your risk profile, it might be the case that penetration testing is the only way to generate a comprehensive list of risks and vulnerabilities impacting PHI. Ultimately, the Department of Health and Human Services (HHS) determines whether the scope of a risk analysis is appropriate—if an audit is needed.
Given that HIPAA compliance operates passively, and official assessments only happen if a HIPAA incident is suspected to have occurred, it’s best to avoid that potentiality altogether.
What this means is that, in practice, if your organization works with any covered entities, you may need to invest in HIPAA-compliant vulnerability testing services. These do not necessarily need to be penetration testing proper, but pen tests are often the most effective way to comply.
Cross-Industry Best Practices: SOC 2 and HITRUST
The American Institute of Certified Public Accountants (AICPA) System and Organization (SOC) standards are frameworks that ensure service organizations take precautions to protect financial and other sensitive data. SOC is not a universal standard, but partnerships with high enterprises often entail compliance, as clients may expect or request SOC 2 reporting. And, although SOC 2 does not explicitly require penetration testing, the same clients that demand a SOC 2 report often ask for penetration testing to verify its risk and vulnerability assessment assurances.
On a similar level, the HITRUST Alliance’s HITRUST CSF is an omnibus framework intended to streamline compliance across many regulatory contexts. Like SOC, it is not mandatory within a given industry or location. Instead, it is a gold standard that some business partners will expect.
Unlike SOC 2, the HITRUST CSF has extended documentation for penetration testing that meets specific industry guidelines (i.e., HIPAA, PCI DSS, etc.). Penetration testing with the HITRUST CSF in mind allows for individual tests to cover more ground and satisfy multiple obligations simultaneously—in the HITRUST Alliance’s parlance, “assess once, report many.”
Other Compliance Penetration Testing Considerations
Compliance is primarily about the things an organization can do to ensure that systems under its control are as secure as they can be. But its scope is not always limited to those systems.
Consider these examples from some of the regulatory frameworks covered above:
- HIPAA’s business associate rules dictate that compliance considerations need to be accounted for contractually; first and third parties share responsibilities of securing PHI.
- DoD contractors subject to CMMC need to ensure subcontractors working under them uphold their cybersecurity responsibilities to avoid compromising the safety of the DoD.
Issues like these point to the need for robust third-party risk management (TPRM), which treats risks to third parties as seriously as risks to your organization proper. Practical applications may include adding third-party assets to your vulnerability assessment penetration testing program.
Additionally, organizations need to be proactive about future growth and expansion within and across industries. If you anticipate potentially working with clients in a protected industry (i.e., healthcare) in the future, consider preparing with preliminary control implementation and penetration testing before any official compliance documentation process begins.
Optimize Your Compliance with Penetration Testing
If your organization is subject to one or more regulatory compliance frameworks, penetration testing might be required. And, even if it isn’t explicitly mandated, it’s still one of the best ways to ensure that your controls are functioning as they should be to protect sensitive classes of data.
At RSI Security, we believe that the right way is the only way to keep your systems protected. We’re committed to helping organizations like yours meet and exceed compliance obligations with targeted control implementation, assessment, and proactive measures like pen testing.
To learn more about vulnerability assessment and penetration testing, get in touch today!