We are seeing companies establishing separate SIEMs for threat hunting. What are they expecting to achieve?
We see organizations, especially in verticals like financial services, healthcare, telecommunications, and government, investing here with the goal of reducing overall time to respond. They do so through programs to mature their threat hunting functions and enable in-house analytics initiatives. In either case, both rely on data as a foundation to baseline their environments. Threat hunters use that baseline to find anomalies and then classify them as operational issues or threat activity and react accordingly.
Analysis programs use a data foundation to build detection modules, often to increase coverage of MITRE ATT&CK TTP’s. In either case, these programs create a virtuous cycle: the right data enables broader analytics coverage and better analyst speed, which together drives down overall response time.
The common need for each is a set of data that provides depth and context beyond the alerts and IOCs that are generated by their detection technologies. That data is always much higher volume than the alerts themselves. This increase in scale drives cost, either direct license cost or operational cost, in many of today’s SIEMs. As a result, defenders are turning to a secondary SIEM platform or data lake for these higher volume applications.
Why are two SIEMs not a viable solution for all organizations?
Cost and complexity! Larger organizations have security engineering teams to connect the security data lake to their primary SIEM. That allows the best of both worlds: centralized alert aggregation, workflow, reporting and training built around the SIEM but with dedicated analytics or threat hunting “extensions” in the security data lake. That integration overhead can be a barrier to smaller organizations, who often don’t have a dedicated engineering team much less the ability to deploy and maintain a security data lake.
Is there a way of making one SIEM suffice?
Absolutely. While the job is the same (enable threat hunting and expand MITRE TTP coverage through analytics), smaller organizations can make progress by prioritizing. First, scope the project tightly: define particular applications that need better coverage or particular TTPs that are most active in your industry. Second, use what is both out-of-the-box or freely available – projects like SIGMA provide threat hunting and SIEM queries for a wide range of TTPs. Third, use industry standard data and tools so you get the best access to talent and training (at SANS or similar firms).
Smaller organizations also have an advantage here: they often have the same analysts driving both incident response and threat hunting. These create a virtuous cycle as threat hunting helps the analyst better understand their environment, which increases their confidence and execution in incident response as well. Larger organizations, due to their scale, often need to create specialized roles for the two.
Why is it important to separate threat hunting and incident response and what is the best way to do it?
Incident response and threat hunting are closely partnered activities; the only question is how to make that partnership work given the scale of the organization. At a team size of one or a few people, each analyst will do both functions (incident response and threat hunting). This is very effective as it helps develop skills and deepen environment insight – so long as there is protected time for threat hunting each week (otherwise the urgent will override the important!).
As the team grows, IR and TH often become dedicated roles within a team. With that growth, it is still important to rotate roles to both build skill and share insight into work in progress. In very large organizations, these can be specialized teams. This is wonderful for bandwidth and toolset optimization, but we need to work hard in those environments to keep communication high between the IR and TH functions.
How to enhance communication and feedback between threat hunting and incident response?
There are three primary communication streams that matter, and regardless of the team scale it is worth mapping out these communication patterns and any supporting technology. The first is that IR teams need to educate threat hunters about the current attack patterns. This helps the TH team stay focused on issues relevant to day-to-day incident response.
Second, the threat hunting team needs to share their insight on what anomalies they see in the environment, so that the IR team sees what is “normal” (vs not!) quickly. Last, the output of the threat hunts need to be encoded in a search or analytics model (a SIEM query, Spark notebook, etc) to serve the incident response team. Each of these streams help connect the learning cycle between the incident response and threat hunting functions.