“Offloading” Your Problems with Sagan
Author: Champ Clark III, CTO and Co-founder of Quadrant Security
As our Sagan XDR solution and customer-base has grown, encountering “edge cases” has become increasingly more common; often discovering users with oddly specific use cases. I occasionally jest about Sagan being capable of “making your coffee” or triggering an alert based on the color of a user's shirt. These types of scenarios can be the bane of a programmer's existence, who often strive to keep their software as “focused” as possible. Allowing for too many unnecessary features can lead to the dreaded “feature creep” and overly complicate the software, sometimes at the detriment of the intended purpose.
Despite these jokes about edge cases, it doesn't mean the user is necessarily wrong, or that their needs aren't valid. It's simply difficult to satisfy everyone's edge case without making the core software complex and monolithic.
Instead, we must guide the user to solve their specific issues without over-complicating our code base, and this is where the new Sagan keyword “offload” feature comes in.
Introducing Sagan “Offload”
The basic principle of this new feature is for Sagan to carry out all the normal detections, but hand-off more complicated workloads to a different process for additional processing, later returning the results to Sagan and indicating whether it was successful or not.
Another way to look at it: consider a signature as a code. The Sagan signature may handle the heavy lifting, but to complete the process, Sagan refers to another program. This is a program that you control for your specific scenario. Let's create an imaginary situation as an example…
Imagine you want to create a signature to “detect brute force password attacks”, but only alert if the user is present in your Identity Access Management (IAM) platform (e.g. Okta, Auth0, Key9, etc). Sagan has numerous signatures to detect brute force password attacks, but the transition to an IAM represents an “edge case”. As developers of Sagan, do we want to code in support for every IAM system in the world? The answer is no, we do not.
We know IAM companies have API’s that allow a user to retrieve this information. While Sagan is proficient at detecting brute-force password attacks, it may not be able to access the IAM API. However, it would be feasible for the user to develop a straightforward process to query the IAM API and provide Sagan with a "true" or "false" response regarding the existence of the user.
Sagan needs a way to pass data that is currently under analysis and has passed the signatures criteria to your routine, performed through the new Sagan keyword: “offload”. The signature keyword is simple – offload: “http://127.0.0.1/myprogram”
As you’ll notice, the "offload" keyword refers to web sockets and APIs. When the Sagan signature meets yjos criteria, the final evaluation is performed by calling your program's API (e.g., http://127.0.0.1/myprogram). Sagan will send the data in the form of a pipe-delimited POST request. Your program can then perform the necessary processing and return a "true" or "false" status to Sagan. Additionally, your program can return JSON data about the processed information, which can then be added to the alert data.
This might sound familiar to the "external" keyword. The difference being that "offload" becomes a part of the detection process, whereas "external" is used in post-alert processing. The "external" keyword is also inefficient because it requires the creation of a new process after an alert is triggered; a CPU-intensive workflow that slows down processing. In the future, we plan to transition the "external" keyword to use an HTTP API model like "offload" for improved efficiency.
In our example above, "offload" refers to "127.0.0.1". However, let's now assume that our hypothetical signature consumes a lot of resources. By utilizing an HTTP API, we can easily "offload" the data processing to other machines, enabling you to scale your processing power to a cluster of machines.
The "offload" keyword is language-agnostic, allowing for scalable solutions in Python/FastAPI or Golang without having to worry about concurrency (multithreading). Since this request is in the form of a web socket, Sagan and your platform (e.g. “FastAPI”, etc.) already handle that for you.
This now enables you to write more complex detections for your “edge cases”. We have a simple example of how “offload” works with a small Golang program, which you can view on Github here.
To learn more about this feature and how it can improve your processes, let’s talk!
