Lately, I’ve been having a lot of conversations with cybersecurity leaders about a concept I’ve been using called the Security Event Horizon. The basic idea is that the concept of “defense in depth” in the security world is a misnomer. Security technologies rarely have any overlap in the scope of what types of attack tooling or behavior they apply to and typically there’s only a single security control/technology between an attacker launching and landing a breach attempt. Prevention remains important, but there is a point in the attack lifecycle where prevention-oriented thinking stops being a relevant model, and detection, context, and response become the things that matter most.
That may sound obvious to people who have spent a lot of time in security operations, but I think it is worth being explicit about because much of the security industry still talks about the problem as if the right collection of preventive controls can make compromise an exceptional condition. In real environments, that’s not how things work.
Why is defense in depth a misnomer?
Modern enterprises are too large, too distributed, and too dynamic for that assumption to hold. They run large estates of cloud infrastructure, SaaS applications, endpoint fleets, identity systems, APIs, third-party services, legacy applications, and business-critical systems that are difficult or impossible to patch in a realistic timeframe. Even well-run organizations have unknown assets, exposed services, configuration drift, over-permissioned identities, and systems that cannot be patched at the moment a fix becomes available.
Obviously, prevention is still necessary. Patching, hardening, segmentation, identity controls, secure configuration, email security, endpoint prevention, and vulnerability management all reduce the amount of opportunity an attacker has. The issue is that prevention is not a complete operating model. At enterprise scale, some percentage of preventive controls will fail, and the security architecture has to be designed with that assumption in mind.
AI makes this problem more acute. Attackers are going to have better tools for finding vulnerabilities, producing exploit variants, automating reconnaissance, generating convincing social engineering, and adapting their activity as defenders respond. Defenders will use AI as well, but the asymmetry around time matters. It is much easier to find one exploitable path than it is to prove that every exploitable path across a large enterprise has been removed.
Additional reading: What’s Next for the Enterprise After Two GenAI Tidal Waves
Why the Security Event Horizon
This is why I developed the Security Event Horizon idea and think it’s important to discuss.
In this model, there is a distinction between cause-based detection and effect-based detection. Cause-based detection is focused on the thing that initiates or enables the attack: a vulnerability, exploit, malicious file, command, infrastructure indicator, phishing message, or known technique. This is where a lot of prevention and blocking logic naturally lives.
Effect-based detection is focused on what happens after the initial attack has succeeded. Once an attacker is in the environment, they have work to do. They have to authenticate, enumerate, move, escalate, persist, communicate, stage data, and eventually act on objectives. Those behaviors create effects in the environment. The defender’s job is to see those effects, understand them in context, and respond before the attacker reaches impact.
MITRE ATT&CK is a useful way to describe this transition. The earlier phases of an attack tend to align naturally with prevention-oriented controls. As an attack progresses into discovery, credential access, lateral movement, command and control, collection, and exfiltration, the environment starts producing behavioral evidence. At that point the problem is less about whether a single object is known to be bad and more about whether a sequence of activity makes sense.
Attackers increasingly use legitimate credentials, legitimate protocols, legitimate administrative tools, and legitimate cloud services. A lot of what they do does not look malicious when viewed in isolation. A login may be valid. A PowerShell command may be allowed. A connection between two systems may use an approved protocol. A cloud API call may be syntactically normal. The question is whether the behavior is consistent with how that user, host, workload, or application normally operates, and whether it fits into a broader attack pattern.
Detection has to be more than alert collection. Producing more signals for an analyst to triage doesn’t really get us where we want to go, but being in a position to understand attack progression is what needs to happen in the post-compromise environment. This has a few practical implications.
Understanding how cyberattacks progress
First, prevention isn’t risk elimination, it needs to be treated as risk reduction. It reduces attacker opportunity and should be continuously improved, but it should not be the assumption on which the rest of the architecture depends.
Second, detection has to be designed around the parts of the attack that are observable after prevention fails. Network activity, identity behavior, cloud control-plane activity, SaaS usage, endpoint telemetry, and data movement all provide different views of attacker behavior. None of them is sufficient by itself in a modern security architecture.
Third, context is essential andit matters as much as telemetry. Seeing an event is not the same thing as understanding it. Defenders need to know what the asset is, who the identity belongs to, what normal behavior looks like, whether the system is exposed, what privileges are involved, and how the activity relates to other events across the environment.
Finally, response has to be tied to attack state. The right response to a noisy early signal is different from the right response to confirmed lateral movement or active data staging. Security operations teams need to know not just that something happened, but where they are in the attack lifecycle, and ideally, what the attacker is likely trying to do next.
This is the point of the Security Event Horizon Framework. It is a way to reason about where different technologies operate, what kinds of signals they produce, and where their value changes as an attack moves from attempted compromise to active intrusion.
Prevention will always be a core part of security architecture. But in a world where AI accelerates vulnerability discovery and exploitation, and where patching every deployed software and hardware component across every enterprise is not realistic, security programs need to be explicit about what happens after prevention fails and architect for it as well.
That is where detection and response have to carry the load. Not as an afterthought or a collection of disconnected alerts, but as a model for understanding attacker behavior across the environment.
The practical question for security operators and leaders is straightforward. When an attacker gets past the controls that were supposed to stop them, can you still see what they are doing, understand how far they have progressed, and respond before the activity becomes a material business event?
Vectra AI is very uniquely built to provide the signals and continuous capability required to secure the hybrid, software defined, enterprise by providing detection and response using data sets and technologies that don’t exist from any other single company. If you’re serious about a security architecture that provides capability beyond the Event Horizon, take a look.
For more from Marty Roesch on the Security Event Horizon, tune in to the Hunt Club Podcast.