Analytics are bits of code that we can use to match up known ransomware tactics and techniques with actual events on our system, as a way of flagging malicious activity. The Analytics Deployment Guide walks through the process of choosing the right analytics for your use case and using them to detect malicious activity in your raw data. Use the table of analytics below as a resource in this process.
Read the Analytics Deployment Guide
Introduction and Prerequisites
This short guide is designed as a quick starter for those who are unfamiliar with the common strategies behind analyzing cyber event data and finding threats. This guide assumes you have done the preparatory work described in the Detection guide. This means that your team is trained, you know which things in your network are most sensitive, you have created the appropriate whitelists, and you have a number of sensors feeding into a SIEM.
Review Threat Intelligence
Before deploying analytics, it is helpful to gain insight into the current threat landscape. We have a heat map of techniques that have recently been used by ransomware threat groups. We have also created a view within the ATT&CK Navigator that highlights the tactics used by ransomware software documented in ATT&CK. Organizations can learn more about tracking ransomware techniques on an ongoing basis on the Cyber Threat Intelligence resources page.
Analyze and Detect
Once you have logs consistently flowing into your SIEM and you know what you need to detect, you are ready to do analysis! Analysis comes in three main flavors:
Alert-based Investigation
Ideally at least one of your sensors will be a security alert-producing product, such as an EDR or NIDS. These sensors have already done some analysis on the raw event data, and have decided to tell you “I think something bad might be happening here,” as opposed to other sensors that are just giving you raw, unanalyzed data. If you have security alert logs, you want to start there. In an alert-based investigation, a human analyst would view the content of the alert and decide whether she agrees that the behavior is suspicious, given her understanding of normal network activity. If she decides it warrants further investigation, she will correlate the alert with the other logs available to her in the SIEM, helping to paint a fuller picture of what is happening. This is why it is important to have as many sensors as possible, to give as much context as possible during an investigation.
Hunting
Hunting consists of perusing your logs, searching for any suspicious activity, not aided by any automated alerting. This is typically done by skilled, experienced analysts who have been trained to know what to look for and also have expert insight into what normal activity on your network looks like, a result of the Preparation phase. Some organizations choose to bring in a specialized team from time to time to do this type of hunting. Hunting is important, but to some extent it can be like finding a needle in a haystack, without knowing what the needle looks like. This should not be your primary mode of operation.
Secondary Automated Analysis
While your EDR, firewall, and IDS can produce some security alerts, in many cases they are only guessing at what is bad and will produce false positives, and they will miss other significant events altogether, because they each see only part of the picture. Each security product is blind to the context of what is happening elsewhere on the network. When you have all the data in your SIEM, you have the opportunity to conduct more analysis based on more cohesive knowledge. With this in mind, there are many machine analytics that will parse through the data in your SIEM and produce alerts as appropriate. It is entirely appropriate to write your own analytics, but it also makes sense to take advantage of all the open source analytics that others have already written that may apply to your network as well. Some open source analytic repositories include:
Reference Health Cyber’s analytics table for a list of open source analytics you can use to provide maximum detection of the ransomware-related hacking techniques listed in ATT&CK. You will see that numerous analytics are available, and it might not be feasible to deploy them all at once. We recommend starting with those that cover critical techniques that are being leveraged to a high degree by current ransomware threat groups. For a picture of which techniques are trending, reference our Ransomware Heat Map.
When you have built or collected the analytics you want, you will need to do several things to run them on your data:
- Convert the analytic to use your data schema, if necessary.
- Test the analytic within your SIEM to see if it functions as anticipated.
- Set up a mechanism to feed the data through your analytics. This architecture can vary. One popular method is to run batch jobs every few minutes: this method would take the latest raw data in your SIEM and apply your analytics to it, spitting any results into a new log somewhere.
- Set up a maintenance timetable that will remind you to periodically review which analytics you have deployed, and decide if they are still relevant. Some analytics can become outdated as technology and threats change
Walk through our analytic deployment scenario for an example of how this all works!
