SIEMs haven’t changed much in 10+ years. They primarily remain as good data collection technologies and data repositories, and depending on the vendor, decent alert engines to direct SOC analysts to noteworthy events. However, the most fundamental, and arguably highest value component, is the content — the detection logic that leads to noteworthy, actionable alerts — this continues to be the bane of every SIEM’s existence.
No matter which enterprise SOC it is, the most common pain points can be generally categorized into two themes — 1) too much noise from false positives and uninteresting ‘incidents’, and 2) inability to detect a higher percentage of threats mapping to priorities and exposures.
Good technology is only a part of the solution, the other part is domain expertise — high-efficacy, relevant and precise detections coming from sophisticated logic that leverages all key data sources necessary. SIEMs were built on the first part and continue to invest in that whereas the second, and more important part, comes from experts in the field, mostly those in enterprise SOCs. Its hard for them as they need to understand how the underlying technology works, and work around deficiencies in those technologies as well as the availability of data sources. There are at least two ways of looking at this problem: a top-down approach and a bottom-up approach.
The top-down approach starts with laying out corporate cyber-security priorities, for e.g., vis-a-vis the MITRE ATT&CK framework, and setting up ranked priorities upon which the “SIEM” can operate by producing alerts mapping to those priorities. This, of course, needs the right data sources, and the right detection content to produce the necessary alerts that can be ‘actioned’ downstream.
The bottom-up approach starts with building detection logic simply leveraging the available, and often most mundane, data sources while not exceeding the license restrictions of the underlying SIEM. This typically starts as a stop-gap approach but too often ends up being the ultimate implementation of security operations for many shops, unfortunately.
The right way to solve this problem is to break down existing legacy SIEM architectures and separate out the content part to make it an independent service that will provide the necessary, ready-to-deploy logic to the underlying run-time engine (which does not have to be a traditional SIEM) and produce few appropriate alerts to the SOC team for further action.
We will be discussing how to go about transitioning to the new and future state of security operations in the coming parts of this blog post. We will discuss how to leverage existing SIEMs but not be confined to only those as data repositories and rather have a more distributed and cloud-based SIEM architecture that leverages an independent content streaming service that feeds the run-time engine to produce only the necessary, and most important/relevant/actionable, alerts to the SOC team for maximum efficacy and efficiency. Stay tuned for more on this subject …
