A SOC that deals in Alerts is doomed. If it deals in 'high fidelity detection analytics' + can show ...
1) what's possible to detect that your tech teams + business MDs care about
2) by implication what gaps exist with existing tech (coverage / config)
... then in with a chance.
1) what's possible to detect that your tech teams + business MDs care about
2) by implication what gaps exist with existing tech (coverage / config)
... then in with a chance.
In practice what that means is defining 5 things that are highly interesting from a blue/red perspective, and where you would tolerate high false positives because if you see 'an activity' it's worth some precious analyst time to investigate ... for 2 reasons ...
1) To rule out that badness is happening
2) To understand if the analytic can be better tuned to remove the trigger to 'go look at this'
2) To understand if the analytic can be better tuned to remove the trigger to 'go look at this'
This is why I reject totally and utterly the concept of spending any time looking at critical alerts as defined by some random rules in some vendor tech. You can't justify your time and money to the people who fund you when you metricate that stuff.
But if you explain that you investigate 100% of 5 (or whatever) activities that would equate to revenue loss, and show how often those activities take analyst time, and how much analyst time they take... you have the start of a business case
Now, let's think about what that means for logs...
If you have a list of top 5 detections there will of course be caveats. You only know to detect what is known to you. For example where you have knowledge of what logs you need from past experience, or from IR. So your top 5 may be wrong in the grand scheme.
But you have to start somewhere. So starting with what you know is better that starting with what could happen maybe based on what vendors have told you, or stories told at conferences etc
Here's a good picture of what happens when you try and build a strategy that starts with what *could* happen.
An issue you may run into when forming a 'top #n' detections is that the logs you have push you closer to the wrong side of IR (i.e. you leave yourself a v short time to close the door before the horse bolts). This is ok. Because you can now explain that to your financiers...
... namely, the business units who are entrusting you with stopping badness. And hopefully adding value too while you do that.
If they would like to 'move to the left' in the timeline of detection (catch things earlier) then there is a cost to do that.
However rather than asking for that cost as an up front investment of money (and trust that you'll deliver value from what you spend) it's better to start with defining the best detections you can deliver with what you have.
It then becomes very obvious whether your 'top 5 deliverable detections' are in fact way down the list of priorities (e.g. numbers 15-20 not 1-5). However if it's the best you can do, that is reality.
Changing reality means changing the logs or changing the way you work with them.
And in turn once you've defined your detections and thoroughly investigated the best you can do with existing tech + config, you are in a much better position to know how best to change reality.
And in turn once you've defined your detections and thoroughly investigated the best you can do with existing tech + config, you are in a much better position to know how best to change reality.
Tl:Dr ...
1) define top 5 things you would need to take action on if detected
2) define top 5 things you *can* take action on with detections you can build
3) define delta between the two + reasons for it
4) articulate how 'investigative' the actions you can take are
1) define top 5 things you would need to take action on if detected
2) define top 5 things you *can* take action on with detections you can build
3) define delta between the two + reasons for it
4) articulate how 'investigative' the actions you can take are
Once you can show how much further digging in 4) is necessary, you know how noisy your detection is and what kind of lag time there is when you take action (e.g. investigate / block / etc)
