Why It’s Time to Evolve from Threat-centric to Compromise-centric Security
By Martin Roesch
For the last five years, it has taken organizations an average of 280 days – about 9 months – to identify and contain a breach. When organizations can shorten that to under 200 days, they can save on average $1.02 million. Yet, many are still set in the comfort of old ways and aren’t taking the steps to shorten the time to action.
At Netography, we believe that even 200 days is far too long. As an industry, we can do much better. However, it will require all of us to change our focus when we think about detection.
I started beating the drum about this 20 years ago at Sourcefire using the framework of the threat continuum – the before, during, and after phases of a compromise. I spent a large amount of my career concerning myself with detecting attacks as they were happening; “enumerating bad” as some called it back in the early days. Looking for known attacks made a lot of sense because, in theory, if you could see them, then you could prevent them from landing on the targeted devices or at least alert operators so that they could initiate rapid response. I called this approach of detecting known attacks the “threat-centric” model.
Since then, and especially over the last five years, the environment in which security professionals operate has changed dramatically to the point where the quote “It’s not a matter of if, but when and how you get attacked” is now a cliché.
The problem has turned into one of scale – alerts constantly fire for detections that are not actually representative of compromise in a user’s environment but merely the presence of an attack. Examining how operations teams consume alerts to identify compromise and respond, the first step is discarding the false positives of alerts that were real yet irrelevant against the targets they were directed at. This represents most of all alerts that are generated, typically in excess of 99%. The process of winnowing the alerts that matter vs. the ones that don’t typically take hours because of the way operations are structured. In fact, I’ve started to call this further time spent spinning up and buying alerting tools “investments in frustration” because of their limitations.
When you understand that more alerts from more detection sources just compound the problem for the operators, it’s time to take a step back and ask a fundamental question: are we focusing on the right things? I say no.
In modern networks, threat-centric security has a major scaling problem, and the traditional solution of trying to apply automated contextualization to sets of raw alerts is done infrequently. Human operators frequently end up having to do it by hand.
There is another approach to detection, moving “right of boom” to a “compromise-centric” approach to detection. More than 20 years ago, when Snort was first gaining momentum, people used to ask me how they should tune their Snort sensors to be the most efficient and effective. My response was always the same: turn off every rule but those that detected things you could be vulnerable to and then write custom rules to detect things that should never happen. In most cases, they would politely nod and then go off and run the default configuration, rarely doing the former but especially never doing the latter.
However, there is hidden gold in that approach. Understanding your network sufficiently to be able to codify the things that should never happen, even if it was a narrow set of things, is incredibly powerful. It’s essentially “detection by exception,” anytime one of these detections fires an alert it immediately bears investigation because it is canonically indicative of an issue. There’s no need to wonder if it’s yet another false positive from a detection that’s catching all the automated scanning coming off the public internet, it is definitively indicative of post-compromise behavior.
Where are we now? While I was admittedly the first proponent of threat-centric security, even I have to accept its limitations and our industry’s dire need to move to “compromise-centric” security. Doing detections with a mindset of detecting the conditions of compromise results in many fewer events – because an actual compromise triggers them – which paradoxically allows a faster time to action by operators because of its rarity and specificity. This compromise-centric approach not only enables faster time to action, but it reduces the investment in frustrating, meaningless alerts, and it allows defenders to get a grasp on what their networks never should be doing in the first place — and reduces the dwell time of an attacker.
The positive implications for enterprises are further game-changing:
- Improved total cost of ownership (TCO) because you are no longer investing budget dollars into frustration and meaningless alerts, which allows you to better defend your overall network.
- Fewer alerts of much higher immediate use mean a reduced workload on operators. This, in turn, allows the core operational goal of identifying compromise to initiate incident response playbooks to happen in a timelier fashion, which reduces dwell time of an attacker massively.
- The methods that facilitate compromise-centric security don’t have to rely on obsolete network traffic inspection architectures. Analysis and detection can still happen in real-time, and yet massive, expensive hardware infrastructure isn’t required to enable it, and, as a result, it works equally well in cloud environments.
- This method of detection changes the abstraction that we use to describe threats to something that’s more broadly applicable to any network environment and works equally well for describing the activities of devices, users, and applications.
Again, we can start identifying what should never happen. The network is now a hybrid collection of cloud plus on-prem infrastructure, and encryption is widespread. Traditional on-prem network security tools that are appliance-based and rely on deep packet inspection (DPI) aren’t practical to use in the cloud or everywhere in your on-prem networks. Cloud networks are typically ignored altogether in favor of log analysis and agent-based approaches to understanding hostile activity in the cloud, yet there is a wealth of security insight that can be derived from analyzing cloud network activity.
Leveraging obsolete on-prem architecture and ignoring the cloud, it’s not uncommon for organizations to miss signs that trust boundaries are being circumvented, which could indicate suspicious lateral movement and potential data exfiltration, or to discover policy or governance issues like misconfigurations, random applications running, or even basic hygiene issues like Bitcoin mining that no one knows about.
In every network there is activity that should never occur, yet most organizations lack the ability to detect them (like the violations of trust boundaries, OT networks communicating with external systems or changing their communication habits, even simple things like dev talking to prod, etc.). They often lack the instrumentation to tell them in real-time when something is occurring that is either a serious policy violation or an attack.
While a lot has changed for security professionals over the years, some things have not. The reality is that most users, devices, and applications behave in a reasonably predictable way or are constrained by policy in very defined ways. When things start going off the rails, that’s when we have opportunities to pick up on potential exposure and risks. This, again, requires the evolution from threat-centric to compromise-centric security.
Fortunately, when we do compromise detection right, we get a system that delivers vastly fewer events while the events it produces are vastly more actionable, leading to greatly improved time to response and remediation. A future where network security remains useful is a future where it is scalable, and the best way to get there is to evolve towards a compromise-centric approach.