In organizations of all sizes, there are usually various forms of Security Testing, such as Penetration Testing, Application Security, and Red Teaming. When this happens, many different teams may be spending time evaluating the Public Attack Surface. I discussed Public Attack Surfaces in my last brief, but I wanted to take a moment to address the debated topic of Assumed Compromise. Assumed Compromise is when a Red Team skips the initial steps of an attack chain that requires them to gain a foothold and instead starts at code execution, typically inside the internal network or the organization’s environment.

A comparison to physical buildings

For those who are not working in security or, for other reasons, don’t know what an Assumed Compromise is, you can think of your organization’s network like a physical building. With a physical building, you’re attempting to keep out unauthorized individuals and protect what is inside. You may think keeping all doors and windows closed and locked is the most effective method, and this is how most companies do security. However, if a news outlet reported a weakness in the front door lock that allowed unauthorized users to unlock it trivially, you would be left scrambling to fix the issue if you valued what was inside. This is the experience most organizations have when a security vulnerability is disclosed in software used by their company. But what happens if you are unaware or don’t have time to fix the front door? You are most likely left defenseless if you don’t have defense-in-depth measures (security features that assume your first line of defense may be breached and provide additional layers of security). In the physical building comparison, this would be akin to having a motion detector protecting your most valuable assets. An attempt to approach or steal those assets would set off an alarm. In this case, you may be slightly less concerned about the inevitability of leaving a door open or about a vulnerability because you know your security layers are tuned to protect your critical assets, and this is, of course, the entire purpose of the physical building. correct?

Defense-in-Depth in your organization

Returning to the topic of organizations, when you mature your thinking beyond perimeter security or the first line of defense, you’re much better prepared to protect your critical assets. That means collecting logs from networks, systems, and users to understand when a behavior or anomaly occurs. When proper alerting and response are in place, you can feel more confident that you can respond if an adversary targets your critical assets. This is not to say that you should not properly manage, update, and secure your Public Attack Surface, but that you should be prepared for the inevitability that adversaries could undermine your efforts, and that layering security is important. With supply chain attacks, AI-assisted perimeter cracking, and high phishing success rates, this is a very valid assumption.

So should red Team’s assume compromise?

I’ve said in the past that Red Teams exist to “Remove Assumptions,” so it all depends on what assumptions you currently have, e.g., can an adversary leverage a vulnerability on the public attack surface to breach your perimeter and gain internal access? You may not have answered these questions; however, the public attack surface can get very crowded with Security Testers. In these cases, if you feel you have sufficient information about your Public Attack Surface, it may be a better use of your Red Team’s time to start from the Assumed Compromise scenario. You can start the Red Team in various situations, such as a successful supply chain attack (code execution on a developer’s system) or a successful phishing attack (code execution on a business user’s desktop). In these cases, the Red Team can do what truly separates them from other types of Security Testing: demonstrate the impact of those positions. If you choose this path, the Red Team can dedicate its time to helping you tune the “motion sensors” that protect the critical assets and exercise your Blue Team’s ability to respond to alerts or the lack thereof. In my opinion, this is the best way to leverage your Red Team (with the caveat that other Security Testing teams remove the other assumptions).