In the first of a two-part blog post on Managed Detection and Response, Fran Donoso, senior director of global security strategy, discusses four major issues that will be familiar to any security leader who has wrestled with making threat detection and response more efficient.
I hate to be the bearer of bad news, but your current detection strategies aren’t working. 91% of attacks aren’t even generating alerts and just over half of breaches are actually discovered by the security team. I wish I could say there was some larger issue at play here, but this is largely a problem we’ve brought upon ourselves. We set up our SIEMs, we categorize all of our alerts, and we put a response plan in place (hopefully). And yet, the problem persists. We’re doing all the right things, or at least we think we are. We and our technology are getting in our own way, creating roadblocks where we should be creating fast lanes that accelerate time to detection and response. Meanwhile, attackers are sitting inside our environments, sometimes for months or more, and we don’t even know it until the aftershocks are felt.
These roadblocks occur because for years our approach to threat detection has lulled us into a false sense of security where we think more data (which just leads to more alerts) is going to help us stop a breach. What if I told you that we as security professionals can be more effective with fewer alerts from fewer data sources. Sound crazy? I’m not the only one thinking this way. Here’s what Gartner has to say on the topic:
“Many customers fail with their threat monitoring, detection and response initiatives, because of the focus on monitoring a variety of log sources from whatever technologies they have deployed, instead of having the right sources generating telemetry and alerts, at the right time, in the right format, in the right locations.”
So, we know we’ve got issues, and we know we want to change. What should change look like? That’s what we’ll get into in this post. First, let’s dig a little deeper into what’s holding us back today.
The Four Roadblocks to Faster Threat Detection
Most organizations get SIEM wrong.
Let’s start with the low-hanging fruit, here. We’re bad at SIEM.
Too dramatic? Here’s what I mean. SIEM was initially positioned as the solution to all of our security monitoring problems. It would pull all your security telemetry into one place, allowing us to centralize triage and initiate response activities. Great! But it turns out not all that data coming into your SIEM are relevant plus there’s so many of them it all becomes noise, a queue for some poor SOC analyst to sift through.
To be fair, this really isn’t your SIEM’s fault. It’s only going to ever be as good as the data it’s collecting, and we’re feeding it some pretty bad data. If you have not set up your SIEM to collect the right (non-default) Microsoft Windows Event data or antivirus logs, then your SIEM is never going to tell you about the attack that’s using Cobalt Strike to move laterally throughout your network. This brings us to our next roadblock.
Default configurations kind of suck.
There. I said it. Default configurations are default. That means they’re designed with the lowest common denominator in mind. They don’t know your environment or the threats to it. They’re just there. And if you’re relying on default configurations for security alerting, you’re going to be missing critical pieces of information that could help you stop an attack earlier.
Take, for example, the default Windows logging configurations. If you plugged it in and turned it on, you’d be missing out on all these events.
No alerts for changes to policies or files or privileges or the security state. No logs related to Remote Prodcedure Call (RPC) events or removable storage or system integrity. It’s so limited that we created a CFC client guide that tells our customers what the defaults should be.
We let devices dictate our detection strategy.
You get a new IDS tool. You look at all the types of alerts you can get from it, you categorize them, and you figure out a response plan. Which leaves you with thousands of alerts from that one tool. Plus a thousand from your firewall, another thousand from your cloud service provider and so on. It’s a lot to sift through, and it may not even tell you all that much. An alert in your IDS may seem like no big deal in isolation. You need a common lens through which you can evaluate alerts coming in across all your relevant devices. At Kudelski Security, we call these lenses “use cases.” More on that in part two.
Everything’s a priority.
When everything’s a priority, nothing is a priority. And nowhere is that more true than threat detection and response. If you are set up to collect every log for every potential indicator of every potential threat, your team will quickly be overwhelmed with data, making it harder to identify and respond to the threats that actually do matter to you. You need to be able to see the forest through the trees.
Figuring out what those threats are requires a threat modeling exercise. Threat modeling may have once been considered a “nice to have” in the enterprise security space, but I’d argue, for the reasons above, that without it, you will end up running on a treadmill of alerts that never really gets you anywhere. The goal is continuous improvement. Start with the most important thing you can reasonably do today and then move on to the next. But you have to know where to start, and threat modeling can help you with that.
But it’s not all bad news. Look out for the second part of this series, which will look at practical advice on how to get round the roadblocks.
Learn about Kudelski Security’s Managed Detection and Response capabilities here.
.jpg)
- MITRE ATT&CK & D3FEND: Step-by-Step Guide to Closing Security Visibility Gaps - September 5, 2022
- “INCONTROLLER” / “PIPEDREAM” ICS Toolkit Targeting Energy Sector - April 25, 2022
- 8 Tips for Choosing an MSSP - February 16, 2022