🔒 Security Week: App Sec Updates

<v Daniel Gould> Hello. Hi everyone. Welcome to Cloudflare TV. Once again we come to you from Security Week 2023. Today's Thursday. Lots of great announcements already and today is just more of the same, more innovation. And actually today we're actually here to talk about some application security innovations. And as a matter of fact, we're making more capabilities available to more organizations, more customers. And we actually have a couple of innovations today that we're actually extending to our biz customers. Very, very exciting stuff. Now, my name is Dan Gould. I'm on the product marketing team for application security. I'm thrilled to be joined by a couple of colleagues I work with a lot, Daniele and Adam. Do you guys want to say hi? <v Daniele Molteni> Sure. Hi, I'm Daniele Molteni. I'm the product manager for the Web Application firewall, and I'm based in London. <v Adam Martinetti> Hi everyone. My name is Adam Martinetti. I'm the product manager for our Bot and Fraud products, and I'm based out of San Francisco. <v Daniel Gould> Yeah, awesome. I love these guys, I work with them all the time and I'm glad to have them on with me. So we'll cover a couple of things today as we think about these new application security innovations. And one is actually related to the WAF and our security analytics and how that's becoming available to more customers. And also, Adam will talk to us about how we're making Super Bot Fight Mode more usable, more flexible and better able to really thread the needle between security and business, right? To meet the needs of every organization. So with that said, Daniele, why don't we start with you? And I'm going to talk about the WAF today. And we actually had a bit of news on security analytics on the blog this morning. You know, what have we launched today in a nutshell? <v Daniele Molteni> Yeah. Look, I'm so excited. We recently launched Security Analytics and the WAF Threat Score for our Enterprise customers. This was back in December. My colleague Radwan launched it, and today she had a new launch as well, which basically she's making that available to all business customers. And it's like massive news, because this is our top and most recent, if you want, WAF feature that can identify very advanced threats and this IS made available also to all our customers. So that's very, very good news. <v Daniel Gould> Interesting. Okay. Powerful stuff. So we're going to take a deeper dive into that and we'll talk about really how it works, what it is, and even what it looks like. I think, Daniele, you'll give us a demo. But, you know, before we do that, it probably makes sense to start at the beginning. Start with the why. Like, why does something like security analytics make sense? And, you know, we were talking beforehand and I think reviewing how Log4J came together, like that attack and how vendors responded, I think does illustrate how and why something like security analytics can be so useful. So if we go all the way back, right, we're talking in security years, even though it was only what, like, you know, 13, 14 months ago, it feels like ages, to December 2021. I believe it was December 9th, if I'm not mistaken. And, you know, feel free to correct my math here. The world got wind of a very severe vulnerability right in Log4J. And that would ultimately let an attacker run malicious code on a server with Log4J and really, really bad. And it turns out Log4j is sort of a very useful piece of I don't want to call it middleware, but, you know, functionality that was all over the Internet. So this is really, really critical. Lots of organizations were exposed and had to quickly either patch or get protections in place. And so, you know, we got wind of that right away. And as a leading WAF vendor, though, you know, within hours we actually released three rules. Right? And Daniel, I think you had a front row seat for that. It was the team in London, I think, that really scrambled, right? <v Daniele Molteni> Yeah. I mean, the usual response of a WAF vendor is to create a rule. So Cloudflare has a team of security analysts like other WAF vendors, and their job is to monitor for new vulnerabilities like Log4J. And when such a high profile vulnerability is made public, they immediately start to create a rule and work on a rule that then is deployed in the traditional WAF. And a traditional WAF is basically a set of rules that are like signature based, right? So think about Regexes. So they're looking for patterns of a very, very, very specific attack. So they're looking for the exact, if you want, words. We can we can we can say words that an attacker is using to try to exploit that vulnerability. So the the quality of the rule is usually measured in the level of true positive. So is there an attack and did they actually identify the attack correctly? And also the level of false positives. And these false positives need to be low. And a false positive is like, "Oo, there wasn't any attack in this request. But actually, for some reason my rule flagged it as as malicious." And so you want that to be very, very low and you want to have the true positive to be to be 100%. So you want to identify every attack. And so the normal, if you want, operational way for us to create a rule is like we identify, we hear about this vulnerability and we create a rule, we publish a rule. And the rule is usually deployed in front of all of our customers to protect their traffic. And you I think you followed very closely this event. And yeah, I think we. Yeah. What do you think? How did that go? <v Daniel Gould> Yeah, and I would say, you know something that that we take very, very seriously. Well two things and you know, for starters, it is getting protections in place fast, right? Because there's this window of exposure that we need to to make as narrow as possible. That is our job. That's what people pay us for, right. To make sure that they stay safe or their applications stay on track. And they're not vulnerable to more risk than they should be. And I will say that, you know, the team in London scrambled really fast and within hours we had these protections in place you're talking about. And we looked at how other vendors responded. And, you know, knock on wood, we responded many, many hours sooner than our leading WAF competitor. And not only does that matter, but what you just said, right? Making sure that we're not accidentally blocking legitimate business, but only blocking attacks. And just by the by, we won't make this a session about, you know, rule testing. We do go to great lengths to make sure that our rules are very precise and only block the bad and don't block the good. So, anyways. Back to December 10th, 2021, we released these three rules and customers. In this case, they effectively woke up, got out of bed, and they were protected automatically. Very, very powerful stuff. Right. And so, you know, that obviously, you know, for those trying to launch attacks to exploit Log4J, that's frustrating because their attacks, their initial attacks at least, are no longer effective because there's a rule in place to block them. Now, at this point, Daniele, this is where the game of cat and mouse as we hear about begins, right? And this is where I believe we saw a lot of new attacks occur that were slight updates on the prior attacks, evasions with the deliberate intention of trying to evade the rule we had in place, right? <v Daniele Molteni> That's correct. So attackers mutate the attack, so they try different things. So they try to perhaps change where they're running attack, what part of the request. But as you said, because the rule is designed to have very high, true positive, it needs to be very, very, very specific. So there is room for the attacker to bypass that rule by trying to obfuscate, if you want, the intent of that request. And I guess that's the real motivation for the attack score. That was one of the feature we launched because the attack score, what it does, is basically an abstraction built on top of rules. It is actually a machine learning solution that looks at the request and tries to identify whether it's malicious or not. But instead of being a binary, providing a binary output as a rule like a rule does, a rule is either it matches or it doesn't match, right? Binary. Instead of being binary, it provides a score, and the score is between 1 and 99, where one means that the request is a malicious content and 99 a clean request. So, there is much more, if you want, nuances in the way we look at the request, it's like, is it malicious or not? Maybe. And it's not scale. And so this gives control to to customer about what they want to block and, tell us a little bit more why this is also useful to identify attacks early on. <v Daniel Gould> Yeah so we talked about these rules and rules are still critical, right? Like, we actually take them very seriously. However, to compliment them, when these evasions are coming at us, I think these, you know, the machine learning protections or detections you're talking about will really help organizations stay safer even when they don't have an explicit rule in place to block an attack. Right? So this really helps them get to a more effective security posture that will block even sort of attacks that are unknown or unrecognized by the world yet because they're active evasion attempts by attackers who have been successfully blocked already by our rules. So this really helps organizations get to a better security posture, something that really is what they ask us to do. So we take it really seriously. <v Daniele Molteni> Yeah, exactly. So the ML model can identify attacks variation because it's not as strict as of signature based. And so any deviation can actually be identified early on. And then we are seeing already at some CVEs that perhaps are not made public yet. We identify them early on. So there is no need anymore to have a security analyst around the clock looking at those CVEs and creating a role against time because we can catch it early on, right? And of course, it's going to be the need for security analysts to develop a rule, a proper rule. We're not going to remove that part of the WAF, that part of the WAF is going to stay. But complementing a traditional signature based WAF and attack score will provide the highest level of security we have seen so far in the industry. <v Daniel Gould> Yeah, and you know, I would love to see this sort of what this looks like. And just a quick note, like as we were bringing this to market and Danny, like, you know, this there was actually last fall a critical Apache vulnerability. I think it was 9.8. And, in testing, our machine learning models, detections here that are running for security analytics actually recognize the exploit attempts without explicit rules in place. So we've seen this actually have great effect in the real world already, right? These aren't just, you know, machine learning models running in some lab. These are actually have already proven effective in recognizing evasion, exploit attempts against applications when there isn't a rule in place. So they've already really proven effective. And so actually with that, you know, as my grandmother always used to say, Daniele, a demo is worth a thousand words. She was a wise woman. <v Daniele Molteni> Yeah. Your grandma was very wise. Yes. <v Daniel Gould> No, it'd be great to. <v Daniele Molteni> Yeah, absolutely. So let me share my screen and then we can walk you through the attacks score and how does that work? So we can't speak about attack score without talking about security analytics. So security analytics is the control plane for attack score but also for things like bot score. And we're going to go in there in a second. Security analytics basically shows all your traffic, and it shows the traffic divided by mitigated and not mitigated, which means if an application here you'll see in the graph in the middle, I'll see all my traffic over the last seven days. The blue line tells me this is my total traffic, good traffic that reached my origin. And the pink one shows you how much of that traffic was mitigated by the WAF in general. So you can really look at traffic that potentially should have been mitigated, should have, you would have needed to mitigate, but you didn't. And at the same time you can see what you mitigated and get comfortable that it's the right thing to do. So you see here on the right hand side, there is the attack score. This is basically a distribution of score. Again, I mentioned we have a score that goes from 1 to 99 where 1 is attack and 99 is clean traffic. And, in this graph, we plot all the request and based on their score. So you can see and you can kind of like cluster, you can see clusters of good requests, like in this case, but also the bottom you'll see there is a little bit of a bump and that's all the requests that are actually malicious. You also see four different labels here, Attack, Likely attack, Likely clean, and Clean. Those are the regions of this histogram or this distribution. So you can see that the attack are all the requests between 1 and like, in this case, and 20. Right? So if you you can basically use the slider here and you can drag the slider to 20 and or click directly attack and then the view will automatically update and you'll see what's the requests that have been flagged as attack. <v Daniel Gould> Interesting. And so those four attack classes that I think is a particular interest here because this is really how business customers will benefit here. And so I think we'll see this in a rule. But, you know, reading today's blog, Enterprise customers get all of the the customization, the flexibility. They'll get details and attack scores for every single request and they'll be able to block by, you know, the ranges and they'll be able to block by particular attacks. If it's SQL injection, cross-site scripting, they get a lot of customization. However, business customers are not left out in the cold. They will be able to block or use rules, you know, based on visibility they see by these four attack classes, right? <v Daniele Molteni> Correct. So Enterprise customers, they get the score for every request so they can use the actual score for each request within a rule. For these customers, we are exposing the four classes. We're going to call them classes. So you can write a rule and we're going to show them in a second. For example, you want to block all requests that are flagged as attack. What that means is that we're blocking all requests whose score falls between the 1 and 20 range. Or they could perhaps challenge requests that are likely attacks, which means that they are they are basically challenging every request that shows a score between 21 and 50. So this is a quick way or a very easy way to separate the attacks. But I wanted to show you also something here I think is interesting. So if I reset our view, you'll see all the traffic here, you see the attack score. But here immediately after, there is another tunnel, which is the bot score, right? And that's something that customers cannot live without. And I'd love Adam to jump in and tell us a little bit more about, about the bot score. <v Adam Martinetti> Thanks so much for the setup, Daniele. So the box score is very similar to the attack score in that it's a scale from 1 to 99, where 1 is your automated traffic, your bad traffic sources, and 99 is your very likely human traffic sources, your browsers, your mobile applications, things that we're able to confidently identify and let through to your site and bot score and attack score can really work very well together. Where maybe for something that's likely an attack, maybe you don't have the confidence on its own to block likely attacks. But if you know something is likely an attack and it's also coming from a likely automated traffic source or a definitely automated traffic source, then that can give you the confidence that you need to know in order to block something. So the way that this works is that today we're our bot management runs a machine learning model at our edge, very similar to the attack score. We're scoring all traffic that we see through Cloudflare, which is around 45 million requests per second. And we're looking both at basic rules like the WAF does, that machine learning model that looks at both connection software as it comes into Cloudflare. And then what we see from that connection software, what we see from that network as it compares to the rest of the Internet and how it performs, you know, does it behave like a browser? Is it requesting the same kind of content and doing the same type of activities that we would expect a normal user to do? And then we also have a third module, which is anomaly detection. That is kind of like a site specific booster pack that looks in profiles with the average user does across your site to look for anomalies in the behavior that we see for that individual user. <v Daniel Gould> Go ahead. Finish. Please finish. <v Adam Martinetti> So the last thing that we have is also our JavaScript detection, which is where we're analyzing what the browser is itself in trying to determine the difference between something like a chrome that is being used on your desktop and something more like a headless version of Puppeteer, where someone is automating Chrome to try and appear human. So that's really the last pillar that we use for for bot detection and all of that. Bot score data is right here available in security analytics as well. And I think that, from what we've seen from what customers in the past have told us, is that most of the attacks that you see in the WAF are also going to come from automated sources because when bad actors are targeting your site and looking for vulnerabilities, they're usually not manually doing so in a browser. This is something that they're doing at scale with software in order to define these exploits. <v Daniel Gould> Interesting, interesting stuff. So as I hear you both talk, it seems like what we've done here is we've separated the visibility piece to understand what your sort of attack landscape looks like from the mitigation piece. Right? Because, historically, it seems like oftentimes, you know, WAFs have, like if you get a brand new WAF and you log in, it's totally blank. There's nothing there. And you have to begin by either writing rules, activating rule sets, etc., to then start logging or blocking things in order to get a list of security events, and then you can start looking at those, right? This feels like we've sort of flipped the script where we're providing attack visibility out of the box and then organizations can block what they need to block. Does that sound right, Daniele? <v Daniele Molteni> That's spot on. So, for example, you can also explore. You can directly explore what you want to block from the security analytics and automatically create a rule. So let me show you that. So here I have identified likely clean traffic and then I can look at, as Adam was saying, you can look at, for example, the automated portion of this likely clean traffic, right? So the like the automated, the likely clean traffic, but it's automated, it's likely something you want to block, right? These are probably bots that are just trying to, they're scanning the Internet. So this is already the filter you want to create a rule with. And here you see at the top we have a create firewall rule shortcut. So if I click here, it will automatically send to the Firewall rules view. And you see here the rule is pre-populated. So you'll see the WAF attack score is greater when the attack score is greater than 51 but less than 80 and the bot score is less than 24. Perhaps you want to block this, and so you deploy this rule straight away. So as you said, you use the analytics to familiarize with your traffic and understand what are the patterns of your traffic and perhaps what you want to block or handle in a different way. And then you straight from there you can deploy WAF rules to manage that traffic. <v Daniel Gould> Interesting. And so, I think, you know, thinking about the news today, our business customers will be able to see their security analytics and block by those for attack classes, right? They do not get the same granularity as Enterprise customers. However, they do get quite a bit. So they will be able to block, say, you know, I imagine an attack, a likely attack, and that's quite a bit. <v Daniele Molteni> Yes. So here you'll see in this rule, you'll see the WAF attack score where you can specify the actual value for these customers. The drop down will show class and then you have only four values, as you said, which is Attack, Likely attack, Likely clean and Clean. And those basically refers to ranges of score instead of the individual score. <v Daniel Gould> Really, really powerful stuff. Daniele, you know, congrats on the hard work. You know, you and Michael and Robin. <v Daniele Molteni> Yeah, I'm just filling in for her. <v Daniel Gould> Yeah, kudos to her. <v Daniele Molteni> And the engineering team, of course. <v Daniel Gould> Yeah, naturally. Naturally. And this is really powerful. Visibility into attacks that maybe are going on are unknown or unmitigated. So this is really differentiated. And you know, as we said before, it really helps organizations get to a better, stronger, more effective security posture, which is ultimately why we're here right now. Let's actually add a transition to you a little bit and, you know, a few minutes and actually, you know, talk a bit about what we're doing in another part of the application security portfolio. You know, bot management in this case Super Bot Fight Mode for our customers, actually just, you know, before we get into the news, can you refresh us like, what is Super Bot Fight Mode? <v Adam Martinetti> Yeah. Thanks so much, Dan. So Super Bot Fight Mode is our self-serve customer offering for bot management. So, this is where self-serve customers can go into the dashboard and select an action that they'd like to help mitigate bot traffic on their site. Let me go ahead, if you don't mind, and I'll bring up what it looks like for a Pro customer today. <v Daniel Gould> That was worth a thousand words, of course. <v Adam Martinetti> All right. So what you can see here is we have our Super Bot Fight Mode dashboard. Dashboard Pro customers just get access to a report that shows in the last 24 hours how much of their traffic we classified as each thing. Business customers do get access to more fine grained analytics. But then I can go over here and I can configure what I would like to do with the automated and likely automated traffic. So I can take an action, because I'm on a Pro plan right now, I only have this option for definitely automated traffic, but biz customers get access to likely automated as well. And I can choose an action of allow through or block that automated traffic or send a managed challenge. And that managed challenge should be able to block any bots that you see and also allow through any any humans where there's a potential for for false positive and a small minority of cases. So manage. <v Daniel Gould> All without CAPTCHAs, right? All without CAPTCHAs there. <v Adam Martinetti> All without CAPTCHAs, all without having to press a button to interact with this. So it's a much better experience than having to click ten pictures of boats or something like that. We also allow through all verified bots. So this is something where we want to make sure that the good bots that access your site, like a Googlebot and Bingbot are automatically categorized and allowed through. So this is the button to do that. We also give you the option to not challenge bots if you'd like, on static resources. So you might say Cloudflare does a great job acting as my CDN for resources that Cloudflare is going to serve anyway, like pictures and style sheets. Why don't, I don't need to try and challenge bots there. I can just have Cloudflare serve it no matter what. No, doesn't. Doesn't bother me either way. And then this is a new option that we announced this week as well, is we have we have an optimization in place for WordPress. Now, WordPress was kind of a sticky situation where WordPress is used by, of course, many, many different customers across the across the Internet. It's the most popular CMS, but WordPress itself will make automated requests back to itself, so it'll actually use a version of cURL to check and see if it's online, check and make sure that its layout is the way that it expects, that it's rendering properly. It will use those same requests to do things like schedule upcoming posts and things like that. So it uses its own bot in order to have like site functionality and diagnostics. And if it was just one one automated bot, that's fine. That's very easy for us to deal with. But one WordPress strength is its really great developer community, and the fact that anyone who wants to can go write their own plug in their own theme and they can they can implement that in any language that they'd like with some realistic constraints. And, so one of the challenges for us was that any time that we were trying to allow these WordPress loopback requests through, what we found was that there were always other ones that look slightly different from the ones that we wanted. So, instead of automatically allowing these through, what we what we decided as a compromise is we need we need a hint and we need to know that you're a WordPress user and that you're expecting these WordPress loopback requests. And with that information, if you toggle this in the dashboard, this gives us enough information that we want or that we need to be able to automatically identify and optimize for those loopback requests. Now, we have just a few minutes here, and I want to get to the big announcement, this is the thing that Super Bot Fight Mode customers have been asking for for a really long time. And what that is, is that in custom rules now, Super Bot Fight Mode have customers have the ability to come over here and let's say that you have an input where you do expect some automated traffic, something that you that isn't globally allowed by Cloudflare verified bot list. What you want it to be allowed through. You can go ahead and say for for this hostname, for example, what I want to do is I want to skip a portion of traffic and specifically I want to skip Super Bot Fight Mode for this API. So don't run Super Bot Fight Mode on that API. Now, Super Bot Fight Mode or custom rules aren't available for everyone today. For some customers, we're still on the old firewall rule system and we're in the process right now of rolling out custom rules to more and more customers. And so, Daniele, if you don't mind, let me throw it back over to you to give an update on where we are with that rollout. <v Daniele Molteni> Sure. As you can see here on your screen, you have two tabs for rules and custom rules. Custom rules is the newer version of firewall rules. And we are in the middle of the of the rollout. So all customers will get custom rules by default. And we are also migrating all their previous rules that are in firewalls that will be migrated in custom rules. So in the next a couple of weeks, two to three weeks, everyone should have custom rules on their dashboard. <v Adam Martinetti> Thank you so much. <v Daniel Gould> Really powerful stuff. So, Adam, back to you for a moment. So what I'm hearing is, this customization for Super Bot Fight Mode customers really will allow them to, you know, you mentioned our verified bots list, right? And they can allow good bots that we track. However, they get the ability to also allow in any, maybe sort of more, maybe less well known bots or automated traffic they need to run their business. Is that right? They can better thread that needle. <v Adam Martinetti> That's right. So while we will automatically allow bots that are good bots that are widely used across many sites, there are a lot of customers that will have automations that they have in place just for their site that no one knows about except for them. And so this is the use case here. This is what we're accommodating with Super Bot Fight Mode skip rules, and this is what's available as soon as custom rules rolls out to everyone. <v Daniel Gould> So exciting. So exciting. Again, we've got 20 seconds left. This has been a great half hour. Thanks so much for for for chatting us through these these big pieces of news that help, you know, not only, you know, when we think a lot about our Enterprise customers, but also our other customers on Business plans. So, with that, thank you once again, thanks for joining Security Week. And for the viewers, we hope to see you on another session. We'll see you soon. Bye-bye. <v Adam Martinetti> Thanks, everyone.