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:
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
(Full-disclosure: I work for Spectorsoft, a creator of User Activity Monitoring software)
With the right systems and data in place, these two concepts can and should merge. The alerts should point to exactly where and when the exploration should take place. The caveat to make this a reality is the need to both monitor (for the Alerting) and record (for the Exploration) the same given set of data.
For example, in the case of our UAM solutions, we’re doing both around user activity (think: every action performed on a computer). We can alert based on keyword (found in email, typed, webpages, etc) to identify a specific activity in question, which allows the exploration of the recorded data to review what actions were taken before, during and after the activity in question to provide contextual and detailed analysis.
So a real-world use case would be taking the 3K keywords E&Y and the FBI developed to identify possible fraud and not only alert that a given keyword was triggered, but also have the ability to explore that specific point in time and replay an employee’s actions to see what was done.
Thanks for the comment. Indeed, it is useful to practice both approaches. Almost no security approach is black/white only, after all.
Very well said. Key from my point of view is blending alert-driven and exploration-driven monitoring and continually pivoting back and forth between the two. Furthermore by inserting and fusing machine readable threat intelligence and context into the mix, both the alert-driven and exploration-driven monitoring approaches become more effective and less dependent on having security geniuses on staff!
Matt, thanks for the comment. Indeed, combining them makes sense, but to combine them you need to know they BOTH exist. And people many don’t 🙂