🔒 Security Week Product Discussion: Browser Isolation and Gateway Malware Scanning

All right. Good afternoon. Good morning. Depending on where you are in the world. My name is Patrick Donahue. Welcome back to Security Week. I am joined again by a great group of product managers and security team members. I'll let them introduce themselves and we're going to get into some questions. So why don't we start with you Malavika and then go to Tim, James and Sam can round us up. Hi, I'm Malavika Balachandran Tadeusz. I'm a product manager for the threat intelligence team, powering Cloudflare One and I'm based in London. Thanks Malavika. My name is Tim Obezuk. I'm the product manager for Cloudflare Browser Isolation. I'm an Australian based in San Francisco and excited to share what we've been working on today. James. Thanks Tim. Hi, I'm James. I'm the detection and response team here at Cloudflare based out of San Francisco. And hi, my name is Sam Rhea. I'm a director of product management here at Cloudflare based in our Lisbon office and I focus on the products that help workforces stay secure, many of which we're going to be talking about today. So excited to be here. All right, great. Thanks. Thanks for making the time everyone. So Tim, big day here. What is browser isolation, remote browser isolation? I just read the blog post again this morning, but you know, for the audience at home, can you explain what it is? Thanks Pat. Yeah, browser isolation is a tool to protect users when we're using one of our most vulnerable and often compromised pieces of software. We think of browsers as this tool that we use every day and it just sort of sits in the background around the work that we're doing. But most applications that we use in our day-to-day work and for our jobs actually rely on web browsers for SaaS applications or Google Docs, use browsers for everything. The challenge with that is browsers are one of the most targeted attack factors for phishing attacks and malware. So browser isolation is a way of keeping the same browser experience that you know and love every day, but being able to do it in a secure way by shifting the burden of executing malicious code that could be present within a web page to a nearby Cloudflare data center. Yeah, I think, you know, we all live in our browsers. I'm embarrassed to show you how many tabs I have open right now. I actually had to close some, you know, before we get started here so I can have enough CPU to run this Zoom meeting. I think remote browser isolation, you know, as a concept is not new, right? There's been attempts at doing this before. What is different or unique about the way that we're going about it? Yeah. So when we look back at the history of compartmentalizing programs to protect users from malware running within it, it goes way back to even the virtual desktop days. And when you look at virtual desktop or remote browser isolation, the technologies typically rely on either some sort of video or pixel pushing based stream or some sort of page scrubbing component. And both of these, well, sort of work, don't present a great experience. Like we mentioned, we're using web browsers all day every day. So if you had 300 Pat Donoghue tabs open on your high resolution laptop, that's a lot of very high fidelity video streams, a lot of bandwidth and not a great experience for you as a user. The good thing about video though, is it's pretty resilient from attacks since it's a completely sanitized stream. So you need a way of being able to deliver the remote browser in a way that feels like a local browser without putting the browser at risk of any of the malicious content on the web page. Now on the other side of the coin, some browser isolation products rely on scrubbing the HTML, CSS and JavaScript to prevent a malicious piece of code reaching your local device. While that can look and feel like a local browser, you can only scrub what you know to clean. So it's not a great solution for protecting the endpoint reliably from a security threat. So we've taken a very different approach for browser isolation. We wanted the benefits of a pixel perfect high resolution video stream and the security benefits of that without the compromises that can come from adding latency and bandwidth requirements to your browser as you're using it all day every day. So our approach that we've taken is to leverage one of the benefits of web pages being what we're sending over to wire and we send a vector stream of draw commands from the remote browser to the local device. Yeah, I think it's neat how everything we build here, you know, we've talked to customers a lot and they're talking to us largely for a lot of security reasons, but we don't allow that sacrifice of performance, right? And in a lot of cases, we aim to deliver additional security and performance. And so I want to dig a little bit into the way that we're doing that. I think, you know, you mentioned before, it's running on the Cloudflare network, you know, talk to me about that. Why is that important? Yeah, so every time a user interacts with their local browser, their mouse and keyboard is interacting with the web page that they're typing into. Now, on our local devices, the time between when you put a keyboard input and your computer response to it is measured in the tiniest amount of time because it's within your local device. Now, that's great for a local device, but when you're dealing with a remote browser, there's the network time for when you press a button and it heads over to a nearby Cloudflare data center and comes back. Now, historically with our services hosted in the basement of your corporate office or in a large public cloud data center, there's a latency trade off there. If it's hosted in the basement of your office, that works really well while you're in the building, but then if you're working from home, you're going to suffer from a poor experience as it takes longer for that message to travel across. The same is true for if you're connecting to a public cloud. Most public clouds have few large data centers, which work well for scaling out to enormous compute requirements. But if you want to get things really close to the user to reduce the speed of light time latency, you need a network that's close to where the users are based. So something that was extremely important for us building browser isolation is to make sure that when we are running a browser and we run full featured Chrome browsers under the hood, we want to make sure that that's running as close to the user as possible. So we run these in all of our 200 data centers around the world to keep latency so low that it's almost imperceptible. Yeah, I think I always laugh when our CTO puts the chart of the speed of light, obviously a constant over time and then our approach or our attempts to get as close to that as possible. But it makes a lot of sense from connecting and sending those commands to that data center and using any cast routing to get to one of those closest machines. But what are some of the other benefits of running the browser there? How does the data center connectivity and compute differ from what you or I might be running on our laptops? Yeah. So it's good to think about what it's like inside a data center. A data center is a very different place to our home office from the perspective of a computer. Our computers are running in all sorts of locations where the temperature can be wildly different and they don't have great CPUs or really strong connections to the Internet. Now, in the data center, it's quite different because we have big powerful computers connected to air conditioning and connected to the backbone of the Internet. So even if you're running a very computationally expensive web page, when it's running in the remote browser, we're able to run it with really high efficiency and take that performance, the effort of rendering that web page away from your device and render it in a data center. Got it. Yeah, I've definitely had some differing speed in our connections over the years and latency and whatnot. And I saw the simulation that was done. I think it was like a six megabit per second connection. And so it seems to be a big boost running with something that is close. I think the other thing I was curious about, and actually I haven't asked you this before yet or talked to you about it, but what about for sites that are using Cloudflare already? Are there benefits for the browser in terms of accessing that content? We talk about the breadth of properties that are using us. How does that kind of interplay? Yeah. So Cloudflare's content delivery network and our browser isolation network is the same network. It's the same data centers, the same machines. So when you're going to your remote browser hosted in your nearby Cloudflare data center, then you access a website that's hosted by Cloudflare, perhaps through Cloudflare pages or workers, or it's your own website that you're using us to cache content for. It doesn't need to leave the Cloudflare data center. So you've got a remote browser hosted in Cloudflare talking to the same, in many cases, the exact same metal in the same rack and getting a really fast download of that content that wouldn't be possible over an Internet connection. Yeah, I'd imagine that the bandwidth to a loopback address is probably pretty high versus going somewhere else. You mentioned vectors and network vector technology. Can you explain what that means to the audience at home? And I think we probably have some people listening that are on the engineering side as well. So feel free to go as deep as you're comfortable with that. Yeah, so our approach with network vector rendering takes advantage of a key component of how web browsers actually render the web page once it's downloaded all of the HTML, CSS, JavaScript. Typically what browsers do is they get all of the web page static content, and they execute and interpret all of that code to then decide what am I going to draw on the screen for your web page. Now what we do is we hook into that point just after we've executed all of the code. So we've done all the execution on our network. And instead of rendering to the screen, the virtual screen of our remote browsers running in the cloud, we send those exact same draw commands that are used from Google Chrome or from Chromium-based browsers over the wire to your local browser. We then run a web-based remoting client to reinterpret those draw commands. And that allows us to present a perfect representation of the page that works well regardless of whether you're on a low bandwidth Internet connection, or if you have a really high resolution modern 5K Mac. The actual amounts of data we're sending over the wire is the same, regardless of your screen resolution. Interesting. So that's kind of where the vector, I know I've used like SVG formats for images before and they can expand or shrink the image to whatever size without any sort of loss of quality. Is that kind of an analog in this case? Yes, a very close analog. Great. So talk to me about the browser itself. I think, you know, I personally use Brave, which I believe is Chromium-based. I know, you know, we've got companies that are using Microsoft Edge and customers kind of using all different technologies. How does RBI fit with that? Do you have to use specific browsers? What is available today? Yeah. So browser isolation is designed to be compatible with any modern browser. We've built our platform on top of fully functional Chromium-based browsers. So as web technologies evolve, the web pages that we're rendering and by extension the network, the vectors that we're sending over the wire remain compatible. So if next year there's a new modern version of CSS, all we need to do is update our remote browsers and you would have a consistent rendering of the Internet through your remote browser. For browsers that you're supporting, that we're supporting, you can use any modern browser. The implementation of browser isolation leverages Cloudflare for Teams. So if you're protected through Cloudflare Gateway and our roaming client, you're able to send your Internet traffic to Cloudflare for us to apply security rules on top of that traffic. And one of the policies that you can apply is actually to isolate certain traffic. So based on application groups or domain names or user identity or the threat score, which is something Marvika works on quite regularly, you're able to say based on certain traffic profiles or user identity profiles, certain Internet traffic should be allowed to pass through, it should be blocked, or it should be isolated. Interesting. I think, James, I want to throw this question to you because I think, you know, with everything that we're building at Cloudflare, we obviously are, we're our best, you know, critics, self-critical of the products we build and it makes the products better as we deploy them. How are we using this, you know, today at Cloudflare? Can you give me an example? Yeah, absolutely. So our trust and safety team, part of their job is essentially to look at malicious URLs every single day. It's what they do. And we've seen people accidentally click things, right? So using RBI technology is one of those ways that the TNS team can use to protect their devices from those accidental clicks. It just allows them to scale and leverage what they're doing with their role here at Cloudflare. Got it. And so Tim, that would use kind of the policy -based technique you described before, where you could say somebody in a particular team within an organization, you could deploy this on, for example, for more high-risk users. Exactly. Depending on the team that's using these security products, you may want different risk profiles for what people can see. A really great mechanism for phishing prevention that we have within Cloudflare for teams is to block newly registered domains. Because if someone's registering a new domain and they're sending an email to you to click on it, there's probably something going on there. Now, in the case of our trust and safety team, they, as part of their job, need to look at those newly registered domains. So while for the wider business, we would want a policy to block those domains outright until someone like James has had a chance to audit it and make a decision as to whether we as employees should be able to access that, the trust and safety team need to do that every single day. So using identity-based policies, you can be more restrictive on certain groups, certain departments, and less restrictive but still secure through browser isolation for other teams. Very interesting. One of the things that, James, that I know that we worry about, as we think about the software running on our employees' machines, is inevitably there's going to be some bug or some security vulnerability that requires that the vendor will patch it and we'll need to update the software running it. I think in a recent example, Chrome, which is widely considered the Chromium-based browsers to be extremely secure and sandboxed, there was a zero-day vulnerability in that recently. So we need to update it on our machines, but Tim, how does that work for, what does that update process look like for somebody using remote browser isolation? How do we help that process on the server side? Yeah. So zero-day vulnerabilities in web browsers happen very regularly. And when you think about how complex web browsers are, it's really not a surprise. They were originally started as these basic rendering components for documents, and now they're running full applications within a couple of decades, which is a short time span in the grand scheme of things. For patching browsers, I'm sure we've all seen the little update icon you see on the top right of your browser. And they're all quite polite and saying, please, when you're ready, you should patch your browser. But users, of course, just want to get on their email, do their job. So first thing in the morning, when they go to check their email, they're not going to be thinking to press the update button. They need to get on and do their job. With browser isolation, since we are running the browsers remotely on our edge, we are able to force out updates when we see that there's a significant risk that must be deployed. So when the next CRAN zero-day comes out, we're able to force that update across all your users. So even before they wake up, their browsers are already patched. Very cool. In my mind, we do something similar with CloudFloat workers. And so the V8 isolate engine where advancements there, either security or performance, we can handle that server side and basically get for free those patches and deploy them to our customer base at large. And so I think there's some similarities here as I think about the Chromium underlying technology that is being used here. Another topic that comes up a lot, you know, zero-days, you get asked about a lot, but is compliance, right? So in regulatory frameworks that are constantly evolving. Can you talk about, you know, your plans today or your, sorry, capabilities today and kind of plans for the future of how can remote browser isolation fit into that compliance story? How can it help companies to the frameworks that they need to? Yeah. With browser isolation, I see there being three key pillars for where browser isolation can help companies for compliance. One is with patching browsers and mitigating malware and zero-day vulnerabilities. We know we do that well with browser as it is today. What we're looking forward to introducing in browser isolation is capabilities for protecting your business against phishing attacks and data loss prevention. In the case of phishing attacks, we can control all of the interactions between the user's local browser and their remote browser. So if there's a web page, which we think is suspicious, we have an opportunity to let them see the web page, but not necessarily type in their corporate email and password into that page. In the case of data loss prevention, since we, like I said, control all of those interactions, we're able to apply controls to the remote browser to say this user shouldn't be copying and pasting information out of this sensitive SaaS application, for example. For example, if someone went on to Zendesk and wanted to download the list of customers, for example, we could prevent people from copying or printing that information out of the remote browser. That makes a lot of sense, and I think stay tuned for some data loss announcements later this week. But I think there's a lot of interplay in my mind between what we're doing here and protecting that with some of the other stuff that we're getting ready to announce. So, James, one of the things you mentioned in your post, which also went out today, and we'll get to that in a second, was the concept of drive-by downloads and malvertising and things like that. One, can you just describe what those threats are and how does remote browser isolation help with those threats? Sure, absolutely. So malvertising is a lot of times attackers will leverage these ad networks to inject malicious scripts that can be used to spread malware at mass. You imagine a lot of times when you're going to a website, all these scripts are loading in the background. It's pretty transparent to the user, but you never know what you're getting in there. And so attackers know this, and so they can leverage these ads to distribute malware. And so a lot of times what I've seen in the past is like, and this is kind of earlier in the days too with exploit kits, a user goes to a compromised website accidentally or through an ad and they get redirected through a chain of websites that ultimately download something from their browser without them actually interacting with that. And so RBI helps by isolating that, right? So like a user can accidentally be served a malicious ad, but it's all isolated from the end point. So it's not going to actually download anything to their machine. Yeah, there's nothing more frustrating when you click on something and see your browser address bar changing and then inevitably you come up and I'm just like XXX trying to get out of it. Absolutely. So what is the danger with that, right? So if something is running locally, like why does that matter? What permissions is the browser running with? How does that actually affect the integrity of the machine? Yeah, well, we were just talking right about exploits and vulnerabilities. And so if an attacker can leverage a vulnerability in a browser to run something at a higher permission on your endpoint, they can essentially compromise it. So that's the scary part. And I think a lot of times people that are browsing their websites, a lot of times they'll get something downloaded if they don't realize. And it could be malware, it could be backdoor, it could be something that can allow somebody now to access your endpoint. Yeah, and I think we talked in the past and we had a week around this on Zero Trust. And so I think the fear in my mind is if you're downloading something and you're running it locally, if you're trusting the IP address of the browser or the machine that's running on, potentially that could be used to leverage. I've seen JavaScript run and it's trying to scan local addresses and send some of that stuff back. And so I think it's important to stop that in the tracks if possible. Absolutely. Cool. So Tim, before we switch gears a little bit, who can use RBI today? When is it available? What can people do to learn more about it? Yeah, so we've made browser isolation available as part of Cloudflare for Teams as an add on to the gateway component of Cloudflare for Teams. So anyone who is using Cloudflare for Teams or has a subscription for it is able to use it today. You can start with as low as one user and expand up to as many users as you'd like. Great. That was going to be my next question. My one person LLC, can I sign up and get going with it? Yes. All right. I may hit you up for a discount. So thanks. Thanks for the context. Terrific. Let's switch gears a little bit. So we had another big announcement today with respect to gateway. Sam and Malvika, I want to talk to you about the specific announcement. But before we jump into that, I'd like to just kind of get an understanding of what gateway is for those that aren't familiar with it. And then we can talk about what was added to it. So Sam, maybe you can provide some context there for me. I'll walk through what gateway is and what's really fun about teeing up gateway is that it leads into all of the work that Malvika's group has been doing on the data that powers gateway. Because you'll see here in a second, gateway is only as good as the data that we have. And the team's been doing a lot of interesting research there. But Cloudflare gateway starts by turning Cloudflare's network in the other direction that most customers think of Cloudflare's network. So a lot of the use cases in Cloudflare's product set, think of Cloudflare's edge, our network, our data centers around the world as defensive security from outside threats that are attacking your infrastructure. And that's really powerful. It also improves the performance of that infrastructure, whether that's a web application, an e -commerce site, or just your own blog. With Cloudflare gateway, what we're thinking about are the types of threats that exist when you're going in the other direction, when you have a corporate laptop or a corporate device, and your users are just browsing the Internet. We built Cloudflare gateway because we kept talking to customers who their entire security world changed as users both left the office, but long before that, as all of the data and the applications and the things that they needed to do their jobs shifted to the Internet. Suddenly you had thousands or tens of thousands of your employees, your entire workforce, spending the vast majority of their day on the Internet. Like y'all mentioned that hundreds of tabs that might be open because the Internet became where they were doing their work. And that's powerful and it's great and it's opened up a lot of possibility, but it's also terrifying. Because if you think about the Internet and the design of the Internet as this globally available network where anyone can connect and anyone can serve traffic, that design that makes it so powerful and so flexible is also a huge potential vector for everything that James' team and the entire security industry works to prevent. That's this idea that I can compromise some flow that you're using on the Internet to deliver malware, to steal data, to phish you and then impersonate you. And so as suddenly you have all of these employees using workforce tools that require them to be on the Internet all day, the only answer to that was, well, we're going to have to backhaul all of that traffic to a physical box somewhere in headquarters, where we're going to go ahead and secure it for them. Which of course is slow and painful if you're an end user, all of my traffic is going through a central location. And it's also really difficult as a security team. That box has some scale problems. It has maintainability issues. You have to upgrade it. You have to think about what happens if someone literally unplugs it or there's some interruption to that service. Do I take down the entire Internet for all my employees? So at Cloudflare Gateway, we're using Cloudflare's network to instead allow any user, wherever they are, whether they're in an office or like all of us right now at home, to connect not to some central appliance in headquarters back in San Francisco or some other central location, but to connect to the nearest Cloudflare data center. For me, that's the Lisbon data center just down the street here. And where all of the security policies can be applied that would protect me from those threats on the Internet. Things like blocking phishing attacks or looking for the host name in a DNS query that might map to something we know to be a threat. That extends now to HTTP filtering as well. So not just DNS filtering, but actually looking inside of the traffic and seeing, hey, is this user attempting to upload a file to a suspicious location? Do we want to block that? Or is there virus in the file that they're downloading? And do we need to block that as well? So it's a really powerful way to let employees and your entire workforce use the Internet and benefit from all the great tools out there, while also getting the performance of Cloudflare and Cloudflare's network with all the security policies. Not just the same security policies that your current appliances might offer, but security policies informed by the data that Cloudflare has about the Internet, which is what Malvika's team is focused on. Thanks, Sam. That was really helpful for you. I don't know if I want to get to the data in a second, but I think one thing you said that really jumped out at me based on conversations that, you know, and I focus on that kind of inbound threat side, right? To contrast with your focus. And one of the things that I had heard just on calls with customers talking about, you know, some of the stuff that we could help them with was, hey, we're now all working from home and we're tunneling back through these VPNs. And the VPNs are just like overwhelmed, right? And they're overloaded and they couldn't get on Zoom calls. They couldn't get a whole bunch of things because they had these like centralized choke points, literally, that had, you know, very limited capacity. And Evan actually mentioned, James, on the security team yesterday, where back in the Cloudflare office where in San Francisco, if you didn't get in early enough, you know, you would like get some license count in the midst of us hiring a bunch of people and growing that. And so presumably, Sam, with Gateway, what's involved when you need to scale? Like how do you scale up your org? You all of a sudden acquire a company. Like what do you need to do to get more capacity? Who clicks in the Cloudflare for Teams dashboard? That's something that, and we see that use case exactly that you're describing, where if you've acquired a company or merged with another company, what used to take literally months of hardware provisioning or deduplication of appliances that both of the organizations might have, can now just take a matter of minutes, less than five minutes, using this platform because any customer who uses this platform has all of the scale of Cloudflare's network. And that's the same network and the same hardware that powers all of the reverse proxy-based services for some of the largest properties on the Internet. Yeah, I was going to ask where this stuff runs, but I think the answer is pretty clear on the same machine, same data centers that everything else runs. And, you know, I think Sam, you and I have talked about just the advantage that gives us from a velocity perspective. I think, you know, your team in particular, dizzying amount of features that are coming out. Similar to Anika, when I spoke to you yesterday about Magic WAN, you also, we get these great emails of the long list of features that you're shipping. And I would imagine, you know, shipping on that same network, using a lot of the products that we build ourselves. I think, you know, one example recently that was really cool was Project Fairshot, right? So we were able to, you know, these sites where people are going to register for the COVID vaccine were just getting knocked over. There was just this herd of people trying to get to them. And this was all legitimate traffic, right? This was not a DDoS attack, which, you know, which I focus on. This was real use cases where people couldn't get and register the vaccines. One of the things I thought was fascinating was that we were able to build that waiting room style technology to help people register. The reason we were able to build it so fast was we were leveraging the developer platform that we built at Cloudflare, right? And so I know your teams are using similar technologies. In this case, it was durable objects, right? This consistent store that can be leveraged by workers. And so pretty cool to see that velocity on this stuff as well. So you mentioned DNS and file filtering. Can you explain, you know, how do those actually, you know, hook in and trigger? So what is, you know, how does DNS play a role here if somebody's on a browser and they're going to some website? This is an interview question I'll ask sometimes, but like, how does DNS factor in here and how does it hook into Gateway? Well, I hope I get the offer at the end of this interview, but so I'm going to do my best here. We really think about Gateway and all of Cloudflare for teams as defense in depth. And kind of this winds up into what Tim was talking about earlier with browser isolation. But at the very beginning with offering customers a DNS filtering option. And what this means for users is when they want to go to a website on the Internet, they use a DNS resolver. For a lot of people, it's their ISPs resolver. Some might use popular consumer resolvers like Cloudflare's 1.1.1.1. But for an enterprise, if you have control over the devices in your fleet, whether that's with an MDM or you manually provision and manage them, you can change the DNS resolver settings of that device to instead point to something that we provide you in Cloudflare Gateway. And when you point it to what we provide in Cloudflare Gateway, whether that's an IP address that we make available, or if you have a device that's roaming and outside of the office and you want to use a roaming agent such that all DNS queries, no matter what network it's on, are sent to our service, no matter how you want to deploy that, when a user wants to go to a host name and says, hey, I want to go to www.donohue.com, and no endorsement of that website, I'm not sure. You're asking a DNS resolver on the Internet, hey, do you know where this website is? Do you know how I can find it? What is effectively the end state, the IP of it so I can make a connection? And we use that position with Cloudflare Gateway to add a layer of security determination, where if you're requesting this website and we as the DNS resolver see that request come in, we're going to check our list and say, hey, wait a second, is this a phishing site? Is this something that was just registered and looks suspicious? Or maybe it's not just security threats, maybe you have rules in your organization that users can't go to Twitter. I know all of us would be a lot more productive if we were able to turn off Twitter for a few days. We're going to check our list at the edge of Cloudflare's network to determine whether or not you should be allowed to resolve that host name. In which case, if you are, we're just going to send you back the IP to get you on to your destination. If you're not, we're going to show an error page and explain in some cases that, hey, you're not allowed to reach this for a given reason. And what's really powerful about that is two things in particular. And to your point about building on Cloudflare, it just feels like a cheat code. Because the first is Cloudflare runs the world's fastest DNS resolver, 1.1.1.1. And that is a extremely privacy-centric DNS resolver in addition to being performance-oriented. We get audited to make sure we are following our commitment to appropriately treat and delete and get rid of the records of that resolver while still delivering the world's fastest DNS resolver. With Cloudflare Gateway, it builds on the same technology, the same performance benefits, the same ability to run all of our data centers. But it adds that security filtering that I was mentioning. And that security filtering feeds into the second cheat code about the DNS filtering part of Cloudflare Gateway. Because what I described earlier, you have a request coming in, and then you have to go check a list to see, based on your account, if that request matches the list and needs to be blocked or not. That's a hard problem. That's a hard problem to do in 200 cities around the world. But thankfully, because of other teams at Cloudflare, a version of that has been solved. Things like our WAF for the last decade has been thinking about a query that's coming, a request that's coming into your infrastructure and data centers around the world. And without slowing it down, checking that does this meet one of the rules that maybe you have about your page or your application that you've secured behind Cloudflare. So we were able to build on that platform to, again, have this benefit to our customers that they should not have to trade off performance or security. And then the HTTP filtering flow, this next layer in that defense-in -depth strategy that leads up to the browser isolation piece, is, again, built on something that we've been able to battle test at scale. Cloudflare offers a consumer mobile application that we call Warp, which for users around the Internet, much like 1.1.1.1 as a DNS resolver, users around the Internet use Warp for a faster, safer Internet experience. What it does is it takes all the traffic that's leaving my device, uses a wire guard tunnel, which is very secure and also battery life and performance-friendly secure tunnel from the device to the nearest Cloudflare data center. So all my traffic is traversing this encrypted tunnel to Cloudflare data center and then onto the rest of the Internet. In some cases, and Tim mentioned this earlier, that might be a site that's already on Cloudflare's network, so you're not actually leaving that data center, but in other cases, it's going to the rest of the Internet. We've had that in the market and available to consumers at no cost, a no-cost version and a paid version for the last several years. And our HTTP filtering flow builds on that experience because we've been able to see, hey, certain websites run into issues with this type of forward proxy approach or certain carrier networks have strange implementations of IPv6 that we need to be aware of. So we're able to test that at scale before now offering an enterprise version where we're using that tunnel once enterprises enroll their devices to inspect the traffic and look for threats inside of that connection, things that might hide beyond just a DNS query, which is really exciting for the things that it means from data loss prevention to browser isolation to file type control and virus scanning. That was really helpful and informative. Thanks, Sam. I want to get to the file inspection stuff in a second, but I want to talk to James a bit about like, how are we using this gateway product today at Cloudflare? I know I run a client-side firewall, a little snitch. And so every outbound connection for my machine, I have to authorize. And at one point, I remember seeing it change the DNS server it was calling out to from 1.1.1.1, I always say 3 instead of 4, to a different Cloudflare IP address for DNS resolution. Talk to me about that. How are we using this? And how is that different, that setup versus the default consumer-focused DNS server? Yeah, so before everybody started going into the remote environment, we used to go to the office and we'd bring our laptops, connect to our network there, and then we'd access, you know, get our resolver addresses that way. But as soon as everybody started going remote last year, we created a separate policy for remote employees. So this allowed us to maintain our users still protected with a gateway, even though they were no longer working out of the office. So today, the security team, we actually use it a lot for performing investigations, blocking, especially malicious domains. A lot of times, you know, we're the first line of, you know, we receive all the alerts that come in from Cloudflare. We do the initial triage. And so when we see something that's malicious, gateway is a place where we go right away, block to make sure that nobody else has, you know, that visits it or use it as a tool to also investigate if anybody did visit it. Great. And so I want to get to the announcement today. And so this is probably a question for you. And then Malavika, I want to talk about some of the threat intelligence behind this. But how do we actually, like, inspect content? So I understand that my machine is talking to, you know, DNS server. And previously that was handed out by DHCP, maybe if we were on the LAN, and now it's pushed out, you know, through some other control mechanism. But what about that outbound browsing experience? Like, how do we – and talk to me about, like, what the announcement is today from a malware inspection capability. So, one, how do we do it? And then what are we actually doing? Yeah. So it all starts with PKI, which I think you'll smile about because most things that we do begin there and making sure it's being handled appropriately. When you're visiting a website, that website, if it's using HTTPS, it will, in most browsers, show Greenview that, hey, this is an encrypted connection. You know, you're not being spoofed that what you're visiting, Google .com, for example, is someone attempting to impersonate Google.com. So in this inspection flow, it begins by putting a certificate that we issue on the client device because in this case, we are, in essence, spoofing Google.com. We're not attempting to impersonate them, but we are terminating the connection between the corporate device and its destination on the Internet. And by putting that certificate on the device, we're able to do so without causing errors in the browser to appear because that certificate that lives on the device tells the device that when Cloudflare's inspection sits in the middle, you can go ahead and trust it and it's okay to proceed. And so once that's in place and we're able to inspect that traffic, a lot of times it's just HTTP requests and responses and things that we're able to inspect and apply rules on. But earlier today, we announced virus scanning, which is really interesting, both because it's a powerful feature, but also it's a kind of fascinating problem in how we handle the inspection that's done at the edge of our network. Because some traditional approaches to this, because as you're inspecting a file and you're looking for viruses, you need to try to guess at, you know, maybe how big is this file? Am I checking it when it's starting the upload? Am I checking it when it's done with the download? At what point am I determining that this is a file, for example? And because of the complexity of that, it's done in these legacy approaches in a centralized appliance that part of that backhaul journey that we were talking about where people are willing to trade off or suffer through the slower performance in exchange for this comprehensive type of file inspection. But we've been able to, using Cloudflare's network and the proxy, the gateway proxy that sits at our edge, do something that performs this scanning in line. So we're not adding kind of additional complexity. We're not adding additional processes. We perform this scanning of the file in line because we're able to determine that, hey, based on a set of criteria, whether it's the MIME type or you name it, this looks like a file, and we're going to begin to scan this file to determine if it matches known signatures of attack. Does this look like a virus? Does this look like malware? And we're scanning that file, and before we allow it to upload or download, we're making a decision about whether or not it should be able to proceed. And when it appears that that file has been fully scanned and we're able to draw that conclusion based on some logical ceilings, we then allow you to download the file or upload the file. So it's a really powerful way that we're taking Cloudflare's network, and one of the things that's kind of our bread and butter is the ability to handle traffic at scale and make determinations like in our WAF about does this meet a certain criteria or not, and to apply that to files moving along the wire as well, check the files against known signatures and known patterns, make a determination about what to block or what to allow, all without slowing down the user. One of the things I'm excited about is, and I think as we bring in different data sources and develop them ourselves and using those for other parts of our stack and our offering, and so the same way that we can scan files for malware from the user side, imagine you're a site that allows user content to be uploaded, and you don't want to serve that back to your visitors or back to the eyeballs. And so I'm excited to work and integrate this into our web application firewall as well to strip that stuff out. Malavika, we've talked a lot about protecting stuff before it happens, right? Obviously, sometimes things are going to get through. Maybe you haven't deployed the file inspection yet, and there's some potential compromise. There's a term in security called assume breach. What does that mean to you, and how does this actually help us from an after-the-fact detection capabilities? What can Gateway do there, and how does that actually work? Of course. So I think actually maybe it's worth taking a step back to what Sam talked about because I think the idea of assume breach is kind of tied to this idea of a layered approach, right? Like you start with DNS filtering. If I think of a funnel, first you want to filter out what are clearly malicious host names that you know, but the reality is you don't always know everything that's malicious. Let's take an example of malware in Google Drive. Google Drive, you don't want to block Google Drive at DNS, and so then you're going to probably let that go through, and then maybe you look at the URL, you think it's fine, but this is where AV is a super useful layer of defense. You might scan the file and you discover it's malware, and then you block it there kind of at that layer. But the reality is you can't always stop malware from being downloaded. Sometimes malware isn't downloaded, and this is where I think again the idea of a layered approach. I think today now with things like backdoors and sophisticated supply chain attacks, people are trying to not just find a way of downloading malware onto the endpoint, but compromising the software itself that corporations are using, and then being able to compromise many corporations. And so I think in a world where networks are increasingly complex and increasingly sophisticated, you're relying on thousands of either on -premise or SaaS software that you're piecing together to become your corporate network, the reality is some of them, if not many of them, might be compromised in different ways. And so I think taking that layered approach to security, assuming that parts of it might be breached, not all of it can be trustworthy, but that's okay, that's inevitable, and that's why we have a layered approach. And I think kind of beyond that then is thinking about, okay, how do I quickly detect a malicious activity on my network? Because if in fact my defenses weren't enough, if browser isolation wasn't able to catch it, AV wasn't able to catch it, all of the pieces of gateway, then how can I quickly identify it, at least triage the issue, and then kind of quickly respond? And I think this is where post-compromise detections are really important, whether that's identifying kind of C2 servers or command and control servers. These are kind of the brain centers of malicious activity on the Internet, where particularly around DNS as a protocol, it's often abused, I think, and you often leverage it because if you know what a DNS query is, you're effectively able to send a string of letters and then receive perhaps an arbitrary set of numbers or a string of letters back, and actually it's quite simple and was designed to allow people to identify resources across the public Internet, but actually can often be abused in both directions, to send data encoded in the DNS query itself, or kind of in response, you might end up with malware in the response that's also been encoded and then can compromise your device, and those communications will happen with what we call the command and control server. And so being able to leverage some of gateway's additional protections, like DNS tunneling detection, which looks at the DNS queries that your organization has made to identify what looks, you know, kind of looking across DNS queries made to a specific domain, looking at the entropy of the queries, the kinds of queries, the frequency of the queries to say like, okay, that set of queries looks malicious, doesn't look like how DNS should be used. We think someone is abusing that to send data either to or from kind of a C2 server and think that might be malicious. And then, you know, another way we also kind of detect malicious activity, which could be signs of compromise are through what we call domain generation algorithms. They're commonly used by malware to then, again, to perform these activities. And so once again, even maybe the malware has gotten on the device, but can we really quickly identify moments at which, you know, or signs of malicious activity using machine learning? Very neat. And when you start talking about tunneling stuff over DNS, I had some flashbacks to when I was younger, you know, being on a plane and having DNS access, but not necessarily paying for Internet yet and tunneling IP over DNS. And so there's a lot of stuff that can be kind of, you know, smuggled in those queries. And I think it's important to be able to detect that. You know, we looked at SolarWinds, for example, and you kind of touched on that, not necessarily by name, but by, you know, relying on third parties. How does logs, how do logs factor in here? Like I know that we did some analysis to help customers from an indication of compromise, you know, looking up the domain generation algorithms and the resulting host names that were queried. But, you know, what role do logs play here with respect to gateway and your ability to kind of sift through that intelligence? Yeah. I mean, I think maybe actually try and unpack your question a little bit more. Do you mean like the customer specific logs or the scale of kind of logs across all of Cloudflare? Yeah. So if you're using, if you're deploying gateway, for example, and, you know, presumably Sam can fill us in here in terms of like how much additional logging that you're getting, you know, for an organization. But if James is managing gateway for Cloudflare, we're able to look, you know, was a machine compromised and going and accessing some site or doing some DNS query on some site. I know like with SolarWinds, that was one of the ways that these machines were calling out, right? They weren't just calling to specific or just unique host names. They were calling to a whole bunch of different host names, right? And were you able to look kind of through logs to help figure that out? Yeah. I think what's really interesting, and SolarWinds is an attack where a lot of different security companies have contributed research. And so it's one, and we did as well. And so it's one we can kind of talk quite freely about. What's interesting about SolarWinds is if you look at one of the first domains that was most commonly used was actually something called avscloud.com. And then the subdomains of AVS Cloud looked like they were kind of randomly generated, but actually had encoded every kind of company that had been compromised. The machine name of the company was then encoded and then appended to avscloud.com and then sent to the server and thousands of organizations around the world. And we saw that across our network using kind of 1.1 .1.1. We were able to see all of the companies that had been compromised. So that was like, I think, a specific example of one attack, which if you think about, like, I actually think that looking back at those DNS queries, nine months went by before people realized that they were malicious because they, you know, if you saw DGAs to what looked like a legitimate cloud provider, you'd probably allow list those queries. You wouldn't think anything of it. You make requests that look very similar to AWS and other cloud hosting providers all the time. But then this is kind of, I think, where log data becomes really useful, both where when you do then realize that you've been compromised and that this activity has happened on your network, then being able to go through all of the data that you do have. I mean, if you're not deploying something like Gateway, you might not know what DNS queries have been made on your network to begin with. And if you're thinking about in the world of remote work, like tracking all of the queries that have been made across every machine can actually be quite a non-trivial effort. And so then with something like the logs, we can then very quickly identify, here are the organizations that have been affected and then work with the customers and notify them. Or they can set alerts themselves to identify when activity like that happens. Yeah, I think that's important. And I think the distinction here is if you're deploying Gateway with your own DNS environment, then you have extended logs that we can help you analyze if you're looking for those indication of compromises versus if you're using something that's more public, especially ours, 1.1.1.1, which has very strong privacy guarantees. We're not able to do that sort of thing for you. It has to be your own Gateway deployment. And so I think the detection of these in the SolarWinds case, I'm not sure what the ultimate goals were. It probably differed by company that got compromised, right? Whether it was data exfiltration or some pivot to some other attack. I think the area I want to go into is what James wrote about this morning in terms of there's some compromise of a network and they're actually using it for a very different purpose, right? And James, your post was fascinating about ransomware and how these attacks could be leveraged for monetary gain, right? And so for those that aren't familiar with the term, can you tell the audience at home what is ransomware and what are those attacks typically look like? Yeah, absolutely. So ransomware is just like malicious software that essentially when it gets on your endpoint, it'll start encrypting files. Sometimes it can even corrupt data. But most of the times attackers are leveraging these to essentially hold your files hostage. And then they ask for ransom in exchange for the keys that'll decrypt it. It's interesting because just to go a little bit back when I first got started in my career early on, when ransomware started becoming a thing, I remember being asked to write about it and I didn't think it was going to be something that was going to blow up. I wasn't really interested. And so it's just interesting today how it's evolved over the many years now and becoming something that's a lot more targeted. We see attacks really going after industries, specifically healthcare being one of the highest. When you think about why, their priority is always going to be providing healthcare. And so when you're in a situation where you have systems that are locked down and could potentially bring down operations, a lot of times attackers know that you're going to choose taking care of your patients first before paying them. They know that that's going to be your priority is healthcare. So it's just interesting to see how things have evolved. Yeah, that is actually a fascinating angle that it's healthcare in particular. There's some dynamic there where somebody is compromising that work. And I think in your post, you talked about files that got encrypted and a key would be held and only decrypted if somebody was paying it. And so you're sort of forcing the victim to make a choice there. And it's interesting that healthcare comes up frequently. What other industries are you seeing this in, or have you seen this in? Yeah, in my past roles, I used to work a lot on the consulting side. So I used to see a lot of these cases come up frequently. And a lot of them were healthcare, legal, education, manufacturing. So it seems to really be all over the place, but the highest definitely has definitely been healthcare. And I think I wanted to add one more point on the ransom. So ransomware, we talked about, it's like being something that can run on the endpoint, but there are other ways to extort people for money. And so one of those other ways is, I think we recently blogged about this and I linked to it in my blog post, using DDoS threats as a way to also extort companies. Essentially what that means is they'll just reach out and say that, they can bring down their entire site if they don't pay, and they can start sending warnings and start DDoSing slowly, just so that they can get the customer or the person to give them some money in order for them to stop. And so this is another opportunity to highlight how important DDoS mitigation is also for your websites. Yeah, we had quite a few of those I was involved in when that started happening last fall. And I think the key there is being able to deploy something quickly to put a layer up and to protect it and fend off the attacks or actually even just dissuade the hacker based on the defenses that are now in place. And so that was a fun period of time and still continues to this day. I mean, we still see it, but for a while it was just incredibly frequent. So what are the ways that people get in? Is there anything, any common threads or initial attack factors that you're seeing for people to kind of get in and gain a foothold into the networks? Yeah. The top three that I consistently saw was RDP exposed to the Internet. A lot of times these are not even attacks that are always really, really targeted. They could just start easily by scanning the Internet for open exposed RDP servers. And these are the remote desktop systems are just open waiting for somebody to connect. The other ways are through vulnerability on a web application or some server that's just exposed to the Internet. And then lastly, phishing emails, right? That's just been like the common way, always with the user delivering some email to a specific group of people or in mass and just seeing who downloads something to run it. So these are always the top three ways that I've seen attackers get in. I know we announced some protections for RDP with access. And so it's something, you know, any sort of brute forcing or credential stuffing, you know, we see it all over the place and we're going to have some, some announcements on that, I think actually next week. And so it's not, it's not security week plus. And so, or fortnight, I think as, as our CEO called it on Twitter. So what about the, what happens when somebody gets in? Like, what do they do at that point? What is their next step? Yeah. So once they get in, you know, a lot of times they don't know how the environment looks. So they'll start looking to see what other systems are in the environment that I can go after in the targeted cases that I've worked on in the past. A lot of times they're looking for backup servers, high critical systems like domain controllers, things that can really bring down operations as well as customer or sensitive data rather. So a lot of times these attacks start as the end goal is ransomware deployment, but also they take data with them and they use that as a way to, you know, say like, if you don't pay for, for this, we're also going to release this. And it just creates this situation where it goes from something like a simple ransomware deployment to much larger network intrusion. Yeah. That is scary to me that the whole backup server, I think in your post, there was something about the, that was the, there weren't backups in this particular case, right. And that was the only source of the data. So they really had to deal with the attacker in that case. What, what I guess are some recommendations that you have for somebody that is facing an attack like this? Yeah. So, you know, we talked about this particular case with the backups, right. Having multiple redundant backups, both on-site and off-site, definitely leveraging two-factor everywhere. And this is, you know, Sam could probably speak to this, but with like Cloudflare access, right. And the features there to protect RDP, just being something that's exposed and just yesterday with product announcements and having a magic firewall, right. Like a lot of times like attackers are looking to move laterally. So being able to control what assets they can get behind on the network once they're already inside that's very powerful. And so being able to segment them from being able to access these critical systems is also very, very important. Terrific. I think we're just at the end of time. So I want to thank everyone for joining and really appreciate your insights and we'll hear more from, from everyone soon. Thanks.