We hacker types use a lingo of our own to describe our work, and many of our clients aren’t familiar with the jargon. One of those terms is “assumed breach” penetration testing. Although we try our level best to speak and write in a way that gets our point across to clients, we sometimes slip up in ways that make us sound confusing. That said, I think that the term “assumed breach” is particularly important to explain.
First, let’s go over the more traditional (and in our opinion, “legacy” term) of “internal network penetration testing.” All this means is that we are testing the internal network, as opposed to testing what an attacker can do to the assets you’ve made accessible on the Internet. This assumes (wink wink) that an attacker has made their way inside, with the goal of determining what they can do once there. “Inside” could mean access to either on-premises assets or cloud environments. An attacker may achieve this level of access in one of several ways, such as:
A user downloads and opens a malicious file attachment they were sent during a phishing attack.
An Internet facing web application with serious flaws allows interaction with the underlying infrastructure housed on your internal network.
Credentials such as passwords, SSH keys, authentication tokens, or others are found on the Internet, allowing an attacker to access your internal environment remotely via VPN connection, remote desktop, and more.
An insider threat sells access to your internal environment.
A bad actor physically enters your office space and plants a device that provides them with remote access to your environment.
Regardless of the method, that bad actor is now inside your environment. So why do we call our internal penetration test an assumed breach test? Time!
The access that I just laid out may take an hour, may take a day, may take weeks depending on the controls clients have in place. But if the goal is squarely focused on the security gaps in the internal network, then it makes sense to “assume” that an attacker has already made their way inside one way or another. This is both cost and time effective for clients, as we are testing from the assumption that the bad guys made it inside already.
Now that we have that nailed down, let’s talk about what an assumed breach penetration test is not:
Minutely focused on your detection and response capabilities
We do want to see alerts you receive that may aid in those efforts.
A threat emulation exercise
A vulnerability scan
Meant to find every issue in every nook and cranny in your environment
A full remediation plan
I hope that this primer has helped you understand the method to the madness and the intent of internal network testing.
Kommentare