“Hello, I am your anti-virus program. Which specific viruses would you like me to kill today? Enter names here: [……..]” While I don’t recall the exact state of the art of anti-virus back in the late 1980s, I do not remember any anti-virus program ever asking such a question. The technology originated in response to a definite threat – malware [collectively called “viruses” at the time]. At no point in this technology evolution, was the user supposed to steer it towards particular targets. It just “did it.”
OK, Anton, and your point is?
SIEM use cases, naturally (example use case, list of common SIEM starter use cases). I’ve met a few folks who loudly wondered “why SIEM can’t just DO IT.” Here is how they think: anti-virus just does it, firewalls just do it (well, after you write the rules), even NIPS just does it [well, in their minds it does…]
Why oh why can’t SIEM just do it? When the enlightened SIEM vendor offers them a tool and adds “now you need to tell us what use cases you’d like to focus on first”, they complain that the vendor is shifting the burden to then; why can’t their SIEM tool “just do it”?
OK, the enlightened readers of this blog will start to snicker – or even ROFL – just about now. However, let’s scrutinize this delusion.
Back in my SIEM vendor days, we had a situation when a field engineer was asking a customer “what use cases do you want to start with?” with the customer countering with “so, what use cases should I start with?” and this ping-pong going on for a while with both parties getting increasing frustrated (all the way to “so…wait a second here…you just paid us $740K for a SIEM and you don’t know what you want with it?! WTH!” — “Whaat?! You just sold us a $740K pile of stuff that does not even DO anything” and so on). In the end, they simply said “we want to do with our SIEM what most other people want to do with theirs” — and left it at that…
Intuitively, people feel that SIEM technology as well as some other technologies are inherently different from others, but they are unable to spell out how (i.e. SIEM is not like anti-virus). For once, monitoring technologies require an open-ended commitment from the organization wanting to utilize them. Also, successful monitoring nowadays MUST be mission-specific; you are unlikely to succeed if you want to generate a critical alert if “something bad” happens. You have BAD, next-morning BAD, end-of-the-week BAD and of course that scary “wake me up at 3AM BAD” — with the exact priorities depending on YOUR BUSINESS. Not the vendor default correlation rules, now some “security intelligence”, not what Gartner thinks – your business [BTW, DLP is even more so this way]. Contrast this with “I don’t like viruses – please kill them all” seen through the anti-virus lens….
To summarize, a lot of security gear is bought to “plug a hole” (be it an audit finding or a new threat such as malware). However, SIEM is most explicitly NOT of this kind. As I’ve written many times, SIEM is a “force multiplier”, but this definition implies that you have something to multiply. If you have 0 capabilities, a purchase of a SIEM tool will still leave you at – you guessed it!—0. SIEM will make YOUR security monitoring problem-solving better/faster, but it won’t “plug any hole” for you.
And if you somehow cannot transcend “see a hole-buy a box” thinking about security, some expensive education is available…
Related blog posts:
Select recent SIEM blog posts:
- More on SIEM Maturity – And Request for Feedback!
- My Evaluation Criteria for Security Information and Event Management Publishes
- On SIEM Tool and Operation Metrics
- SIEM Analytics Histories and Lessons
- How to Use Threat Intelligence with Your SIEM?
- Popular SIEM Starter Use Cases
- Detailed SIEM Use Case Example
- On “Output-driven” SIEM
- On SIEM Deployment Evolution
- On People Running SIEM
- On SIEM Processes/Practices
- On Large-scale SIEM Architecture
- All posts tagged SIEM