As Anton Chuvakin recently mentioned on his blog, we are starting some research on the work around security monitoring use cases: from the basic identification of candidates to prioritization, implementation, tuning and even retiring use cases. It is a crucial component of security monitoring practices but there are not many places you can get good information or best practices about it.
I have seen very different approaches on that topic by different people and organizations. It is very common to see, for example, organizations relying on out of box content from their SIEM, but most of those cases are related to “checkbox mentality” of managers – they just want to check the “we are using a SIEM” box. Others expand that a bit by enabling rules and content related to specific regulations, such as PCI DSS, to make the auditors happy. Of course, none of those are getting much value from their tools and monitoring teams.
There are also others that understand the need for customized content and go through the effort of creating their own use cases and related content, but end up building over engineered processes, killing the agility and dynamics required by today’s constantly evolving threats. Those organizations are usually very thorough with processes and procedures. However, when the use case implementation process includes the same level of change management formality (and bureaucracy) that IT operations, it’s time to simplify.
(I find hardly surprising that organizations that have fallen into that trap are now looking for things that “apparently” don’t require use case development work, such as UEBA tools. I say “apparently” because they soon find out that even if those tools don’t require something like developing SIEM rules, all work related to alert triage and investigation processes, log (or other input) requirements identification and tuning still exists. Wanna guess what happens next? More cumbersome process development for all that, killing the usefulness of yet another layer of tools. Well, maybe the next cool stuff will be easier….)
Of course there are also the opposite, the cowboys. Those chaotic environments where tools are implemented with no planning or oversight, in a very “just do it” approach. Those are the environments where the good stuff is usually created and maintained by a few heroes, just to die in abandon when they move to another job.
(and yes, these guys may also try to get the next gen of tools hoping that this time things won’t be as chaotic as the existing stuff…making all the same mistakes again and again)
And finally, there are those that do things right!! And interestingly enough, I’ve seen that happening with different approaches, but a few things can be found in all successful cases:
- Good people: You can’t create good use cases without people that knows how to do it. You may get some external help, but if you don’t have your own good resources things will get stale and quickly lose value after the consultants are out of the door.
- Simple, but clear processes: Chaos can provide some help by pumping up the creative juices, but it’s very hard to move from good ideas to real (and fully deployed) use cases without processes. Optimization is a constant need too, and without processes there is always the tendency of leaving things to a slow death while pursuing new cool shiny objects.
- Top down and lateral support: The security team may have good people and processes to put together the use cases, but they are not an island. They will need continuous support to bring in new log sources, context data and the knowledge about the business and the environment required for implementation and optimization. They will need other people’s (IT ops, business applications specialists) time and commitment, and that’s only possible with top down support and empowerment.
You may ask about technology; having the best tools around certainly helps, but it’s interesting to see how many organizations achieve great results by putting together a few open source tools and custom scripts while others fail miserably with the latest SIEM and UEBA technology in their hands. Security technologies are just like any other tool, they need someone who is prepared and knows how to use them.
So, we know some of the key success factors, but are there any others? For those starting now, what should they do? Is there an optimal way to establish processes, roles and responsibilities? What is the best way to identify candidate use cases? From those, which ones to implement? How to prioritize them? Lots of interesting questions! Stay tuned as we proceed to find those answers.
(and of course, if you have something interesting to say about that….let us know 😉 )