For the better part of the last decade, I’ve been fascinated by the promise of security information and event management (SIEM) systems. I joined one of the most advanced SIEM vendors as a security engineer, and worked tirelessly to make this passion a reality. The ability to monitor all security activity from a central location was a complete game-changer in my mind, and adding a querying engine that would ask any question of the data was so compelling that I was sure security incidents on a large scale would soon be a thing of the past. Then, evidence to the contrary started to emerge….
First, it was the complexity of deploying SIEM systems. Then, it was the complexity of using them. Then came the false positives and the burden of maintaintenance. I shrugged off all of these complaints initially, and attributed them to poor technical skills of the user. With the right approach and a powerful querying engine, I thought, no use case is impossible.
I got my chance to prove it after joining one of the largest security operations in the world. I was responsible for the SIEM content in a organization with more than 300,000 employees operating on six continents, using dream-tier hardware and being part of a team of highly experienced and capable engineers. We monitored everything imaginable, from domain controllers to malware detection systems, from firewalls to proxies to email gateways.
What I learned very quickly is that when you’re dealing with this amount of systems and data, there will inevitably be exceptions, special circumstances, configuration changes and other events you cannot foresee, all of which will make security alerts trigger not for the intended reason. Even the most robust and straight forward rules were generating false positives at a rate that was too high for the security operations center (SOC) analysts to handle. Sometimes, it was a slightly different format of the log message; or it was due to a network or a system change. Sometimes, I just didn’t know that systems could behave in a certain way and that users were occasionally allowed to perform activities that triggered false positive alerts because it was their job.
What followed these discoveries was a continuous cycle of making updates and exceptions to account for the new circumstances I learned of, only to be faced with the next set. SOC analysts were chasing red herrings more times than not, and I did not have time to look into implementing new use cases because I was so busy tweaking the existing ones. To our embarrassment, we learned of many security incidents from third parties. The worst thing was probably the perception that the latest tweak to the rules will solve the false positives for good. I was like a mouse on a spinning wheel, certain that if I just run a little bit faster I will get to the cheese.
When I met the folks from Exabeam, I realized my mistake. I was applying the wrong tools to the problem. Applying a rule-based correlation engine to these massive amounts of data is like trying to perform open heart surgery with a saw. It won’t work. Instead, more appropriate techniques have to be applied to mine through this data, such as data modeling, clustering and machine-learning to create user behavior intelligence. These have already been successfully applied to problems ranging from fraud detection to highway design to self driving cars. Somehow, only the security industry was left behind.
After this conversation, I was ready to jump off my spinning wheel and join a tremendous effort to advance to how companies approach the security challenge. This is the beginning of the end of SIEM as we know it, and Exabeam is here to give a makeover to how we manage and analyze security information events.