The Future State of SIEMs - Part 1 (The "what")

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 ...

Content Conundrums for the SOC: Part I

Organizations are constantly in need to keep their threat detection content up to date but with an ever changing threat landscape, organizations struggle to properly develop viable content that is relevant to their security needs leaving unnecessary time spent on irrelevant content, increased remediation times, and large security detection gaps. In order to effectively do this, organizations need to do two things: an introspective look into their current cyber security state, and have a methodology for developing detection content.

Introspection requires an organization to understand the relevant threats and threat groups associated with their industry, understand their current infrastructure, and understand what their attack surface looks like. By taking a deep look, organizations can better identify what kind of emerging and existing threats are applicable to themselves, and pinpoint their efforts to developing detection content dedicated towards those threats. Ideally, the output of this exercise is a full breakdown of everything from security infrastructure design to relevant threat groups with associated MITRE ATT&CK mappings. As you are probably thinking, this introspection is the foundation to start the next step in almost any area of cyber security but we will focus on content development surrounding threat detection.

Now that organizational needs are all mapped out, the process of developing detection content is more targeted since there is no question as to whether a new or emerging threat is relevant. This may seem like a simple task but the reality is that every time a new critical threat emerges, most organizations scramble to determine if and how they are affected. Wouldn’t it be nice to just know whether you need to start developing detection content or not? And if you can immediately determine that you are not affected, wouldn’t it be great to not waste resources on the irrelevant and continue to focus on that backlog of the relevant? With that being said, how should an organization develop detection content for the threats that are relevant?

In order to do this, organizations are going to need some organizational unit to perform functions similar to the B.A.D. (Build, Attack, Defend) pyramid. For those unfamiliar with the concept, the B.A.D. pyramid essentially covers the critical components needed to properly defend an organization and, in order, they can create an iterative process for developing detection content. To be clear, these do not need to actually be different teams but are personas in the detection content development process. To give an idea of how this process would flow, after an organization identifies a new threat, they would employ their Attack component, or Red Team, to simulate the threat within an environment. From here the Defend component, or Blue Team, would either fully, partially, or not detect the threat. This information gets passed onto the Build component, or Yellow Team, to create or modify the necessary detection content for this particular threat who will then kick off the whole process once again for validation. It is an iterative loop until the detection content is ready to be published which requires full transparency so that no detection logic associated with the threat is overlooked. This is required even if a detection is already made, there may be opportunity to improve detection logic by either including other threat indicators or even just tightening detection logic to improve processing and filtering out false positives.

With this information an organization can begin to take the first steps towards effectively creating net new threat detection content, but there are still ways to improve this process in order to make it more repeatable and streamlined. Stay tuned for Content Conundrums for the SOC: Part II. Let us know how we can help you or visit us at www.anvilogic.com.