Why do we have low severity threat use cases?

What is the purpose of low-severity cyber alerts?

It is standard practice to categorize cyber threat use cases by severity on a scale typically: low, medium, high, and critical. Everyone cares when something is critical or high, but does anyone care about the lows?

What even is cyber alert severity?

Use case or alert severity is typically a function of two key factors related to threats: likelihood and impact. If something bad is happening, we want to know what the potential impact is so we can prioritize action. Separately, we need to know how likely that bad thing is to have happened.

MASSIVE, SIDE TANGENT: Likelihood is hard to derive and is often assessed as how frequently a given use case contains an actual threat. Under a different lens, likelihood is seen as relating to the level of confidence between the frequency of 1) how often a given use case 'fires' off an alert, and 2) how often those alerts lead to a real response action. Moreover, this confidence is weighted not just on how often the use case is 'right' in its detection but also on how often that use case fires. Many environments don’t see a large volume of actionable threats, and so if one of their given use case fires a lot, then it can be perceived as to be low confidence and, by association, the threat potential low likelihood. That last leap is certainly a huge stretch, but that’s how it often appears in practice in the real world.

What are low severity use cases?

We pulled some low-severity alerts from a very common security tool.  What you’ll find is a mix of things that sound somewhat interesting or downright scary.  

These use cases have all been classified as low severity:

• Fileless Attack Behavior Detected
• New SSH key added
• Privileged command run in container
• Process seen accessing the SSH authorized keys file in an unusual way
• Python encoded downloader detected
• Connection to web page from anomalous IP address detected
• Suspicious access to possibly vulnerable web page detected
• Spam folder referrer detected
• Command within a container running with high privileges
• Container running in privileged mode
• CoreDNS modification in Kubernetes detected
• Creation of admission webhook configuration detected
• Detected suspicious file download
• Docker build operation detected on a Kubernetes node
• Excessive role permissions assigned in Kubernetes cluster
• Exposed Redis service in AKS detected
• Kubernetes events deleted
• Kubernetes penetration testing tool detected
• New container in the kube-system namespace detected
• New high privileges role detected

Why are these use cases treated as low severity?

It’s all about precision. Sometimes, you can observe actions that threat actors take, but how you detect those actions isn’t precise enough to only include the bad actions. Thus, these use cases fall victim to a ton of false positives.

What happens to alerts from low severity?

The sad truth is not much. They were created by some smart person who realized they could observe bad guys doing bad things. However, operationalizing these use cases was too expensive (in terms of people's time). Given the secondary goal of every SOC analyst is to eliminate all false positives, many of these use cases end up in the basement collecting dust.

Don’t leave me hanging!

So, what CAN you do with these use cases?

1. Threat hunting
2. Use them to add context to other investigations
3. Mine them to find patterns that raise the overall threat rating of a user or system
4. Hire Salem. This is basically the reason we created Salem, the AI Cyber Analyst. Real SOC analysts are great but are also limited by biology and wall clocks (and really hate repetition). An AI analyst doesn’t have these limitations so it can be the front line of defense against false positives and breathe new life into low-severity alerts. Blue teamers, rejoice!