Pricing Login
Pricing
Support
Demo
Interactive demos

Click through interactive platform demos now.

Live demo, real expert

Schedule a platform demo with a Sumo Logic expert.

Start free trial
Back to blog results

July 14, 2020 By Sumo Logic

Cloud SIEM: Getting More Out of Your Threat Intelligence - 3 Use Cases for IOCs

Background

Ever since JASK was founded, we have heavily integrated with threat intelligence platforms to gain context into attacker activity through indicators of compromise (IOCs). Now that we have joined Sumo Logic, our customers have the ability to pull in more data than ever making this feature even more powerful.

One of our tightest integrations is with the Anomali (formerly ThreatStream) platform. The gist is we pull IOCs from their API (IPs, domains, and file hashes), and automatically check all ingested records for matches. These Signals provide great context for the analyst when investigating Insights.

Going Further

While simple matching is a great baseline for context, it is more powerful when you take these IOCs and build out more thoughtful use cases. In Sumo Logic Cloud SIEM Enterprise, you can take advantage of the different rule types to accomplish different goals.

The Templated Match Rule allows us to perform a simple match but pull details out of the event to adjust the Signal name, description, and even severity. The Threshold rule allows us to find anomalous activity based on our norms in our environment. And lastly, Chain rules allow us to go a step further and wait for another event to also happen before creating the Signal.

Use Cases

  1. Templated Match Rule - IOC login attempt (successful and unsuccessful)
  2. Threshold Rule - IOC attempting to Login to more than five accounts
  3. Chain Rule - IOC attempting to login to more than five accounts with a successful login from an IOC

Templated Match Rule - IOC Login Attempt (Successful and Unsuccessful)

The first use case is the most straightforward. We are basically going to look for any authentication type event that is also from an IOC IP address we are tracking. In addition to this, we are going to set the severity of the Signal based on if that authentication was successful or not.

To do this in CSE, our expression just needs to look for all records where the objectType is Authentication and the listMatches array contains a threat match. We will then want to associate this match to the username since that is the potentially compromised account. Now, moving to the templated values. The Name will show whether or not the attempt was successful, and the Description will also show the username whose account was used. Lastly, we will set a severity to 1 when the success value is false, and 8 when the success value is true.

Threshold Rule - IOC Attempting to Log In to More Than 5 Accounts

While these individual matches are great for context, it is more important to track persistent attacks on your accounts. To do this, we can use a Threshold Rule that looks at the distinct number of usernames an IP attempted to authenticate to. This rule is going to look very similar to a Password Spray or Brute Force attack rule, but we will be focusing on IOC matches now.

To do this in CSE, we will still be using the same expression as the first rule which tracks all authentication events that have a source IP address that is an IOC. But, in this case we will also be tracking the distinct usernames attempted on. As you can see, we have the “count distinct” box checked and have it counting the distinct usernames.

In this case, if we see more than five distinct usernames attempted from the same IOC IP in five days, we will see a Signal.

Chain Rule - IOC Having 5 Failed Login Attempts with a Successful Login

Moving to our final use case which is a combination of the first two to create an extremely high fidelity Signal. The idea is to first check for an IOC IP having five or more failed login attempts in a five day window while also checking for a successful login attempt. If one of the other happens, we don’t get a Signal, but if both happen, we get a Signal.

The actual logic is very similar to the first two use cases, except we are going to be checking if success is true or false.

Wrapping Up

Threat iIntelligence is oftentimes thought of as mostly contextual, but as you can see, you can use it to create high fidelity Signals as well with the right data coming in.

To do this in CSE, our expression just needs to look for all records where the objectType is Authentication and the listMatches array contains a threat match. We will then want to associate this match to the username since that is the potentially compromised account. Now, moving to the templated values. The Name will show whether or not the attempt was successful, and the Description will also show the username whose account was used. Lastly, we will set a severity to 1 when the success value is false, and 8 when the success value is true.

Complete visibility for DevSecOps

Reduce downtime and move from reactive to proactive monitoring.

Sumo Logic cloud-native SaaS analytics

Build, run, and secure modern applications and cloud infrastructures.

Start free trial

Sumo Logic

More posts by Sumo Logic.

People who read this also enjoyed