Assumed Breach? I Thought I Bought a Penetration Test!

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 our 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 our 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
  • We offer threat emulation exercises as a separate service.
• A vulnerability scan
  • We are proud of our “hands-on-keyboard” work and will never sell a vulnerability scan and call it a penetration test. We do offer vulnerability assessments as a separate service.
• Meant to find every issue in every nook and cranny in your environment
  • We find as many valid attack paths as possible to sensitive data and privileged access given the parameters of the engagement.
• A full remediation plan
  • We do provide resources and recommendations to assist you in remediation efforts but will not pretend to know your environment as well as you do.

I hope that this primer has helped you understand the method to our madness and the intent of our internal network testing. As always, if you have any questions on what we do and how we do it, please reach out to us!