Cybersecurity teams continue to struggle with the challenge of alert fatigue. SOC staff, detection engineers, and CSIRT/DFIR professionals struggle to determine the true significance and severity of alerts or detections. On one side, detection engineers constantly innovate methods to catch threat actors. On the other side, SOC and CSIRT staff are inundated with numerous alerts, requiring them to prioritize and take action.

It may seem logical to increase the number of detections to bolster metrics, but this approach inevitably adds to the problem of alert fatigue. So, how can security teams strike a balance that ensures the presence of effective detections without overwhelming SOC analysts and incident responders with alerts that offer little value in thwarting threat actors within an organization's network?

I spoke about this significant challenge during my presentation at the 35th Annual FIRST Conference in Montreal, particularly in organizations where there are distinct teams responsible for writing detection rules and those handling incident response and forensics. I've always had concerns about determining which alert should be our top priority in preventing a compromise. It's crucial to identify the alert that signifies a compromise in progress, or one that is about to happen shortly. It’s these alerts that our security operations team needs to jump on as a priority as they present an immediate risk to organizations.

In my view, the MITRE ATT&CK framework provides an excellent perspective on the actions that threats are currently taking within the environment. However, when these alerts are transferred to a Security Operations Center (SOC) or Computer Security Incident Response Team (CSIRT), it doesn't necessarily mean that they should automatically prioritize these alerts as the most critical ones to investigate.

For example, consider how detections for Cobalt Strike and Mimikatz are handled by ATT@CK and how they are handled by the Kill Chain. While both tools are concerning, Cobalt Strike alerts might often be viewed with greater urgency because they indicate an attacker has achieved a significant level of control over a compromised host and can direct it in multiple malicious ways. In contrast, Mimikatz indicates credential access, which is also concerning but might be a precursor to the deeper control Cobalt Strike signifies.

In practice, the urgency assigned to any alert also depends on the context—where it's seen in the environment, what else is happening, the potential impact, and more. As you can see in the graphic below, these detections map to different stages in the cyberattack lifecycle. The differences in how both frameworks treat these threats can be understood by examining their philosophies, granularity, and intent.

Kill Chain: It provides a linear progression of an attack from its inception to its conclusion. The focus is on understanding the attack's progression and trying to stop it at the earliest possible stage. The "Phishing Link Detection" would typically map to the "Delivery" stage in the Kill Chain, indicating an initial attempt to compromise a system or user.

MITRE ATT&CK: This is a more detailed, matrix-like framework that focuses on the tactics and techniques an attacker might use post-compromise. It's about understanding the "how" of the attack, i.e., the specific actions attackers take. "Cobalt Strike Detection" might map to multiple techniques, like "Command & Control" or "Defense Evasion", indicating that an attacker has not only gained access but also established a foothold.

Kill Chain: It offers a high-level overview of the stages an attacker goes through. While it helps understand the attack progression, it might not delve deep into specific tools, techniques, or actions within each stage.

MITRE ATT&CK: This framework offers a much more granular view of attacker actions. Every technique in the matrix can further be broken down into specific methods, tools, or procedures. Therefore, it provides a more in-depth understanding of the attacker's modus operandi.

Kill Chain: By this model's philosophy, early detection (like "Phishing Link Detection") is key. The earlier you detect and disrupt the attack, the less damage potential there is. Thus, detecting a threat at the "Delivery" stage might be seen as an urgent call to action. It also means the later down the Kill Chain you detect something, the further the threat actor is embedded in your environment, and the higher attention you need to give that type of detection.

MITRE ATT&CK: A detection like "Cobalt Strike Detection" implies that an attacker has already compromised some part of the network and is potentially moving laterally or escalating privileges. This would generally be treated with high urgency because it indicates a deeper level of intrusion.

In essence, while both frameworks aim to understand and categorize cyberattacks, they do so from slightly different perspectives. The Kill Chain emphasizes understanding the progression and disruption early, while MITRE ATT&CK dives deep into specific attacker behaviors post-compromise. The varying treatment of threats in both models stems from these foundational differences.

One very rudimentary approach to alert triage is to start from the oldest alert and slowly work your way through the list. The challenge with this approach is that it doesn’t help you focus on preventing a threat actor from achieving “Actions on Objectives”, which is really what a SOC and DFIR staff should focus on as a priority.

For example, it should be more important for a SOC to triage an alert that detected Mimikatz being used, over an alert that is someone performing an external port scan of an organization's network. However, if the port scan occurs first, and you’re just triaging alerts in time order, you may not stop the threat actor currently using Mimikatz in your environment.

To deal with this challenge, I wanted to share the below Cybersecurity Alert Priority Matrix that I’ve slowly refined over several years of working in the DFIR industry. The idea of this matrix is to enable teams to give a priority rating to an alert, so they are focused more on alerts that could result in widespread compromise, than others that aren’t critical (yet). I’ve tried to make this as generic as possible while conveying what alerts should be prioritized over others.

It is important to understand that the Cybersecurity Alert Priority Matrix below is written from the perspective of the importance of the alert and whether the DFIR team should be alerted. That’s not to say every alert is (sometimes) important, but there are certainly alerts that are more important than others, and this matrix attempts to give SOC staff a starting point to help prioritize alerts.

Following the reception from the 35th Annual FIRST Conference in Montreal, there was one interesting topic raised that I hadn’t considered, and that’s location, location, location! 

There is another factor that plays an important role in helping with the priority of triaging alerts, and that’s “where” the alert is getting fired from. For example, is Cobalt Strike on a Developer’s Laptop as bad as Cobalt Strike on a Domain Controller - well, the answer to that is always the Domain Controller. If the threat actor has “Domain Dominance” then you need to triage that alert first. 

But what if the threat actor is detected on the Domain Controller and also on a device that provides medical life support in a hospital? Then things start to become a little harder.
Stay tuned for a future update to the Alert Priority Matrix that helps to solve the problem of location.