Visibility, observability, detection, and mitigation in cybersecurity

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.

alt

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.

An open source catalog of offensive security tools Permalink

From Gwendal Le Coguic (@gwen001 / @gwendallecoguic), offsec.tools is a fairly wide-ranging collection of offensive security tools. At the time of publication, it includes close to 700 tools, though some very popular free tools (e.g., mimikatz, impacket) are missing, and the project’s appetite for cataloging commericial tools (e.g., Pegasus, FinFisher, etc.) is unclear.

Roundup of commercial spyware, digitial forensics technology use by governments Permalink

From the Carnegie Endowment for International Peace:

The dataset provides a global inventory of commercial spyware & digital forensics technology procured by governments. It focuses on three overarching questions: Which governments show evidence of procuring and using commercial spyware? Which private sector companies are involved and what are their countries of origin? What activities have governments used the technology for?

The leaderboard is interesting, albeit predictable.

Simple, measurable ATT&CK testing with Atomic Red Team

Updated June 2024 to support ATT&CK v15.1.

This Google Sheets template aims to make it easy to perform simple, measurable testing of MITRE ATT&CK techniques using Atomic Red Team or an adversary emulation solution of your choosing.

alt

To get started:

Choose the technique that you wish to test. To help prioritize your testing, incorporate rankings from public threat reports, your own intelligence, or any other mechanism that you choose. The top techniques from Red Canary’s annual Threat Detection Report are incorporated into this template for convenience.
Select a corresponding Atomic Red Team test. You can search for or browse tests by tactic, technique, or target platform here.
Document whether the test was:
- Observed in any manner, from system logs to network events
- Detected by any of your controls, which could be SIEM analytics, alerts from any of your security products, or activity detected by partners or service providers
- Mitigated by an existing secuirty control

This is based on the “ATT&CK in Excel” spreadsheet provided by MITRE, one of several resources for working with ATT&CK. It is based on the ATT&CK v12.1 release.

Get the template!

The most prolific ransomware groups in 2022

It’s 2023 and security firms are starting to release findings from 2022 threat data, notably their lists of the most active, impactful ransomware groups.

As with all threat reports, the findings and prevalence are subject to each firms’ visibility, methodology, etc. The data isn’t perfect and it’s not particularly actionable on its own, but it’s interesting and in aggregate can be a useful starting point for other types of analysis.

The leaderboard

This is not the product of original intelligence analysis. I’ve aggregated data from reports that contain ransomware group rankings, assigned points based on relative ranking, and this is the result.

alt

Read on for some thoughts re: how this type of data can be useful, followed by summary data and charts from each report.

The case for imperfect threat data

A good use case for these types of lists–and a way to make them actionable–is to look at tactics starting with initial access and progressing through the intrusion lifecycle. For each tactic, look for common vectors and MITRE ATT&CK techniques (some of this is readily available in the source reports below). The goal is to see whether we can glean good enough insights and do it quickly, assess risks, and take preventative measures.

This sounds simple and obvious because it is. The short list of “how ransomware happens” isn’t terribly long and few TTPs are novel. Unfortunately, it’s easy and common for teams to get wrapped up in the minutiae of threat modeling, risk quantification, etc.–perfect over plenty good enough–and in doing so they waste valuable time addressing high impact, high likelihood risks that are staring us right in the face.