Finding the “Goldilocks” Zone: A Practical Approach to Alert Triage

This article was originally published in the InfoSec Survival Guide: Orange Book — Incident Response. Read it free online HERE, or grab it on the Spearphish General Store (free digital download or a $1.25 physical copy, your call).

Security engineers, analysts, and incident responders all have one thing in common, and I’m not talking about 3 AM phone calls concerning incidents. I’m talking about triage: that challenging moment of urgency when assessments must be made and classifications communicated—for the right things to be decided on to prevent the bad stuff from happening.

We’re all petrified about missing a critical event or misclassifying an alert, but when we’re talking about incident response (IR), there are often hundreds if not thousands of alerts to parse through. It’s easy to get caught up with one alert because it feels “too hot” or maybe not spend enough time looking into something that initially seems “too cold.” I’ll provide some tips, tricks, and techniques to help find that “Goldilocks Zone” of spending just the right amount of time on an alert, allowing you to quickly triage and move on to the next.

Consider the Severities

The simplest way to triage events is to consider the severity of the alert. Initially, most Low-severity alerts should be entirely ignored. On any given case, time is limited, and the value return of going over hundreds of Low alerts is not even remotely comparable to that of reviewing higher priority findings.

Mediums will often be the bulk of your alert volume, with these being right in that uncomfortable middle of the “Probably nothing” of Lows and the “Definitely something” of Highs or Criticals. To move quickly on an IR engagement, I categorically relegate the Medium alerts to a later time on that case; and almost every time, the High and Critical alerts tell the real story, giving concrete direction on how to search the Mediums and Lows in a more targeted fashion.

Anomalies Against the Baseline

One of the most surefire ways to quickly classify an event as a true or false positive is to compare the activity against the normal baseline: “Does this happen regularly on this host,” “in this environment,” or maybe even “in any of the environments I can observe?”

While a certain execution or activity on one host may appear anomalous, once you discover that it happens on a number of hosts across multiple environments, either you’ve just found your answer, or you’ve discovered a much bigger issue…

Actions on Objective

One of my favorite tactics is considering “actions on objective.” If an attacker gains access to a host, they have an end goal in mind. Whether that goal is financially motivated, a desire to steal data, or even if they just want to observe activity in the environment—they broke in for a purpose. Someone isn’t going to go through the effort of breaking into your house just to stand around.

For the attacker to achieve their goals, some form of activity must occur to get them there. That often looks like exfiltration or lateral movement. All that to say, if the activity you’re looking at never actually goes anywhere, steals anything, or tries to override anything else, chances are it may not actually be evil, because it certainly isn’t doing the attacker much good.

Detection Intent

Probably the most novel (and somewhat controversial) approach I’ve come across is considering detection intent first and foremost. This approach requires you to understand exactly what it is that the rule that fired is looking for, and to look for that one specific thing only, ignoring anything else you may see in the periphery.

That idea may sound counterintuitive but think about it: Threat detections are often straightforward and scoped to a specific TTP, and the biggest time-waster in investigations is when we follow rabbit holes of related activity. So, if instead we observe that the primary activity the alert fired on isn’t malicious or relevant, that alert is now classified as non-malicious, and we move on. While debatable in its effectiveness, you can’t argue with its efficiency and straightforwardness. Ultimately, with this concept, you should be considering the alert itself and looking for the activity that most resembles what “success” would look like for the attacker in that context.

Ask Questions

To summarize the core concept of each of those suggestions into one idea, the best way to tell if the alert you’re looking at is in the “Goldilocks Zone” is to consider the context around it procedurally:

• How high of a priority is the event?
• How often does this activity happen?
• Does the activity from the alert help the attacker further their goals?
• What would “success” look like for that attack?

If you consider each of those things in succession, you should be able to breeze through a queue of alerts in no time.

---

---

---

---