Building Argus: AI & ML threat detection at scale in Cloudflare

My name is Henry. I'm a principal security engineer in the detection response team at Cloudflare, and today I'm going to talk you through a system we built called Argus. And what I'm going to go through is explain to you what Argus is. It's pretty much a platform for our detection response team. We predominantly use machine learning detections over large security data sets. And then I'm going to take you through what goes under the hood there, take you through some of our detections that we use to build on Cloudflare gateway logs. And then the last part is about security language models, how we train LLMs to help us in investigation, what data sets we train on, and how we use it in our triage, in our detection generation as well. Here pretty much is the basic flow through Argus. We get some data through, we apply some rules, some ML detection, try and calculate a risk score, some of our models, and based on that we send an action to our cert team. Why we built Argus? So we built Argus to solve some of our problems that we face. Usually we have large data sets, large time windows, we have use some batch clearing that creates some delays in the results. We use usually SQL and then going away from these fixed detections to more anomalous, more of anomaly behavior things. And what we try and do is give evidence to people at the end on how to use these results to triage and find out what is malicious security -wise and what's not. Before Argus, this is how our detection cycle pretty much worked. We had a detection written in SQL and it's good when it's launched at the time, however there's a drift, things change, so these rules become quite brittle. So what we tried to do in Argus is to use a lot of anomaly detection on top anomalous behavior so we don't have a fixed rule and based on that we can detect when things are anomalous and possibly bad and also not to miss things that we usually run based on SQL queries. Over here is pretty much a diagram to what is Argus, the ARP platform. We run it in Kubernetes cluster in one of our data centers. Pretty much so over here is our data sources, here is our detection compute engine. We use two compute engines, we use Spark and Slink. I'm not sure if any of you heard of that, of these two engines. Spark is very good at doing AI and ML on a very large scale, it's very good for batch processing. Slink, which is this one, it's very good at streaming, so part of our detections is that we try and reduce the lag between the events and alert firing. We got now to around three seconds lag between an event being triggered and an alert firing. Here are these, these are like the tools that we use for our ML pipeline, so MLflow tracks our experiments, our parameters for each detection. Feast is our feature store, so every time we need to run the model we don't have to calculate that from scratch. Jupyter notebook for doing our testing, our development of our rules. Airflow is the DAG and we use Elastic to view the results of the alerts. So that's pretty much what Argus is. We built a UI on top of that, which sits here, which shows all of these, all of those have some sort of UI and then ties them all up here so an analyst or detection engineer can use that UI to look at things and try and find out what's going on in terms of day -to-day operation. Over here I'm going to take you through the architecture, so the slide that I showed earlier, I'm just going to focus a bit more detail on each and one of those boxes I showed and just take you through the process of how we run its detection, build it from scratch and how does the process look like inside Argus. As I mentioned, these are the different components I touched upon earlier. We use Spark for building for our batch process, our large data sets, we use Flink for streaming, we use Feast as a feature store for us for ourselves in Cloudflare, MLflow and then we pass the results through a trained LLM, which I've trained on, which I'll touch on later in the topic and that helps in filtering some of the results. We have usually a thing is that anomalous doesn't mean security bad, why? So what you do is that we try and filter that through the results, so whatever we can send out to the search team or to investigation is a lot less than the number of the volume of what's anomalous. So over here, this is how the process starts, so we read a data set, say for example our gateway logs, we read probably the last around last 30 days worth of data, we extract some features of it, so whether it's IP address, location, where people work, we probably have around 40 features we're trying to extract from that detection, we train our data sets on that, we get the model, an anomaly detection model and once we're happy with the results, we have hyperparameters. What I've been trying to do is similar for Flink, so we read the events, you read the model from there and then extract the features from FEAST, use the same model to do the scoring and then we have a risk score. That risk score determines whether it's going to be sent for search investigation, whether it's going to increase the next time run as the next time you run risk score and send all of that as evidence to our detection and response team. This is how our ML pipeline through in August, we pretty much go through the data and then we built and do some pre -processing, we load the feature store, a feature matrix if we have it, we train, we validate on top of that, if the model is having a drift, not optimized, too many results coming out, we send it back for re -evaluation to optimize the model, if it's approved, we have an approved bundle, this has a version, a hash of sorts that gets deployed and that's how the process works pretty much in semi-autonomous way for our ML pipeline. Now I'm going to talk a bit more into some of the algorithms that we use and some of the models that we use in practice. This is a famous diagram on what anomaly detection looks like, so pretty much we take a baseline or a feature, we put it on here and then we measure against a recent window, if there's an outlier, we detect on that, if it's above a certain threshold, if it's not, we just leave it as it is. Over here, these are some of the models that we use, so the k-means measures distance, a Gaussian mixed method, which is GMM, usually uses the likelihood of something happening, PCA is used for computing error, we pass that through some LLM and we use these different models and we create a composite risk scoring, measuring different aspects for different user behavior and based on that, we have a score and that score plus the evidence from each of these models gets categorized, whether it's severe, critical, high, low, medium and based on that, we can get to do some automations or some stuff down the line or send it for further investigation. These are some of our models that we use on some of our gateway logs, for the gateway logs, we use k-means, GMM, for DNS, because it has host names, we use term frequency, inverse document frequency, so that turns these domains into some wording and some matrices and then based on that, we calculate a risk score and then based on that, we do interesting things for measuring the anomalous behavior between people based on the job family, where they work, if they're an engineer, if they're non -technical and then we can do a bit of interesting clustering, compare people based on different features and different behavior. One last thing that we're also experimenting with is using LLMs for our CASB, for our DLP logs and what it does is we use a fast LLM that grabs the logs, grabs the actual rules themselves and review that and based on that review, it will have a risk score, whether it's worth investigating further, whether some of these DLP rules need some further optimization or whether it's benign and there's nothing you can do. These DLP logs, we have very large volumes of them, so no human can pretty much have the time to do that, so we have a two-step process of using a fast LLM for filtering first and then a more advanced one to review the outcome of the first one and these are some of things that we run in Argus to help us with our detections. I touched earlier now upon the LLM side and in section here, I'm going to talk you through what we built on training of our security LLMs for detection and response and how that process looks like. Pretty much the reason for that to train the data, train the security LLMs in here is pretty much to give a consistent of behavior and feedback and then also train it on a lot of our security data and then the right taxonomy, the right schema, also absentation, so it can only speak based on evidence. Over here, we pretty much been doing different types of training, CPT, which is continuous pre-training, supervised fine-tuning, direct preference optimization and then reinforced fine -tuning and based on each of these methods, I train on different types of data to help the model do two things. First one is based on detection, so if the results come, then read the model and then give some recommendation on how to optimize it. The second part is the triage part, which is it reads the results, the alerts and based on that, it can decide whether it's malicious, requires more security review or whether it's safe to drop. Over here, for the past, for the process of the training the LLMs, we also have been training two different types of LLMs. A fast one, which can run very fast, it needs the least amount of GPU to run and then that fast ranker here pretty much go through, have a very small context, can run very quickly and then you can do that in line with your detection and your alerting pipeline. In a way, it acts like a very basic triage and then the biggest part of training it is to make sure that it can abstain from making a decision if it doesn't have enough data supported in its corpus. Hallucination is a big thing and then trying to get a very lightweight LLM to abstain when it doesn't have the information and how you train about doing that. What we trained on so far, we used a lot of public security data material, detection structures, so there are a lot of repositories based on OSQuery, based on different types of Sigma, Falco, different types of rules, some cases. These have been mostly also open source, some of our material from inside Cloudflare, do some quality checks on our data, do duplication and then divide them to different categories of data sets. For the CPT, which is the bulk of the data that goes to your heavy type of data corpus, we've been training around five billion records on that. The supervised fine-tuning is usually very fast, that takes a few days to train on and then that usually can change with time. And then those two pretty much between the DPO and the reinforced fine-tuning is to make sure that you tweak the behavior of the model to pretty much respond in the way that you want it to be. Over here, I think I touched upon that, that each stage has a distinct job. This is probably the one that takes the longest and most resources, that usually takes around one week of training to get this done. The supervised fine-tuning takes around a few days, two to three days to run. These granting tools and changing the behavior of the model, that's usually a few hours. The testing on that, there are some benchmarks, there's some things between open source and industry standard ones and ones that I've internally built to test the data on, that usually takes around a day. So an experiment like that to train a model would usually take around 10 days minimum to sometimes two weeks. So pretty much it's been an interesting process and now I'm going to discuss some of the results that we've seen. It does improve a lot the outcome of the model. So these are different tasks that train the model on, so triage, networking and web knowledge. You can see here, so this is the untrained model and then the trained models. You can see here that we pretty much got very, very interesting improvements in the model's performance. I think our precision went to from 0.02 to 90 percent and the correction absentations, which is very important, which you don't want your model to hallucinate, it abstained when it didn't know 119 out of 120. So it tells you that your models, if you train it on what you want, you can get very good, very interesting and very big improvements on the performance of the model. Finally, I want to share with everyone, this is like a summary of what we've built in the last year. Argus, which is one platform, fast delivery, we can move things quite fast, we can improve the models, better detections based on machine learning, and continuous improvements for our security trained models, and have the ability to improve the models and help our analysts in terms of their work and day-to-day. And I think that's it.