Adaptive Intelligence: Detecting sophisticated and persistent attackers

I'm Chris. I work as a product manager in the web integrity and trust team. And I look after adaptive intelligence. We're part of the bot management team. And today over the next 20 minutes, the lightning talk, we'll be talking a little bit about sophisticated and persistent attackers. It's what we've built adaptive intelligence for. And it's an important part of detection going forward. Within our team, we look to answer two questions. Are you who you say you are? And can we trust you? And based on who we're looking at trying to detect right now, those questions have been more important now than they ever have been. Our vision is to answer these questions across every single entity. And as they transfer through all of our customers applications. And we believe if we can do this accurately enough, then we can solve for most bot related cybersecurity incidents that we see today. And certainly the ones that we might see going forward as well. So being good and improving on bot detection is certainly a core component of this, but also so is trust. There are an increasing amount of individuals who are starting to utilize automations to improve their day to day with their workflows and stuff like that. And whilst there's certainly a lot of malicious traffic that still resides underneath that automated umbrella, the landscape has become more nuanced. So our detection capability has to follow. As point of demonstration, can you just raise your hands right now if in your day to day at work you are using agents or assistants to get your job done? That's great. And that's not a surprise and keep your hands up if you're building that capability for your customers to do the same on your applications. Right, because there's a lot of legitimate traffic that sits out there. From my perspective, from a professional life, most of the automations for me are helping me plan my day. They'll be helping me with administration, improving my workflows, helping me surface data points and get insights into that data as quickly as possible. But there are other people who are also following this. Attackers. They're improving their workflows. They're improving their quality of data as well. And it's really important that we strive to understand how we can attack and defend against those sorts of attacks. So there are two things that are converging at the same time that make the traditional way in which we were thinking about bot detection slightly more nuanced. It's still somewhat relevant today, but will start to become more obsolete as we think about things tomorrow. The first thing is that the line between automation and human is almost entirely blurring, completely blurred in some instances. We see an increase in the number of hybrid environments. So these are things like Chrome and the integrations that they have with Gemini Pro subscriptions or Claude. We see OpenAI with Chrome inside Codec. So across the spectrum, there is a lot more opportunity for automation. Personally, for me, I use it in my personal life as well. I love going on family holidays, but I absolutely hate booking them. It's just such a pain for me. It's multiple sites I have to look at. Hundreds of different permutations of hotels and flights. The prices all seem to change. It almost ruins that holiday experience before I've got my passport out the drawer. Now I can give Claude an understanding of what makes a good family holiday for me. I give it unrestricted access to my browser and go away, come back maybe an hour later, and I have a curated list of great holiday ideas with live prices within budget and a rationale as to why those would be good holidays for me. On the other side of this, we're also seeing an increase in the level of sophistication in attacks that we are observing across Cloudflare networks. There's two things that are kind of at play here. The individuals aren't necessarily getting more sophisticated themselves, but the time it takes them to get those attacks back underway is being shortened considerably by the use of LLMs and automations. Additionally, it's democratizing the barrier to entry. A lot of the individuals who probably didn't have the engineering capability to put more sophisticated attacks in play, they're using automations now to really help them to level up their game and level up the attacks. So the point for us now isn't necessarily about just looking at automation. It's making that differentiation between well-intentioned good automation and the automation which is effectively an attack which is about to start or is already underway. So these sophisticated attackers are incredibly intelligent. They are well -motivated, sometimes economically motivated as well. And when they start to get blocked on their attacks, it's not their intention to stop. It's their intention to understand a way to re -engineer this as quickly as possible and get back in the game. So they'll grab, maybe jump onto Discord they'll start talking to a Pearset about the fact something had gone wrong. They'll work through the night and eventually we'll find a workaround to the defenses that have been put into place. In some instances, there are libraries of services. These individuals may even be contributing to those libraries of service. So economically benefiting from creating the workaround as quickly as possible and then getting it into the hands of people that rely on them. Traditionally, we have been, as an industry and at Cloudflare, using static version models for bot defense. And for more simplistic automations, this actually is still a particularly good strategy. But unfortunately, when you have people who are highly motivated to try and get around your defenses, every time we have to put a new detection in place, effectively building up that defensive wall, we're finding that people are getting around those defenses far faster. The best defense in the world, when it is static, cannot keep persistent attackers who are always probing and looking for weaknesses out indefinitely. We might be able to buy some time, but ultimately this is not the right path when we're looking at sophisticated attackers. Our approach for this particular cohort is to acknowledge that the state has changed, understand specifically what has changed in that, and then build for that new state. When you look at this through the lens of game theory, there's a name for it. It's asymmetric adversarial game. It's asymmetric because the cost of making a move and a counter move is different between each side, the defender and the attacker, and the information that they have access to is also completely different. It's adversarial because the outcome that each side is looking to achieve is in direct conflict with one another. So to be successful here, it's not about just playing the game the same way that you would for a more simplistic set of automations, building those defenses or the detections into that wall. It's more about attacking the incentives, and in this case it's about how much it costs to make your move and your counter move. Right now, the attacker unfortunately has that advantage. The asymmetry is running in their way for three key reasons. Firstly, information. Every time we put a new detection in place or a new block, that's an incredibly strong signal for them. Something that was working yesterday is now broken today, and they want to find a way to make that work tomorrow. When one or two things change, it is very, very easy for them to understand exactly what that was and reverse engineer the block to get their attack underway. Secondly, from a cost perspective, as I mentioned before, there are off-the-shelf toolkits. Reverse engineering for them has never really been quicker, and this is in terms of costs for engineering the solution itself, how to get around things. From our perspective, we have to be far more careful. Any counter moves that we make, we need to ensure that we're not breaking anything. They don't have that problem. Their idea is to actually break the thing so they can deploy far faster. On faster, there's also time. Chances are that there is a group, and somebody within that group has already fixed this problem or it's available in the library service. Effectively, these three things, when you take them together, mean that the attacker is spending far more time doing damage than they are trying to work out how to get around today's defenses. An attack is in one of two phases. It is either live and it's doing damage to applications and your customer databases or whatever it is that they're looking at targeting, or the attacker is adapting. They're trying to work out why the thing that was working yesterday isn't, and they're reverse engineering these defenses. In game theory, the idea here isn't to win every single round of that back and forth. What we're actually trying to do is inject as much friction into this process as possible to slow things down. Two things need to be true to make that happen. First, the cost for us to defend needs to be incredibly cheap. Just flicking a switch would cost them weeks of adaptation. Second, we need to starve them of information because even the cheapest move on our behalf is entirely worthless if we tell them specifically how to fix the thing that we just broke for them. Right now, the ratio is working backwards. It's not the way we want to see it. For every day that an attacker is spending in adaptation mode, they can have weeks and weeks of the attack running live. This is somewhat as a demonstration as opposed to hard numbers, but what I want to show you here is that the ratio is on the wrong side. What we want instead is for every single day of attack, it takes them weeks of adaptation to sustain that attack. There's a human on the other side of this as well. They have human traits, frustration, boredom, ego. We want to attack those things. Those adaptations have to be as painful as possible to make sure that they just want to give up. They may find that they get 80% of the way there. They can't quite work out how to continue the attack on the target they had on the Cloudflare network. Maybe there's a softer target elsewhere. We want to encourage them to move away from applications that are largely under our protection. This meant that we went back to the drawing board. It's not thinking about how we can build better rules and build that wall just that little bit higher. We went back and thought what if we were to build a system under the assumption that from day one, a determined attacker is always going to make its way through. This led us to three key insights. First, the system needs to automatically notice when something goes wrong. Secondly, it needs to be able to adapt to that new state. Thirdly, it needs to be able to react on its own, be that if it needs to monitor something and flag it or if it needs to do something to lower bot score into a more enforcement related zone. To do this, there are five key things that we have and are in the process of delivering. First one is speed. Now, this is about how quickly we can react to attacks that are live in the moment. But it's not just about that. Static version models are incredibly expensive to research and to deploy, which is why they only happen infrequently, usually on an annual or a semi-annual basis. The problem that we have here is that the efficacy is particularly high at launch, but over time that starts to diminish as people start to work their way around the defences. We're effectively playing cat and mouse when we're putting the new detections in place. What we have with adaptive intelligence, which this is the first component that launched at the end of August, is the ability to react as quickly as we need to when a new attack pattern shows. That's either us retraining the model on new features, getting better in areas that we know that we haven't necessarily covered thoroughly enough yet. But it's also the ability for us to make sure that we're not stuck on a specific schedule. We can react when attacks are at their highest or most prevalent. Secondly, we aim to close a lot of the structural gaps that we see today. There are three areas that we cover with bot management. There's simplistic automations, there's a middle ground, and then the more sophisticated side of things. Here, this is really helping us close down that middle ground where there are some very obvious places where attacks are masking themselves right now. And we know that there are things that we can do about that now that we can train faster. So, for example, this quarter, we're going to be doubling down on trying to get much better at detecting within the residential proxy space, areas where we know that some of these moderate attackers are actually masking themselves. Secondly, we're also looking at bridging the gap between the network signals and the client-side signals that we see. So, it may be that a network signal managed to spoof us at some point, but when it gets into the browser -level signals where we're looking at things like typing cadence, how a mouse might move, how a browser gets driven, the information gets put in, despite the fact there are some things which are relatively intelligent on this, when you're looking across the whole session, it's actually really, really difficult to spoof things like precursor. So, we're bringing those two things together to make sure that we're closing down those gaps where we can. Sorry, you said you're bringing two things together. You're bringing precursor and what together? Things like residential proxy detection. So, we've got the network stuff where there's a lot of network signals that we're looking there, and then we're bringing precursor, which is the more browser-related client-side stuff. Like some of the ephemeral ideas of that? It's not about ephemeral ideas. That comes up in a minute. So, yeah, the question was there were two things that I'd mentioned, and I was just answering that it was the network stuff and the browser-related side of things. Right now, they work or have been working independently from each other. This is what we're calling silent signals. Effectively, at the moment, when we detect an attack, there'll be several signals that we can understand how that attack actually has unfolded. We put those into labels and train the machine on them. Generally speaking, though, what we would do is find the strongest signals and then use those as blocks and largely leave the other signals alone and decide that they weren't strong enough to enforce against. What we're doing now, though, is splitting out the areas where we would look to block an attack from where we can monitor. This gives us the ability to effectively start to fingerprint attackers. So, when they get blocked, then they go away and come back. We can start to frustrate some of their adaptations far faster than if we were just starting from zero again. We're also starting to baseline what normal looks like. At Cloudflare, we often talk about fingerprinting the signals against our network. Here, what we're doing is understanding things like browser version, operating system, language, geographic location, et cetera, et cetera. What that enables us to do is start to build patterns so we can understand how many English-speaking users in Paraguay are on the latest version of Chrome, for example. Once that baseline is set in the system and adaptive intelligence understands what that looks like, when there are variances within those signals, adaptive intelligence can automatically signal that something is wrong and either flag it for a human review or go into some sort of enforcement action as well. So, this is more about our ability to react faster without a human in the loop doing some level of triage first. And lastly, on the ephemeral rule side of things, we call this disposable rules. Disposable detections is probably a better way of thinking about this. What we do here, actually, when I was saying there was an incredibly strong signal that we give to attackers when we start to block them, what we want to do here is inject a lot of noise into that signal. So, we raise lots of disposable detections into the mix, force the adaptations, and then effectively just retire these and they'll never get used again. What we're looking at doing here is frustrating the attacker and making them waste their time. Everything up until disposable rules is stuff that we're looking at delivering within Q4, Q1 timeframe. Disposable rules, what we want to make sure is that we've got really good guardrails in place so we don't end up causing more of like false positives or friction for our customers. So, from that perspective, there's a little bit more time and R&D that we're putting in place to make sure that these launch as frictionless as possible. So, drawing to a close, key takeaways to this is that we're seeing sophisticated attacks on the rise and that's one of the main reasons why we have launched Adaptive Intelligence. Our aim here is to put best defence in place and combine that with frustrating the attacker's ability to adapt. We think this is the best way for us to win as opposed to the cat and mouse game that we play today. Adaptive Intelligence is rolling out. The first version of this has already launched on the 31st of August. There are going to be more frequent launches as we go through Q4 and Q1. The models will update automatically as well to make sure that the coverage is as good as it can be. Not every customer has auto-upgrade machine learning toggled on. The vast majority do, but the ask for me is just look on the dashboard, make sure you work with your representatives and get yourself on our most up-to-date protections. Thank you very much.