The concepts of visibility, observability, detection, and mitigation are foundational to cybersecurity–security architecture and detection engineering in particular–and technology operations in general. They’re useful for communicating at almost every level, within technical teams but also to organizational peers and leadership.
I’ve found myself thinking about and explaining the relationship between them time and again, specifically as a model for how we enable and mature security operations.
Visibility
Visibility is knowing that an asset exists.
Of these terms, visibility is the lowest common denominator. For assets that are visible and that we’re responsible for protecting, we then want to consider gaining observability.
Observability
Observability indicates that we’re collecting some useful combination of activity, state, or outputs from a given system.
Practically speaking, it means that we’re collecting system, network, application, and other relevant logs, and ideally storing them in a central location such as a log aggregator or SIEM.
We can’t detect what we can’t see, so observability is a prerequisite for detection. And while it may not be required for all mitigations (e.g., you may purchase a point solution that mitigates a particular condition but provides no observability), there’s a strong argument to be made that observability is foundational to any ongoing security operations function, of which mitigation activities are a key part.
Lastly, observability as a metric may be the most important of all. As a security leader, I can think of few metrics that are more useful for gauging whether assets or attack surface are manageable–simply knowing about an asset means little if you have no insight into where, how, and by whom it’s being used.
Read more in-depth thoughts on observability here.
Detection
Detection is the act of applying analytics or intelligence to observable events for the purpose of identifying things of interest. In the context of cybersecurity, we detect threats.
Detection happens in a number of ways (not an exhaustive list, and note that there are absolutely relationships between these):
- Turnkey or out-of-the-box detection, typically in the form of an alert from a security product
- Detection engineering, a process where the output is analytics aimed to make detection repeatable, measurable, and scalable
- Threat hunting, a process where the output is investigative leads that must be run to ground (and should feed detection engineering)
- More . . .
There are plenty of ways to measure detection. We have outcome-based measures like time to detect (MTTD), respond, and recover (together, the MTTRs). And we have internal or maturity measures, like detection coverage.
Mitigation
Mitigation is easiest to think of as a harm reduction measure taken in response to a detected threat.
Mitigations can be preventative, detective, or response measures. Mitigation in the form of early-stage prevention, such as patching a software vulnerability or wholesale blocking of undesirable data, is ideal but not always possible. There are plenty of cases where the best you can do is respond faster or otherwise contain damage.
In practice, mitigation is an exercise in looking at the things that happen leading up to and following threat detection:
- Where did it come from?
- What did it do?
- What’s its next move?
And then figuring out how and at what points you’re able to disrupt the threat, in whole or in part.
