Is alert-driven security workflow “dead”?! It is most certainly not.
However, it is being challenged at some enlightened organizations that deploy SIEM, network forensics or other analytics technologies (notice how elegantly I am avoiding the marketer-corrupted term “big data” ).
A fellow SIEM literati once called it using “tech support workflow” for security incident response – and, let me tell you, he didn’t like it much. Many users of network forensics tools (NFT) have discovered that their tools are not alert-centric at all (such as discussed here), but require active data exploration. One NFT team manager even went as far as to say “we don’t hire alert responders here.” He meant to say that in his team he doesn’t want people to wait for alerts, but to go and explore, “hunt” for insights rather than “gather” alerts. Starting from a hypothesis, a “thread to pull”, a question rather than an alert is characteristic of this newer way of approaching security.
Here is how I am thinking about:
|Incident DETECTION||Incident DISCOVERY|
|Alert comes in –> you respond||You go out –> you find actionable info -> you act|
|Like tech support||Like QA (thanks for this idea!)|
|Context to decide on the alert||Context to explore wider/deeper|
|Triage THIS entity||Explore in THIS direction|
|Want to be “done” with the alert||Want to know what is really going on, not be “done”|
|Operations – alert volume||Research – insight usefulness|
In any case, hopefully it is insightful and useful for your security analytics / SIEM / SOC thinking and planning.
And, hey, vendors – don’t assume that security monitoring is ALL about alert-driven workflows… The smartest of your tool users already don’t.
Posted related to my network forensics research: