Turning Hunts Into Detections with PEAK

If you’ve been following our series on the PEAK threat hunting framework, you might already know that the purpose of threat hunting isn’t just to find security incidents your automated detection systems missed. Finding incidents is more like a helpful side effect. The real reason to hunt is to drive improvement to your security posture over time. 

Improvement can take many different forms, and we’ll talk about some of these in future PEAK posts, but probably the most obvious is that threat hunting helps you find new ways to detect malicious activity. Finding these new ways, though, isn’t that useful unless you take the next logical step: turn your hunts into production detections so you don’t have to spend the time and energy hunting them over and over again!

Push that work off onto your automated detection systems so you can spend your limited time more productively than re-hunting the same things over and over. Creating detections can be as easy as “write a new SIEM rule,” and you’re done, but what if your new method isn’t quite that straightforward?

In this post, we’re going to look at something the PEAK framework refers to as the Hierarchy of Detection Outputs. The hierarchy is a model for understanding the different types of detections you can create from your hunts and when each type might be most appropriate. Of course, you don’t have to follow it strictly; like the Pirate Code, it’s more of a guideline, really. But it’s a useful guideline, so let’s take a look at it.

(This article is part of our PEAK Threat Hunting Framework series. Explore the framework to unlock happy hunting!)

The Hierarchy of Detection Outputs

The hierarchy consists of four broad categories of detection, ordered by how much automation they offer. Or, to put it another way, ordered by how much human attention they require in order to find the bad things.

^{The PEAK Hierarchy of Detection Outputs}

The hierarchy consists of the following levels, starting from the bottom:

Reports

Sometimes you know what you want to find, but searching for it is likely also to return a large number of irrelevant results, such as authorized benign use or other false positives. Finding relatively rare examples of true malicious intent may require analyst experience and insight. In this case, an automated report might be the best option for detection. Run it on an appropriate schedule (daily, weekly, monthly, etc) and put it into the analysts’ ticket queue or use some other mechanism to ensure that someone actually reviews it.

Reports are the lowest level of the hierarchy and thus the least desirable because they require the most human attention. They’re not ideal, but sometimes they are the best you can do. Hunts that result in report detections might make good candidates for additional detection engineering or even re-hunting in the future; once you have more experience with the reports, you might find better ways of focusing on the relevant results and climbing the hierarchy.

Dashboards & Visualizations

Moving up from reports are dashboards and visualizations, which present summarized information instead of just raw details. Unlike a report, which lists individual events, dashboards are easier for humans to consume and make sense of. They may show the systems deviating the most from their established Producer-Consumer Ratio baselines or a heatmap of failed logins across DMZ servers.

Although dashboards and visualizations still require regular human attention and probably have a fair amount of benign entries, they are designed to make it easy for analysts to pick out the important things quickly. Like reports, dashboard detections could be refined in the future to move up the hierarchy.

Analytics in Code

When you know how to find the exact activity you’re looking for, but it requires a little outside computation to make it work, you’re dealing with what we call Analytics in Code.  That is, you have created a script or program to analyze the data and find the targeted activity. This is especially common with model-assisted hunts but can occur with any hunt. Ideally, the output of this code will be highly accurate and suitable for inserting into your SIEM as an alert.

Although this level in the hierarchy is perfectly respectable from the standpoint of automation and alerting, you may need to devise a mechanism to ensure that the code reliably runs on a regular basis.

Signatures & Rules

At the top of the hierarchy, you’ll find IDS signatures and SIEM rules. These require no human input to generate alerts and are easier to manage than analytics written in code. As a result, they are the preferred choice for automated detection when feasible. 

Applying the Hierarchy

Applying the hierarchy to your hunts is usually pretty straightforward: at the end of each hunt, ask yourself:

• Have I figured out how to find this activity? Don’t worry at all if you didn’t find any malicious activity. This is common! You can have a successful hunt even if you didn’t find what you were looking for, as long as you are satisfied that you would have found it, had it been present.
• When I have a result, would I be confident enough to put it in front of a SOC analyst as an alert? If yes, then you’ll probably want to use either Analytics in Code or Signatures & Rules. Otherwise, Reports or Dashboards & Visualizations are likely the best choices. In either case, choose the highest level that you can feasibly implement. Dashboards are better than reports, and rules are better than code.

Don’t stress too much about the choice.  Do what seems best; you can always revisit your selection if it doesn’t work out. In fact, you probably should revisit the reports and dashboards every so often just to see if you can figure out how to move those detections to a higher level.

Also, keep in mind that you may discover more than one potential detection mechanism for any given hunt. Therefore, you may create detections at different levels in the hierarchy.

Conclusion

If the purpose of threat hunting is to improve your security posture (and it is!) then one of the most impactful ways to do this is to create new detections as a result of your hunts. It’s important to recognize that there are different types of detections, requiring various amounts of human effort to process and offering various levels of automation. PEAK's Hierarchy of Detection Outputs simplifies the process of optimizing detection coverage while minimizing analyst attention costs.

As always, security at Splunk is a family business. Credit to authors and collaborators: David Bianco, Ryan Fetterman.