3f. Hunt for known threats

Fig. 41 Hunt known threats

The Detections Capability Development Lifecycle is a cyclical process during which the bulk of time and efforts are focused within a detection engineering operation. One thing that will provide perspective and insight into this process is to regularly hunt for known threats in the raw or alert data.

That might seem confusing considering if it is known then it would likely already have an existing alert. The difference here is to focus beyond the scope of existing rule coverage. This could be to detect changes in tradecraft as threat actors are continuously adapting. It could be a brand new threat that may have been captured in the data but unknown at the time of exploitation.

One of the powerful things about threat hunting is that it allows you to walk back on findings, no matter how small or insignificant, which often leads to a bigger discovery. This is a common way that zero days are often found. Even with the most advanced tradecraft, you only have to trip over one detection, and in this era of layered defense, it is tough to completely evade everything.

We started hunting on unknown threats earlier in the DPBL, but mentioned that it would become truly relevant after subsequent steps. Now that the initial research process has been completed, the information accumulated should be leveraged to hunt for known threats. From this point on, hunting for known and unknown threats should be a recurring process as a means and an end to supporting the development cycle, but also to ensure an environment is safe.

Hunting for known threats is also a cyclical process that should be used to validate observations and assumptions made during the research phase. Any new value should be incorporated back into the outcomes of the research.

To start hunting, you can pivot from existing alerts, or start by searching for known maliciousness that doesn’t presently have alert coverage. Following the process hierarchy of existing alerts is a good pivot and often reveals more bits of information about the attack. Of course this would likely be found during the triage stages when analyzing an alert, however, for product companies, this step doesn’t occur in the same way.

Additionally, when going back and looking at the data from a more holistic perspective, things tend to stand out and reveal themselves differently. It adds the advantage of a pure data and statistical purview, where context is less required.

Fig. 42 Pivoting on an alert to the process tree in Elastic Security

Fig. 43 Pivoting on an alert prevalence to hunt known threats

At this point, all of the major considerations from the Unified Detection Engineering Framework have been reviewed and stepped through. As stated, this is not a single-pass, linear approach, but rather an ecosystem of processes and workflows meant to operationalize the practice of detection engineering. It is a continuous cyclical approach, with many feedback loops along the way, constantly improving itself as a process as well as the outcomes.

This may also serve as a starting point for operationalizing detection engineering, where adjustments and variations will depend on specific circumstances. Perhaps where you or the environment sit along the dual perspective spectrum.

Also, as technology continues to evolve, and security vendors continue to push the bounds of innovation and create new products, the detection engineering discipline must keep pace. There also seems to be continued growth in the managed security space, with the expectations of that relationship evolving as well.

In the next two sections, this publication will shift focus to the practical application of some of these processes discussed so far. It will then discuss more advanced and novel subjects, for the sake of continuing to push the discipline forward.