Hi, I'm Rafal. I've spent my entire career in and around SOCs - starting as a Junior Analyst and working my way up to Director. This blog is where I share what I've learned and what has worked for me so far.
Today I write about my take on what optimal security monitoring strategy looks like. By optimal I specifically mean being cost effective AND giving solid visibility of the environment. I found this approach to be both better and cheaper than the alternatives. I’ll explain it here at a high level and will break it down in future posts.
First let’s talk about what a bad security monitoring looks like, then we’ll discuss the good approach.
The suboptimal security monitoring
If you're learning about SOC work from LinkedIn or similar places, you might think it’s not going well for the defenders. You might’ve seen content about analyst burnout, 1000s of alerts every day, SOC metrics being largely unhealthy, alerts being missed due to overwork and so on.
That’s mostly just marketing. You know, the usual “things are bad → you can’t possibly fix it yourself → I can → buy my product”.
In reality, SOCs aren't doing that poorly. Even if your security monitoring isn't set up perfectly, it's still manageable and nothing will explode if your team is mostly competent.
That said, two problems genuinely do show up everywhere: security monitoring that costs too much, and security monitoring that generates too many alerts. Both are avoidable and almost always trace back to the same root cause - poor security monitoring strategy.
And how do SOCs get there?
By thinking tactically about a strategic problem.
Let me explain:
How a SOC engineer thinks about security monitoring
To set up security monitoring you first need to collect data, apply detection logic to it and then investigate when an alert is generated. Those are the technical steps that need to be taken in a specific order to monitor for threats. This is not how we should be thinking about our security monitoring strategy.
Because if we do, this is what happens:
We first think about what data to collect.
The problem is that it makes sense to collect everything that’s even remotely security relevant. Does it make sense to collect firewall logs? Sure. Endpoint logs? Yes, please. Cloud logs? Of course. Once we’re done, we end up collecting more than we need. This later becomes a cost problem.
We then figure out what to detect.
We already have all this data, it makes sense to use it for detections. Then we have our basic detection needs to cover common attack scenarios. Then we have the new stuff that we seem to read about every other week. We eventually end up writing too many detections that we don’t really need. This later becomes an alert volume problem.
We’re ready to investigate
But it turns out we have too many alerts to reliably go through. Our problems surface here. If we’re skilled, then we finetune. If we’re not, then we seek professional help, maybe look to buy a product. By this time we’re already not cost effective. Throwing more money at the problem might help, might not. At this point our security monitoring is already suboptimal.
The optimal security monitoring
So what can we do?
We’ve established that setting up security monitoring by thinking along the collect → detect → investigate steps doesn’t yield optimal results. This is one of the cases where we need to put our technical thinking aside and take a step back.
SOCs primary objectives are to detect and respond. But detect what? And respond to what exactly? It makes sense to detect everything even remotely security relevant, but this is simply not doable. We’re limited by budgets, work capacity, skills, tooling, you name it. And trying to do more than we realistically can is what sets our security monitoring programs up for failure.
How about if instead of trying to detect everything, which we can’t do, we focused on our ability to detect the most likely attack scenarios?
If we were able to do that, we could focus our efforts on a narrow set of detections, that require less data. We would not only be more cost efficient, but also more effective in detecting realistic attack scenarios. In other words, our SOCs would be cheaper and better.
Here’s what to do.
First we gather intelligence
We want to understand the most likely attack scenarios for our organization. I like to do it by looking at capabilities of threat actors known to target organizations similar to ours. We list those threat actors. We then look into how they carry out their attacks. The attack techniques that are used the most across all those threat actors, are the ones we need to prioritize. Those are our most likely attack scenarios.
Techniques in RED are our most likely attack scenarios
Then we plan detections
Knowing how we’re likely to be attacked, we are ready to plan our detections. This will form the core of our detection capabilities.
We then collect data to support our detections
With detection logic already planned, it is easy to understand what data is required to run those detections and investigate alerts that they’ll generate. That way we can run a very cost effective security monitoring program.
We’re ready to investigate
At this point we are ready to start investigating. We are likely to have spare investigation cycles.
How a SOC leader thinkgs about security monitoring
In my experience this approach is both cheaper than the alternatives and yields better results as far as threat detection is concerned. It allows SOC teams to start meaningful monitoring while leaving space in their budgets for onboarding more data sources down the road. It is far easier to start small and build up than to start large and try to trim the fat while under pressure to fit within budget and meet monitoring targets.
In other words, I believe this security monitoring strategy to be optimal.
If this way of thinking about security monitoring resonates with you, I'll be going deeper on each step in future posts: how to actually build your threat actor list, how to map techniques to detection logic, and more. The best way to follow along is to subscribe to the SecOpsPOV newsletter below. No spam, no vendor pitches - just more of this.