🚚 Magic WAN + Browser Isolation

Welcome back to Cloudflare TV and to GA Week. As mentioned prior, I hope everyone has enjoyed all the exciting announcements that's been going on this week. Again, early in the week, lots more to come. We've shared lots of exciting things. In this segment, we're going to share two more exciting things within our Zero Trust Week that are getting even better by working together. I'll be your host today. My name is Corey Mahan, and I work on our Zero Trust products here at Cloudflare. And I'm joined today by Tim Obezuk, our product manager for remote browser isolation. Hi, everyone. Thanks, Corey. I'm excited to be here. Awesome. So today we announced support for browser isolation with our WAN as a service solution or Magic WAN. And we're excited to share more about how these two already great products that work independently now work better together, working more closely together through integrations. And we're going to dive into that solution. But before we do that, I kind of wanted to have Tim help me kind of lay out the problem that most organizations are facing today when it comes to integrating and getting the odd rates to browser isolation in their perhaps legacy network architectures. So kind of to kick things off, Tim, do you mind giving us an overview of the challenges teams are facing today? Yeah, absolutely. So we've had our Zero Trust platform and browser isolation for some time now. And we've had many customers integrating it into their security solutions by deploying a roaming client or redirecting from existing secure web gateways with our clientless option. But what we found talking to a number of customers is businesses which already have existing security appliances that have grown organically over a long period of time and took a network with networks, with boxes, with firewalls and DNS filters, HTTP filters, DLP, CASB, all these different appliances working together run into the challenge where they want to maintain their existing investment but still defend against emerging security threats like browser isolation. And what we wanted to do with our update today is make it easier to integrate browser isolation into legacy networks through the integration with our WAN as a service magic WAN product. Yeah. Does it make sense, Corey and everyone? Totally. Yeah. So in kind of doing that, when you say integrate with kind of the on-ramps too, maybe talk a little bit about that on when you say kind of the defending against threats and getting people onto browser. What do you mean by that? Yes. So Cloudflare's security solution for defending networks is built as an all-in -one global cloud that leverages our global network of 270 something data centers around the world. And we've built all the different layers of network security into this fabric. With on-ramps, when we say an on-ramp, what we mean is a way of getting traffic from your end users or your network into Cloudflare's network. And for end users, working from home users, this often just means a roaming client on the device to steer traffic to the closest Cloudflare port for filtering inspection and security. If you're running a larger network or you have multiple sites, you would want to look further towards the network stack for how you connect into Cloudflare's network. And where Magic WAN comes in is it enables you to perform low -level network connections to Cloudflare's edge. This could be over a IPSec tunnel, a GRE connection, or even plugging a cable directly from your data center into Cloudflare's POP and connecting over a trans-OPNI style route. Awesome. So the problems of getting the traffic on it sounds like is kind of where we are. And it sounds like with kind of the Magic WAN solution and browser now working better together, we can solve that and make it easier for our customers. So the problem is very clear that it can be hard to do, or maybe you want to keep some of the existing investments that you've made. Before we jump into kind of the exact solution, can you give us a little bit more of an overview of Magic WAN? Yeah. So Magic WAN essentially allows you to, once you connect your data center or your network to Cloudflare's network, you're able to apply a range of different security solutions on top of your traffic. This could mean just generic network-level firewalls. So if you historically had hardware appliances deployed at different sites, you could actually take all of the on-premise appliances and just have a dumb tunnel to Cloudflare's network and implement all of those security functions at our edge. And then as you get further up the stack of defending against more sophisticated attacks, maybe it's a DNS layers HTTP, or even inside the web browser, which we'll go into more detail soon, you're able to just enable those functions without actually needing to buy new appliances or deploy virtual appliances and wire all these together. They're already integrated into our network. Got it. So it is the on-ramp, if you will, for all of the things, kind of no matter what you're using, whether that be all the variety of Zero Trust services and other Cloudflare services as well. Can you talk to me a little bit about the administrative bit of this? Like what do administrators need to worry about? And then I want to go into RBI or browser specifically, and then we kind of label in in a magical way in the world. Yeah. So for administrators, building out a network is a lot more than just installing an appliance. Depending on the scope and the size of your network, you may need to deploy multiple instances of the same appliance to ensure that latency is low for users that have a performance experience in traffic. It's not tromboning. So for the administrators, deferring that workload to Cloudflare's network introduces a reduced cost for one by having a single solution rather than multiple instances and redundant hardware. It's easier to manage since you have a central pane of glass for controlling all of your networks. And it just has one contiguous network or even more granular depending on how you configure the platform. And it's much easier to integrate since you don't need high -powered and you don't need to right-size your boxes depending on the size of the network you're connecting to. It just needs to get to Cloudflare's edge when we manage the rest of it. Got it. So that was kind of the problem, a little bit about magic way in there. And then the other piece of this story is browser isolation, something that's near and dear to your heart as the product manager for the solution. Can you give us the RBI 101 as well, just kind of what problems is it solving? And then we'll kind of talk about the two together. Yeah, absolutely. So browsers are incredibly interesting pieces of software. When you think about what a browser was originally meant to do, it was originally an application to receive documents in an academic setting and it's just for reading documents, really. However, over time, they became more sophisticated and you've had technologies like JavaScript to be added. And when you fast forward all the way to today, they're incredibly sophisticated pieces of software that can perform, that can interact with GPUs, they can interact with USB, Bluetooth, your webcam microphone. And with that comes a lot of risk for both the security of the code that's running inside the browser and also any data that is inside it. As browsers have become more sophisticated, so have SaaS applications. And now people are relying on browsers for the vast majority of their business applications today. And I think if you were to go back in time and say, we want to install a piece of software on our workstations that can download untrusted code from any server on the planet and then execute it, that would be a security manager's worst nightmare. And it's a risk we are currently tolerating every day, which is just unnecessary. And the remote browser can reduce your attack service significantly by isolating the execution of website code into a remote browser hosted at CloudFlows Edge. Awesome. So you touched on it there at the end, the hosted at the edge. So this isn't something that you install or download or have to run and there's no agent per se for the browser itself? Yeah, absolutely. So what happens is when Magic WAN and browser isolation are configured, CloudFlow is able to filter and inspect and secure any instant traffic within that network. One of the actions we can perform is to isolate traffic. And what happens when traffic is isolated is rather than serving the original HTML that would have been served if it was a traditional secure web gateway, we intercept that and steer it to the remote browser. The remote browser serves to your local browser, this lightweight HTML5 shell. And with that, it's able to connect directly to the remote browser in any web browser a user would typically choose to use any day, like Safari or Brave or Firefox, whatever their preferred browser is. And it will connect to the website transparently just as if it was any other website. Now, what's really interesting is how the technology actually works. Browser isolation products have historically worked with two main models. One is either to scrub the website for malicious code and send it through. This comes with two main risks. One is compatibility. It can often break websites and lead to a fragile and unreliable experience for users. And two, if there's an emerging threat or a zero day that isn't removed from the DOM scrubbing solution, it could potentially land on an end user's device and be a very bad day. The other approach is a pixel pushing style solution. So this is similar to basically just pointing a virtual camera at the web browser and streaming pixels to the end user. But this lead, this solves some of the compatibility and security issues that DOM scrubbing had. But there's a huge trade-off there for the end user experience and performance because we use browsers all day. We're all using very high resolution screens and having such a high resolution image stream to users is very heavy on bandwidth. And even trying to downsample it leads to a low quality experience for users. Got it. So the two together there, so we're able to on-ramp or add that traffic using MagicWay into browser isolation. We're able to do some really cool things. Could you talk on a little bit more into, great, where we've isolated this site or these sites or all traffic, let's say, for this user or these sets of users because we can configure all that. What are the things that you can stop? And I'm thinking about this from like, great, like kind of the risk prevention, a malicious code being run on this site, but what about other means, whether that be control or data protection? What else do you see kind of customers using from the on-ramp to the browser isolation product? Yeah, I'll answer that, but let's make sure we circle back to what we do differently than DOM scrubbing and pixel pushing. Absolutely. So once, when the secure web gateway has made a decision to isolate traffic, this could be based on newly registered domains or suspicious traffic, which is not yet being identified to be something you would want to serve to users or it's not yet identified to be malicious. The remote browser gives you a lot of control over how the users can interact with it. For example, it can mitigate phishing by preventing users from uploading files from their local workstation or even downloading a file from a website, performing input into password fields and mitigating a credential harvesting attack, as well as prevent, if they're looking at the sensitive app, for example, preventing data loss by preventing people from copying sensitive information from the website to their local machine. Got it. And from a setup perspective, once the magic web uses are in place, what's the outlook look like to enable users to using kind of what you just talked about to get them set up in an isolated browser? Yeah, so it's not all that much different to just having Cloudflare filter and inspect HTTP traffic. So once Cloudflare is able to inspect and filter traffic through the secure web gateway components, it's only a matter of adding an isolate policy to say this subset of traffic or these range of sites should be steered into a remote browser. An administrator is going to be very granular in controlling what traffic is isolated and what traffic users continue to access directly. Awesome. So using the magic web product already and then adding browser isolation, the uplift is a couple of clicks and you're off to the races more or less. There's no need to, I was just going to say, there's no need to manage a scaling remote browser solution or positioning remote browsers. We automatically scale it across our global network. So wherever your users are, they automatically connect to their closest Cloudflare point of presence and we serve that remote browser near them. That's really important for their end users experience since every, you know, typically we interact with web pages locally. So we're used to moving a mouse or pressing a button and that being an instant response. With a remote browser product, there is actually some latency that's introduced for serving that. We're able to keep that extremely low by positioning browsers close to the user. So when they click, it's imperceptible that they're actually integrating and interacting with a remote browser. I love it. And I'm sure others have talked about it as well, but when you're using the remote browser product, which we do at Cloudflare, it's really impossible to tell because it's so seamless, right? It just flows like you were using your data driver, if you will. Tim, go ahead. Yeah, that's, I was just going to say, that's really a testament to what I mentioned before, DOM scrubbing versus pixel pushing is a testament to how our vector-based rendering model works. Instead of sending pixels over the wire, we actually send vector instructions, which is essentially mathematical instructions to say, draw, how you draw particular lines, squares, shapes, colors, all those things. And all that comes together to a really low bandwidth, crisp, sharp experience for the end users. Awesome. And then you mentioned there, the buzzer, the word or acronym is NVR, correct? It's pretty revolutionary if I were to use the word to describe it. Is that a fair assessment? Yeah, absolutely. It's patented and unique to Cloudflare and in the industry of browser isolation products. And it's always fun as a product manager working with the engineering managers on this technology because a number of our engineers actually come from a video game background. And it's interesting seeing how their experience in graphics programming in the video game industry relates to cybersecurity and browser isolation. I love it. Well, Tim, I'd love to talk about some real world examples of kind of the magic when in browser isolation use cases in real life. But before we do that, I was curious, we talked a little bit about the uplift for administrators is just configure an isolation policy and they're off to the races. Well, kind of that data control element, what do you see customers getting most excited about the problems that they're solving, whether that be the controls that we have today and then the use cases that they're using? What do you hear the most about excitement and buzz from customers? Yeah. When talking to customers about data control, it's interesting because a common statistic keeps coming up, which is, I forget the exact number and most statistics are made up, but the vast majority of data loss events actually occur because of end user naivety. So the work we can do to warn a user when they're performing an action that could lead to data loss can help mitigate a number of data loss events. So functions like preventing clipboard, upload, download, and even some work into screenshot mitigation is really important for protecting data. I also just want to add one of the challenges that administrators have with browsers and protecting against an emerging threat like a zero day within a browser environment is just patching. There have been, I think in the last year there's been six zero days for the Chromium engine and those zero days are situations where code in an untrusted website or a code running in a browser could compromise an endpoint machine. The remote browser does a number of things to prevent that malicious code from breaking out. So if the remote browser and into the user's local machine and there's things like preventing local network access to the local machine and local code execution and that buys a lot of valuable time while local browsers are being patched since our browsers are isolated, even always isolated. So if there is a zero day attack and it does affect a remote browser, the blast radius of that is much smaller than it would be if it affected a local machine. Awesome. So the Zero Trust principle is applying there directly to that control and limit blast radius, literally personified in that deployment and that architecture model. Yes. Awesome. Well, Tim, I know this segment is to talk about MagicWay and browser isolation. So I'd love if you could talk us through maybe one or two real world examples of where you're seeing this kind of come into play and what customers should be most excited about here. Yeah, absolutely. So the two main areas is if you're integrating browser isolation into an existing network and you're looking to connect legacy hardware to Cloudflare to then connect to browser isolation. So if you're a business which has many sites and you've got many firewalls, you can connect them all to Cloudflare's edge through MagicWay and have the consistent isolation policies across all of your sites. You don't need to worry about deploying a browser isolation solution to them all or centralizing and impacting user experience by adding latency. With our GRE connections and IPSECs, this is all, it leverages our Anycast network. So you don't need to think about what POP is it's connecting to. You just establish a connection to Cloudflare and our network automatically connects you to the lowest latency POP. The other is if you're building out new networks or expanding sites rather than buying additional hardware, you're able to leverage MagicWay once you get a connection through to deliver the firewall, secure gateway, DNS filtering, gateway filtering, and browser isolation solutions all together without needing to build out a rack in each of these locations. Got it. And from a, I always like this as well. So a question as well from kind of seeing these products come together and being able to help additional companies with different networks and things that may not be necessarily easy to pick up and move or migrate that may take lots and lots of time to do. How do you see them getting started with kind of MagicWay or perhaps browser isolation in this journey? And kind of like you just mentioned, once you have the traffic flowing, it's as simple as configuring a policy. What's kind of that first step in this journey of seeing the true value of the MagicWay and plus browser isolation pieces coming together? Yeah. So it's really easy to get started testing browser isolation. In our blog, we now have a form where you can request access to a demo environment to test the remote browser. So, and that's already running on our global network. So you can see the experience just as you would if it was connected through MagicWay. MagicWay does require, like it is a technical integration. So there's no software to install your local devices for it, but there is network configuration for it. So the best way to get started there would be to contact us and we can help you set up a environment, a proof of concept for that. But the easiest way to test locally, well, test without performing browser-based changes is through our roaming client, Warp, which establishes a tunnel, which is terms blanking on me. It's a wire guard tunnel, a wire guard tunnel to Cloudflare's edge, and you're able to test through that on your own endpoint. Awesome. So lots of different ways to, I guess, feel the full experience from, if you wanted to go the full route and have MagicWay plus browser isolation policies, you can experience that yourself and just try it out. I believe the link to that form that you just mentioned is in the blog post and also going to be linked in the description of this Cloudflare TP segment. And that will let you get access to, you mentioned the kind of the clientless experience, just to confirm what that would look like from the user perspective. Yes. Perfect. Awesome. Well, wrapping up here a little bit, Tim, we've talked about how the Cloudflare Zero Trust and Cloudflare One specifically products are coming together to make things easier for customers. And I would argue this is probably one of the most clear Cloudflare One vision maturations or personifications that we've seen, right? It's a networking -based solution coming together with a browser-based solution to provide users complete and total control of their employees, contractors, third parties, browsers, browsing experience, adding data control, or even preventing those potential outages from executing or detonating locally on their employees' clients' devices, phones, tablets, et cetera. So if you're not already using Zero Trust, this would be the time to go check it out. You can try it at Cloudflare .com slash Cloudflare-one. For teams of 50 or less, it's free. You can get started. And then when you're ready to try out the browser isolation product, you can do so via the link that we just mentioned about moments ago. And we'll also be in the description here. If you're a current Zero Trust customer, check out the Cloudflare .com slash Cloudflare-one or contact your AE or us to get started with the rest of Zero Trust, browser isolation, CASB, DLP, all the other products Tim kind of mentioned. And for those that are new to Zero Trust or just kind of getting started and knowing where to jump in, we have a roadmap that is vendor agnostic at zerotrustroadmap.org. That website has a list of very tactical and practical steps of kind of how to think about getting started on a Zero Trust journey, the solutions, techniques, tactics, step-by -step broken down in phases, understanding that this is a journey rather than a specific destination to arrive at. And so we have a guide on how to do that, how we think about it at Cloudflare, and we hope you'll check that out as well. So feel free to get started with browser, feel free to get started with the popular Zero Trust, continue to pick your list, or if you're just curious, zerotrustroadmap.org has how we're thinking about it as well. Tim, any last thoughts on browser isolation and MagicWay? Yeah, I think just to echo that point about how this is bringing the Cloudflare One vision to life more and more. We mentioned in the beginning how it's challenging to keep adding additional appliances to defend against emerging security threats. We don't yet know what the next browser isolation would be to defend against the next level of security threats. But when it comes to that time, the great thing about building into a cloud network as a service providing these security functions means the next one will also just be very easy to add on as we'll integrate it into our offerings as well. And it will just be buttons and layers for an in-depth security solution. Awesome. I think you hit the nail on the head there at exactly the Cloudflare One vision. Awesome. Well, thank you all for watching. Tim, thank you for joining me today to talk about MagicWay and browser isolation. And we look forward to all the exciting things to come for the rest of GA Week. Thanks all. Thanks for having me, Corey. Bye. Hello from rainy Singapore and welcome to Cloudflare GA Week. We have never done a GA Week before, but we're excited about this as a way to take a bunch of products that we have already announced and actually make them available and especially to tell the stories from customers about how they are using these products in their production environments today and how you can use them in order to build the fastest, most reliable, most secure, most efficient and most private applications on the Internet. As some of you may know, September 27th of 2010 was the day that Cloudflare launched. And so every year around that date, we celebrate our birthday with a series of new announcements around what we call Birthday Week. And we're doing that again this year, next week, actually. But what we realized as we were looking at Birthday Week was we've announced a bunch of stuff and it's time for a lot of it to go GA. And so we're taking this opportunity a week before Birthday Week in order to hold our what we call GA Week. And so you're going to see a bunch of products that we've already announced now become available for anyone to use and be able to use in a way that you can trust and that they are production ready, enterprise grade and ready to do whatever it is to build those applications of the future. And so if you've been waiting for better user account controls, that's coming out GA this week. If you've been looking forward to some of what we've done around the amazing acquisitions of AreaOne and Vectrex in CASB and email security, those are products that are going to go GA this week. And even some of the products that I know a ton of people are excited and just waiting to go out, watch this space because over the course of this week, we're going to be GAing those products too. At the same time, we're going to be sharing stories of how customers are using those products in order to make their production environments as efficient as possible. And all this just sets the stage for next week, which is our Birthday Week, where we're going to do what Cloudflare always does, which is hopefully surprise and delight the entire Internet, releasing products that make the Internet a better, faster, safer, more reliable, more efficient place. So stay tuned. This week is GA Week. Next week is Birthday Week. And we're super excited for everything we're going to be announcing. So Q2's customers love our ability to innovate quickly and deliver what was traditionally very static, old school banking applications into more modern technologies and integrations in the marketplace. Our customers are banks, credit unions, and fintech clients. We really focus on providing end-to-end solutions for the account holders throughout the course of their financial lives. Our availability is super important to our customers here at Q2. Even one minute of downtime can have an economic impact. So we specifically chose Cloudflare for their Magic Transit solution because it offered a way for us to displace legacy vendors in the Layer 3 and Layer 4 space, but also extend Layer 7 services to some of our cloud native products and more traditional infrastructure. I think one of the things that separates Magic Transit from some of the legacy solutions that we had leveraged in the past is the ability to manage policy from a single place. What I love about Cloudflare for Q2 is it allows us to get 10 times the coverage as we previously could with legacy technologies. I think one of the many benefits of Cloudflare is just how quickly the solution allows us to scale and deliver solutions across multiple platforms. My favorite thing about Cloudflare is that they keep development solutions and products. They keep providing solutions. They keep investing in technology. They keep making the Internet safe. Security has always been looked at as a friction point, but I feel like with Cloudflare it doesn't need to be. You can deliver innovation quickly, but also have those innovative solutions be secure.