Last updated at Mon, 28 Oct 2019 18:39:48 GMT
If you've ever been irritated with endpoint detection being a black box and SIEM detection putting the entire onus on you, don't think you had unreasonable expectations; we have all wondered why solutions were only built at such extremes. As software has evolved and our base expectations with it, a lot more people have started to wonder why it requires so many hours of training just to make solutions do what they are designed to do. Defining a SIEM rule is the perfect example – crafting the right query and adding it to detection lore can take up to an hour, which is fine if you have nothing else to do all day.
Writing a SIEM rule in legacy systems harms security teams by demanding expertise
The training London black cab drivers endure has been examined a great deal in recent years and for good reason: memorizing the ridiculous layout of London streets for a year before working eliminates “how do we get there?” annoyances and expands a region of the cabby's brain. However, requiring this level of expertise has been a massive barrier to entry for new drivers, and with the advent of GPS devices [“sat nav” to the angry London taxi drivers], somewhat unnecessary. In the taxi world, this has led to Uber providing rides to consumers at a third of the price.
Similarly, when ArcSight [who defines “simple” different than I] and QRadar were first deployed as the “single pane of glass” for the well-staffed organizations who could make them effective, it took more than six months to develop the skills and expertise necessary to translate the foreign language of many logs into meaningful rules for detection. Now that cloud solutions and continuous deployment made collective learning possible, it feels impractical for Splunk or AlienVault experts to first translate the logs into a language your SIEM can understand, and then use this event format to define each and every one of the alerts that'll trigger. In this case, the negative impact isn't the cost of your services, but rather a decrease in how quickly your security team can adapt to new attacker techniques.
Understanding a SIEM rule and the corresponding alert makes every non-expert look for the translator
Whenever a customer walks me through the process of triaging and analyzing an alert, it reminds me of the effort to debug the satellite communication terminals I developed at Raytheon in 1999. We were running FORTRAN on x386 chips and breakpoints weren't a possibility, so the raw assembly code we traced through resembled the chirps and beeps of R2D2 until you spent a lot of time with it. It wasn't until you'd acquired this level of expertise that you'd understand how to backtrack from a bizarre message on a tiny screen through five to ten different CALL and GO TO statements until the mistake in the code presented itself.
Just as I was forced to translate an output to the raw machine data to the actual code written by someone else, today's SIEM analysts have to translate the alert's accompanying data to the actual behavior identified and then, the reason why it warranted a rule back when someone else wrote it. It certainly doesn't feel like you've got the information you need to take action; some digging is required before you gain the necessary insight. C-3PO would be really helpful here to immediately explain every alert in plain English.
If your team is going to get more time to do the important work, you need custom alerts for humans, not machines
InsightIDR comes with dozens of useful alerts to anomalous and attacker-like behavior across log and endpoint events, but this extreme is just not enough. Switching from the rules-only of SIEM to the anomalies-only approach of other User Behavior Analytics (UBA) solutions is too dramatic a shift and that's why you need a solution with both. This is why Rapid7 customers can write custom alerts for the events which are a concern for their organizations. If they want to feed this intelligence to our teams, we're thrilled, and we may add it to the alerts every new customer gets after testing its noise level.
But right now, assign a junior analyst to make sure you have the alerts you need. We've made it dramatically easier to capture the alert in the first place. Deciding to alert whenever someone authenticates from North Korea or it looks like someone is streaming The Night Of from HBO Go will feel like you've been handed a sat nav on the day you interview to drive in London. My first experience in debugging Java was a dream after the process I had learned with FORTRAN. Even I can write these custom alerts and even I can understand what it means when someone else's alert triggers.
If you want to learn more about the way InsightIDR does what I described here, please check out our on-demand demo. We think you will appreciate our approach.
