In some of the recently publicised security breaches, analysts have not necessarily had the right information and tools at their fingertips to detect those breaches quickly enough. In CrowdStrike's most recent threat report, they called out the fastest breakout they saw took just 51 seconds, with the average breakout time reaching an all-time low of just 48 minutes. With that in mind, as an industry, we need to adapt and shift some of our security monitoring use cases out of the SIEM and onto the wire so that we can be alerted and take action quickly.
Several emerging products on the market are positioning these capabilities, but did you know that, as a Cribl customer, you already have that capability in your toolbelt?
In this blog we are going to discuss why we should be moving certain Security monitoring detections onto the stream as well as some practical information as to how to achieve that focusing on a common use case that I talk to customers about all the time, “geographically improbable access”, sometimes referred to as the “impossible traveller” or “The Superman Rule”.
SIEMs are a great place to be analysing data and alerting on detections, however there is some latency involved in collecting, processing, storing, and searching that data, often they are based around cron schedules, which means the lowest unit of execution is typically every minute. Some of these detections would be more valuable if they were closer to real-time, then you would be able to start remediation sooner and limit the impact quicker.
There are a lot of security detections that only require a single event to trigger a notification, or are a simple correlation between 2 events over a longer time period that require you to maintain state, the one that we will focus on in this blog is “geographically improbable access”, which requires you to maintain state about previous logins and in your SIEM this is often solved by running the search over a long time range at high frequency which increases load, can drive up costs or impact your SIEM’s efficiency.
This is where moving the detection earlier in the events lifecycle can help. When moving these detections to the wire, we will still deliver the relevant security data to the SIEM which will support the investigation or other use cases, but we will also add an additional capability so we are also creating an alert as the event flows through Cribl Stream in real-time.
When we break down detections like “geographically improbable access”, they are actually simpler than many of these emerging technologies make it out to be. We need to track the time and geographic location of the previous login by username, then compare that previous login information with the current login information, do some simple math, and then if the user could not have travelled between the 2 locations in the time between the logins, then trigger an alert in the SIEM ready for triage.
All of that is achievable with Cribl Stream.
We support the use of Redis, which we can leverage to read and update the state data from previous login attempts. In fact many emerging technologies uses Redis in exactly the same way for its implementation of this use case in their products.
We have the ability to perform mathematical calculations within our pipelines
We have the ability to make decisions about our data within our pipelines
We have the ability to format the output anyway we want giving you the flexibility to format it for delivery to any SIEM
Finally we can send the output to any destination, in this case we might be raising an alert directly in our SIEM via a Webhook.
We can also feed the events that the analyst will require to the SIEM in parallel.
When I had my eureka moment that this was all possible using Cribl Stream it was an eye opener, these techniques allow me to trigger detections for certain time sensitive use cases sooner, bringing the latency down from tens or hundreds of seconds to just a few hundred milliseconds. That exponential increase in speed when coupled with an automation or SOAR tool could be the difference between a decent nights sleep and a damaging incident occurring within your organisation.
The “Superman” or “Geographical Improbable Access” Use Case Using Cribl Stream
Useful Information before we start
Redis
We will require an external place to stash our data for this use case. We will use Redis as Cribl Stream supports Redis connectivity natively using the Redis function.
Our data flow will be something like this:
If you do not have Redis deployed today, it will be required for any on-the-wire use cases that require some state to be maintained. Redis can be deployed easily on-prem close to your hybrid workers but also has a cloud version available, here is some useful architecture advice for deploying Redis.
GeoIP Information
Cribl Stream allows you to add the Maxmind database so you can use the GeoIP function to tie a public IP address to a location on the planet earth.
Another approach I have seen with this use case is; If you have a robust CMDB and can reliably map your internal subnets to real world locations then you can enrich internal addresses with location information using the lookup function which allows for geo information to be mapped on internal addresses.
The Analytic Pipeline
I have arranged the pipeline for this use case into three parts to generate my notification.
Prepare the event
Extract any fields from my data for my alert logic
Get the current datapoints stored in Redis about the user the current event is concerning
Generate location information about the current event using the GeoIP function
Update Redis with the datapoints about this user from the current event. The hash I put into Redis against the primary key is:
['timestamp',_time,'latitude',lat1,'longitude',lon1]
If this user did not exist in Redis, I drop the event as I have nothing to compare this login event to.
Analyse the event
Rename any existing fields for my alert logic
Apply my alert logic.
I have replicated the haversine formula for this use case using a simple eval function for this use case demonstrating that even more complex math is easily achievable with Cribl Stream.
Compare the time between login attempts to the time it would take to travel the distance, if the travel time is less than the time between logins then we have an alert
Drop any events where the journey was possible.
Format the alert
Different SIEMS require events to be in different formats, so in this section, we can create the structure of our alert that we will eventually deliver to our SIEM.
Now that we have a pipeline we can create a destination where we would like our alerts delivered and craft a route for data to be passed to our new pipeline. It really is as easy as this to start moving security rules to Cribl Stream to reduce alert latency and improve your security posture.
Conclusion
With Cribl Stream, you have a swiss army chainsaw that allows you to tackle a wide variety of IT, Security and Observability challenges within your organisation.
An ever changing threat landscape is requiring that customers like yourselves are demanding faster notification of security events within your organisations with lower trigger latency and Cribl Stream offers that flexibility as the realtime engine for IT and Security Data to augment your existing toolsets no matter what they are.
The techniques described here allow you to move some monitoring use cases closer to real-time enabling you to improve your security posture and allow you to take action sooner. It might not be appropriate to move all your use cases out of the SIEM and into a model like this today, but ask me again tomorrow and my answer may be different.
