This guide will help introduce you to EchoTrail Scoring, how it can be used in automation, and some common use cases. Scoring can help you with anomaly detection, noise reduction, and risk adjustment automation.

Building on EchoTrail Insights

EchoTrail Scoring builds on the analytics provided by EchoTrail Insights, which you can read about here. It provides a means to programmatically compare a given process execution profile to our large dataset of typical process behavior.

This provides the same anomalous activity detection capabilities as EchoTrail Insights. However, manually writing detections for all possible scenarios or hunting for the same, would be a massive undertaking. While both detection writing and threat hunting are important, it makes sense to first automate as much of the problem space as possible. EchoTrail Scoring does just that.

Automate Process Execution Profiles

If you were to take a given process execution profile and compare each attribute and behavior to our dataset of normal attributes and behaviors, you would likely form a picture as to whether what you’re comparing fits relatively closely to normal or far afield (or somewhere in between). Doing this manually makes sense when trying to resolve one-off alerts, but using it in an automated fashion can provide many benefits. Those benefits include, adding a score to any process execution event. This score can be thought of as a risk score, where a higher number indicates normal behavior and therefore lower risk, and conversely, a lower number indicates more anomalous behavior and therefore higher risk.

Common Use Cases:

• Anomaly Detection - By automating the process of adding an EchoTrail risk score to each process execution event in question, you can quickly sort and highlight any with a score below a particular threshold. For example, all executions with a score below 20 might be interesting to you. Starting with scores closest to 0 will immediately bring to your attention the most anomalous activity in your environment. This provides a very simple way to not only identify anomalous activity, but also prioritize the order in which you look for it by simply sorting the results of scored process executions.
• Noise Reduction - In a similar vein, but on the opposite side of the score spectrum, you can also easily automate the process of filtering out the known and common process behaviors. When thinking about the problem of signal-to-noise ratio (SNR) in security, we are always fighting the battle of too much information making it difficult to find the important things we are looking for. Using a threshold of 80, for example, you could quickly weed out common process behaviors by ignoring items with a score above 80. That makes your actual search space much smaller, with the lowest scores being the highest priority items to assess and working your way up from there. Of couse, much of this process can be automated, leaving the analyst with much smaller problem set to contend with.
• Upgrade/Dowgrade Automation - While the use cases of anomaly detection and noise reduction involve operating on raw process execution events, the same pattern can be applied to alerts coming from other security devices. Any alert that contains some metadata about a process execution can also be scored. By enriching alerts with a score, you both automate a process of upgrading or downgrading the severity of that alert based on a customizable threshold that is appropriate for that alert type, and you provide additional context for the analyst resolving that alert. For example, if you receive a high volume of low or medium priority alerts from a particular device, you can score those alerts with our scoring API and then upgrade those alerts to a higher priority level for any that receive low scores (higher risk). The reverse is also true in that you can downgrade alerts with high scores (low risk). Note that you need to understand both the original alert/detection as well as how scoring works before deciding to automate the downgrade path as you risk missing an important alert that might be a high priority for a different reason. The risk with upgrading an alert is alert fatigue, which is still important but those are easier to tune since they are brought to the attention of an analyst when they might not have been otherwise.