Using SIEM Solutions to Connect the Security Dots and Detect Ransomware
Many companies, organisations, groups and individuals who are vigilant in the face of new cyberthreats create highly advanced detection and prevention systems to help potential victims identify and remediate security events as quickly as possible. While these controlling, monitoring and alerting mechanisms can be used in isolation, their true value lies in the correlation of different data sources, which requires a security information and event management (SIEM) solution.
It also detects malware associated with these domains and includes antispam software that identifies files that could damage the internal network — all in real time and summarised in a single security alert. By cross-referencing this security intelligence with public indicators of compromise (IoCs), security analysts can spot and respond to malicious network activity — especially ransomware — quickly and more accurately.
Four Processes to Maximise Your SIEM
When it comes to detecting ransomware, the early warning strategy breaks down into four processes:
- Developing the solution;
- Research; and
Below we will break down each component and explore the ways in which they work together to maximize the value of an SIEM solution.
Before we can start creating alerts and post-investigation phases, we must consider the level of exposure to threats based on the organization’s industry, public presence, and the types of businesses and users with which it engages. While ransomware can be indiscriminate, some industries are more likely than others to suffer from this type of infection. We must also ask whether organizations have the basic devices to detect threats, including firewalls, virus detection systems and intrusion prevention systems (IPS).
Sources of information come in many forms and flavors, and can vary from one vendor to another in terms of reputability. I personally use the IBM X-Force Exchange, which is continually updated, either by an internal team of researchers or registered users who create collections with IoCs such as IPs, hashes, URLs and filenames.
2. Developing of the Solution
Using IBM QRadar SIEM as a model, we can create the following components to fully develop the solution:
- Reference sets (information containers);
- Rules (logical parameters and validations);
- Search (views of data allocated in QRadar); and
- Reports (documents generated by QRadar summarizing alerts).
Below is a diagram of the network that sends this data to QRadar:
As we can see, we have at least one firewall that controls access to the internet. We can assume in this scenario that the firewall registers all incoming and outgoing events (whether allowed or not) and has a web proxy content filter, which allows us to view all the activity of user-accessed websites.
With this scenario in mind, we can start priming our SIEM solution. First, get the IoC information from any desired source — in this case, we will use the X-Force Exchange JAFF ransomware collection and a free online Ransomware Tracker tool. With this information, we will create two reference sets, one for each source.
After downloading CSV files of data from both collections, we will import them into the corresponding reference set. This is a manual task that must be done at least once a week. To automate the process, you can use either the Threat Intelligence plugin in QRadar, which can take information from TAXII servers and populate the data according to a predetermined frequency, or create a script to fetch the information and convert it to CSV.
If the data is successfully loaded to our reference set, it should look like this:
Before we create rules, we must determine from where we can capture the events. Navigate to Log Activity > Search > New Search — here we will include a relatively small time frame, such as 24 hours. We will leave the options of columns and rows as default and select Reference Set under Filters. We are then asked to indicate the destination IP.
Initially, we will make the search (and the rule) to determine whether there is an infection on the network or ransomware activity from a malicious external IP. We will select Destination IP and then indicate which reference set we want to use. If we want, we can add the category definitions on the Custom Rule filter to show only the allowed communication.
When we click on Search, we can see that we have effective communication and we then must determine where the events came from. We should factor this information into the rule creation process to make the rule more efficient and effective.
Next, we classify the event and determine whether it stemmed from communication allowed or communication denied. Here it becomes a bit subjective — in our case, we only want to see the events with allowed communication, but we could also track denied events to gauge the effectiveness of our blocking devices.
Now we can repeat the search of the source IP’s property on the reference set filter to detect any remote-to-local communication.
In summary, we will take the following information from the searches:
- Name or group of sources that send the information to QRadar;
- Name or category of events that we want to detect (allowed communication);
- Direction (local-to-remote or remote-to-local); and
- Validation of the data in the reference sets.
To create a rule, navigate to Offenses, then Rules on the left panel, as shown below:
Next, go to Action in the middle of the new page and select New Event Rule.
When creating the rule, use the following parameters:
- Event context (remote-to-local — look for any external IP trying to communicate with any internal IP);
- Log source type; and
- Destination IP.
Additionally, determine whether any of the following rules match the event:
Follow and use the desired properties to create the offenses and aspects needed based on your current necessity, such as Notification, Severity, Actions, etc. Now that you have the rule, go to All Offenses on the left panel, then Search, then New Search, as illustrated below:
Here, you will use a time frame — in this case, 24 hours. Next, go to Contributing Rule and select the recently created rule.
Click on search. Even if it does not produce results, go to Save Criteria and fill out the fields on the new page with the details desired. We will use these search criteria later to create the report.
As soon as you create the rule, you will see results on the QRadar console. The SIEM may generate false positives, including blacklisted IPs that are not necessarily part of ransomware activity. As a best practice, research the destination IP and any other external IPs, and validate the category and possible risk from other sources. Keep in mind that you can add more data into the rule, such as antivirus log sources, IPS and other devices identified during the first stage.
To generate reports, navigate to Reports > Actions > Create. Select the desired layout and timing to schedule the report. Next, name the report and select Top Offenses as the chart type. On the new page display, select the chart name and type, then limit offenses to the top 10. Select the Ransomware Offenses saved search, save container details, and continue with the wizard to customize other details and parameters.
Wait until the report is run to get some results. You can use these results to fine-tune the rule, generate statistics and gauge the effectiveness of countermeasures you’ve implemented to fight ransomware and other advanced threats.
SIEM: A Security Analyst’s Best Friend
An SIEM solution is not a silver bullet to cure all cybersecurity woes. However, it is a critical tool to help analysts make better use of the massive volume of security intelligence available to them through multiple sources. An SIEM platform bridges these disparate solutions and turns your security program into a well-oiled machine, allowing analysts to focus more on remediation and response efforts. Given today’s brutal cyberthreat landscape, security professionals need all the help they can get.