When you hear the phrase “penetration test,” what do you think of? I’ve asked this question to dozens of security professionals and I received a different answer from each person I asked. Penetration tests are well-known requirements in the cybersecurity industry however they mean something different depending on who you are talking to and the organization they work for. This article discusses how we should reconsider the evaluation of penetration tests in cybersecurity compliance assessments.
By AJ Yawn, Co-Founder and CEO of ByteChek
Requirements to complete a cybersecurity compliance assessment are unavoidable whether you’re working with the government, financial institutions, health care providers, software companies, or any entities that care about protecting their sensitive information. The assessment type will vary depending on your customers, your business model, and your company’s maturity. There are plenty of common frameworks and standards every security leader is familiar with, such as SOC2, ISO 27001, HIPAA, HITRUST, CMMC (NIST-800-171), FedRAMP, and CSA STAR.
Each of these compliance standards or frameworks requires similar controls, one of those control activities being penetration tests. But what exactly does that mean? Auditors have accepted blanket penetration tests to meet compliance requirements for far too long. The level of depth between a penetration test taken by one auditor sometimes completely varies from other assessors. This leaves a confused reader of compliance reports to ask this question:
What does it mean when your compliance report says, “A penetration test is completed on at least an annual basis”?
Hackable by Ted Harrington, a #1 best-selling book, discusses how to ensure application security is completed correctly and adds value. Harrington outlines the key differences between a penetration test, vulnerability scan, and vulnerability assessments. I consider Hackable a must-read for every security professional as application security is important to understand, regardless of your role or expertise.
Why should auditors rethink evaluating penetration tests?
An audit is an activity focused on evaluating controls and their operating effectiveness. Each control serves a specific purpose – to mitigate risk. When an organization undergoes a penetration test, they are generally looking to gain a comprehensive understanding of the weaknesses of their application’s security posture to ultimately reduce the risk of a breach or malicious event from a bad actor.
When we think about an annual penetration test activity, does it reduce this risk? What does it even mean? The term itself is no longer clear, as different providers mean different things when they use it. When you think about penetration testing, keep two things in mind:
- Security is never done. An annual scan or test will only be useful for a short timeframe after the test, and modern technical environments are changing by the second.
- A penetration test control without a detailed methodology outlining the type of test (white box vs. black box) does not provide enough information to the readers of the report if the test that was performed reduced the risk of vulnerabilities in the application.
Good security requires context; good compliance requires the same
Context is critical in security. Security professionals worldwide understand that there is no one-size-fits-all approach to security, but we have accepted this mindset in cybersecurity compliance. For more mature organizations with a robust vulnerability management program (which probably includes regular, tailored vulnerability assessments), a penetration test makes a ton of sense. Ted did a great job explaining when a penetration test makes sense versus a vulnerability assessment or a scan, so I won’t dive into those details here.
Most companies need vulnerability assessments. A vulnerability assessment is a “comprehensive, rigorous, manual effort to discover security vulnerabilities, assign severity ratings to them, and determine how to fix them. The objective is to find as many as possible and remediate them. As a result, you understand and reduce risk.” Hackable, p. 50
The above quote from Hackable is a perfect description of what auditors should be looking for instead of the blanket penetration tests. A vulnerability assessment provides a more detailed view into whether or not an application is appropriately mitigating risks, which is ultimately the compliance assessment goal to determine if the organization has controls to mitigate risk properly.
Security professionals around the world are lifelong learners, addicted to finding new ways to solve security problems. As a security practitioner, I immediately think about my customers and the security community when I find out further information. I want to run out, scream, and tell everyone I know the new knowledge I gained so that they are more secure and informed. At ByteChek, we are updating our control statement for our platform and SOC2 examinations. We will no longer include a generic penetration test control and transition to a vulnerability assessment control statement. We are only a small piece of the large cybersecurity compliance space, but we must take small steps to improve the industry. Cybersecurity compliance assessments should add security value to the organizations undergoing audits. The only way this will occur is if compliance professionals are consistently evaluating controls from a security point of view. Security evolves, and compliance assessments should evolve too.
About the Author
AJ Yawn is the Co-Founder and CEO of ByteChek. He is a seasoned cloud security professional that possesses over a decade of senior information security experience with extensive experience managing a wide range of cybersecurity compliance assessments (SOC 2, ISO 27001, HIPAA, etc.) for a variety of SaaS, IaaS, and PaaS providers.
AJ advises startups on cloud security and serves on the Board of Directors of the (ISC)2 Miami chapter as the Education Chair, he is also a Founding Board member of the National Association of Black Compliance and Risk Management professions, regularly speaks on information security podcasts, events, and he contributes blogs and articles to the information security community including publications such as CISOMag, InfosecMag, HackerNoon, and (ISC)2.
Disclaimer
The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.
