This post was originally published on Forbes
If you’ve ever run across a penetration test report, they usually look bleak. I should know; I’ve authored hundreds of them. By their very nature, they try to focus on the most egregious security issues within a system or network. Having an understanding of how an actual adversary would perceive the organization (which is a lot different than how a hired penetration tester does) and a grasp of the business and operational relevance of the tested environment are crucial to driving an effective result.
In combination with a good understanding of the business risks and how they relate to cybersecurity (see my previous article on utilizing two frameworks for securing a decentralized organization), a company’s security organization can provide context for such technical and scope-focused penetration tests. As we go through a report and align it with business risks, we should keep asking “why/what.†Why is this finding relevant? Why is this issue so critical? What is the root cause that allowed an asset to be exploited? What are the environmental factors that are part of this scenario?
Through connecting the technical report to the specific business environment and contextualizing it with the actual valuation of assets/risks, we end up with a highly enriched map. This map contains the original report findings along with additional elements that the penetration test did not address, such as processes, out-of-scope-systems, environmental elements, compensating controls and awareness/practices.
How does this play out? Consider a report finding related to the ability to steal credentials, escalate them to a higher privilege and gain access to a sensitive server. A penetration tester may suggest addressing this through technical means (hardening the server to allow access from predetermined hosts, locking down workstations to reduce privilege escalation effectiveness and adding MFA). However, this could also be amended by enforcing two-person authorization for critical actions (breaking the ability to abuse a compromised account), using password managers (reducing the chances of reused or guessable passwords) or even increasing logging visibility (to provide the SOC with insights on privileged activities through the systems). These remediations are less likely to turn up on a penetration test report, however, they are just as effective — if not more so — than the classic ones that only address the common technical aspects of the issue.
By no means should this be read as an encouragement to ignore the report findings from a penetration test, but rather, it should compel you to enhance them within the business context and make them more applicable for your organization. Many of these tests are done through narrow scoping, so as you get more proficient in contextualizing the results, you’ll be able to work more closely with your penetration testers and guide them to provide tests and results that are attuned to your business’ needs.
Rather than taking these penetration test results as gospel, and instead of accounting for the specific business environment and risks (and, yes, the culture, practices and tolerance), security organizations can provide more effective and longer-lasting mitigations to security gaps, perhaps even lowering the severity of seemingly critical issues to negligible ones. By being a true partner in the organization, instead of limiting ourselves to a technical watch-guard, we can more easily come to acceptance and cooperation — not only from the technical teams we work with, but also from business leadership.
Leave a Reply