1️⃣ Area 1 + Cloudflare Remote Browser beta

Good day, everyone. Hello. My name is Tim Obezuk and welcome back to Cloudflare TV.

This week is a special week because we're talking about Cloudflare One and the innovations that we've been shipping, partnerships, new products and features within the whole Zero Trust space.

And today, we're going to be talking about a announcement we made on Monday, which is a new integration between email security and Area One security and Cloudflare's Zero Trust Browser Isolation platform.

So for those who don't know, Cloudflare One is our comprehensive cloud-based network as a service solution, and we're protecting the future corporate network.

It replaces patchworks of appliances and WAN technologies and provides a single control plane for protecting your networks in a single interface.

Today, I'm delighted to be joined by Shalabh Mohan, who's a product manager with Area One, and also Phil Syme, who's one of our highly distinguished engineers.

So Shalabh, I'd love to just briefly have you introduce yourself.

Can you tell us a bit about your role and what you've been working on?

Sure thing.

Thanks, Tim, and great to be here. We've been addressing this problem of phishing campaigns and making sure that we we protect organizations and users from the number one threat factor out there for several years.

And a few months ago, we came into the Cloudflare family and super excited to extend our product portfolio and bring the solution out to broader scale and the reach that Cloudflare has.

Also excited to address additional use cases like the ones that we're going to talk about, which is deferred phishing campaigns and blended threats that come across these sophisticated attack campaigns that we're increasingly seeing in this marketplace.

Phil, if you want to talk about yourself?

Yeah, thanks.

Thanks, Shalabh. So I'm one of the co-founders of Area One and I was formerly the CTO, now an engineering role here in Cloudflare.

And yeah, it's been having a lot of fun getting to kind of immerse myself in all the Cloudflare tech and, and use it for this, this integration that we're going to talk about today.

Great.

Thank you, Phil. And I'll introduce myself in more detail. I'm a product manager on Cloudflare's Zero Trust team.

What I think about day to day is protecting users while they're browsing the internet with our Browser Isolation product.

One of the...

so what we're talking about today is the protecting potentially malicious or suspicious links, but at the point of time when users click on a...

with a remote browser. This is something I'm super excited to be talking about today because as the Browser Isolation product manager, I often had conversations with customers where they're saying, How can we protect malicious links in email?

And for a while there I was thinking, I may have to have my team build some email security solutions.

And then on April 1st, I got the best news in the world, which is Area One was joining Cloudflare.

And I also heard the reverse story with Phil, which was they had considered building a Browser Isolation solution for their, for the Area One platform, so it's very serendipitous that we've come together and been able to work on this.

Great.

So, Shalabh, would you mind giving us a rundown of the types of attack campaigns that people see and where isolating links can help users?

Yeah, absolutely.

When we take a step back with threat actors, what we have learned is they're going after the user, they're going after the person, not the protocol.

They want to make sure that they have any which way and means to create authentic looking campaigns that can breach an organization.

First-generation campaigns and attacks that were link-based were typically fairly static in nature.

They were declarative.

You could actually make a make an assessment where that link was hosted, what's behind that link.

and based on that, you could make an assessment of the maliciousness or the genuineness of that link.

And so several solutions out there can do that or make that assessment.

Area One, on our side, of course, sort of competitive differentiation is being able to preemptively understand the infrastructure behind that link and how that campaign is getting stood up, what's behind that campaign before something gets activated.

Over the last couple of years, what we've also started seeing is this increasing prevalence of campaigns that would look benign as they are coming through the email within an organization.

And they become activated at click time or they become weaponized at some point down the line.

So think of it as, a message comes to you on on a Sunday evening and everything about that message is completely appropriate.

So filters that are looking at that message as it's traversing the email flow, it's all good.

But the attacker is going after the fact that when the user comes in the next day morning at 9 a.m.

or 8 a.m., when they click on that link, they want to make sure that they're pushing out something that's malicious, so they'll weaponize that campaign at that point in time.

So key use case to close that bridge or bridge that gap or we call this last-mile blended-threat gap is to make sure that you're able to effectively detect anything that's malicious at click time.

So that's one use case.

The other use case that we see increasingly is Cloud Services Campaigns.

So as we've gotten into a world that's extremely mobile and remote and a lot of work is happening across cloud applications such as SharePoint, OneDrive, Google Drive links, the links within those, those services are encrypted and they can redirect you to malicious content that the threat actors are taking advantage of.

So in order to truly inspect that, you need to have knowledge of what's happening in real time while that click is happening from the user's perspective.

So that's another set of campaign types that we are seeing increasingly.

We want to make sure that we help customers get protected against those.

And so as we come out with the solution, the the assessment of the signals in real time as the message goes through allows Area One to say, Ok, these links, we want to make sure that we will redirect to our isolation service so then when the user clicks it, we can put that behind the isolation service, detect if something is bad, if it's appropriate, if it's good, it goes through, it's transparent to the end user, but if we detect something is malicious about it, they get blocked and at that point the user is protected.

So those are the two key use cases that we have seen, Tim, come across.

But there's many additional ones that that increasingly threat actors are using to make sure that organizations get breached.

Yeah.

And with the the topic of making a decision to block or not block traffic, it it's generally something that requires a careful balance because if if users, well if administrators are too aggressive in blocking because obviously they want to block every possible unknown risk, it could really impact user productivity.

And I'm definitely excited because for those links, let's say it's a legitimate new product that's being announced that someone's being emailed by, that buys the department time and the threat intelligence time to do their investigation without letting them look at the site directly by putting the site into a read-only state or preventing user input to prevent credential harvesting, for example.

That's right.

And I think acting upon signals that are dynamic in nature as the message is coming through, understanding where is the link posted, what's the age of that link, assessing what kind of language is being used in the message itself, makes some determinations of whether to isolate or not, allows us to blend that balance that you just talked about Tim, which is business has to go on.

Email is a mission-critical application.

The world transacts on email, the world operates on email, you want to make sure that you're not stopping normal business while still protecting users and organizations without pushing that that assessment or that decision onto the end user or the organization.

And that's where we come in using using those dynamic signals to determine where to isolate and how to isolate.

That's great.

I also, I find it extraordinary how much implicit trust has been put into emails.

I'm Australian and recently moved over to the United States and one of the things I found very interesting was in Australia I could always pick up my phone and know that the person who was calling me was legitimate.

But I got a very quick lesson when I came to the US.

I should never pick up my phone since it's always a bot or a campaign that's targeting me.

And it's extraordinary that email is an open door where people can send me something and I have that implicit trust and click it, which is something I wouldn't do on my phone or in any other service beyond email.

Yeah.

No, I think it's certainly a dichotomy. There is implicit trust in all communications that we do through email, the fact that you're receiving something, at some point the user is conditioned, Ok, that might be an appropriate thing to interact with because that's all they're doing is trying to do their business.

Technical controls have to get to a place where we're not pushing the end user to make a distinction between, Hey, is this legitimate or is it not legitimate?

How do we make sure that that the user is free to do their work while making sure that they are secure and protected at all times?

And the better technical controls we can put, the more transparent we can make it for the end user, the more easy we can make it for the end user, the better the security that we can provide to the customer itself.

Yeah, absolutely.

And I think one of the one of the stories from your blog post I really enjoyed reading was asking the question of why people still click on malicious links.

And generally the end user has the best sense of who should be communicating with them through email.

However, even with all of the anti- phishing training campaigns they have, people are still clicking on links and falling victim, from being really busy and just immediately needing to process through all of their work and going through 50 emails at the start of the day.

Absolutely.

I think it's just ingrained in the sort of ethos to do that.

And it happens consistently. To expect them to be vigilant or even to understand.

Vigilance is one thing and everybody needs to be aware and have the appropriate education and awareness about the threats out there, but at the same time, understanding the sophistication of how these campaigns get destructed and forcing the end user to make that assessment is almost unfair.

It's like going to the doctor and the doctor telling you you should self-medicate yourself, self-diagnose yourself and we have given up.

And we want to be in a place where we actually are helping the organization and the end user make those, take those decisions away from them, protect them.

Anything that comes into the inbox should be clean. Anything that doesn't is something that we protected against them getting compromised.

Yeah, absolutely.

Cool.

Well, I think now will be a great time for us to maybe show the people a few things about how it works.

What we've announced, everyone, is still, it's in the private beta stage at the moment.

So if you are interested in exploring in more detail what we're, what we're about to show in the blog post, which is titled Email Link Isolation, there'll be a link down the bottom to join the beta for that.

But we're happy to give you a bit of a glimpse today.

Awesome.

It's full.... Let's do a couple of demos.

I think we have set that up.

Before we do that, one thing though, as Phil is bringing it up...

Tim, it would be great to talk about the technology that we have behind our own isolation service and how we make sure that it's transparent for the end user.

But Phil, I think you're walking us through sort of the default campaign use case where something comes in through an email.

It's completely fine, but at click time, an assessment is done.

Yeah, what I did is I pasted a rewritten link.

So this is a link to that deferred campaign, example deferred campaign that is rewritten.

And at click, the user would experience seeing a page like this with a warning.

Yeah, so the way users would get to this place is by having Area One's email security at the front of the email, which just requires an extra layer of change to implement.

Area One's able to assess whether that email should be delivered to the user.

And Phil and Shalabh, feel free to override me as you're the experts in this space.

But Area One will make the decision about should this email even land into the user's inbox.

It may be from something that generally appears legitimate, like, for example, someone else's Okta instance, which is a very legitimate enterprise.

However, some bad actors may leverage a legitimate service to perform an attack.

So once the email, if there is an email that appears legitimate at the time of delivery, we would rewrite the links within that email and then at the point of time of the click, steer them to a splash page such as this where we can warn a user about whether or not they should go through if they're extremely confident they have that option to do so.

But if they...

ideally we would prefer them, or the user will be safer if they're accessing the isolated browser where we can control how they interact with that service.

That's right.

And Phil, if you can share, what are some kinds of signals we're looking in the email to make the determination what to isolate or what we write for isolation down the line.

If you can share some of that. Yeah, and so just as general background, at email delivery time, we have to be extremely strict in our algorithms about what email we are going to definitely block the end user from seeing, having definite proof of phishing at that point.

So some examples of these sort of more margin campaigns where it's hard to get a signal at delivery time is if the site comes in without DNS active or without even a website active.

You know, coming in kind of dark, quote unquote, then it is, it's not possible to make a determination sometimes for those cases.

And so then that's a really good place to to rewrite links.

And in general, we can be a little bit, be more aggressive about rewriting links as opposed to just blocking email from end users' inbox.

And those are questions.

Phil, does the user see anything different?

Does the link look different to the end user when it's coming to the user in the inbox?

Or is that transparent to them? It's...

visually, it's transparent. If you hover over the link, you're going to see more complexity, like you see more complexity in this link at the top, but in general, it's transparent to the end user.

And then if they do click through in the isolated browser, this is the really cool thing that Tim and his team have done.

It's it's very tricky to get this right, but to have basically a pixel-perfect and very performant isolated browser once you click through, kind of in this safety.

Yeah.

So let's, let's double click on the click you just made there, which is that link went from the static splash page to warn the user about the action they're about to perform and steered them into a headless Chromium browser running on Cloudflare's edge network.

We have hundreds of data centers around the world, and in that time, our network connected the user to their closest Cloudflare data center and connected them to a browser to serve that site.

There's a few layers of protection going on here.

One is any of the code inside that site is not running on the user's local device.

Browsers...

We all see the update button in the top right of our browsers every single week, and that's because the browsers need to be continually patched to mitigate zero-day attacks and now the CVs that are emerging all the time with web browsers.

And especially at 9 a.m.

in the morning, if a user thinks there's something urgent that they need to action, they're unlikely to patch their browser before going into email and doing their job.

So any malicious code inside that site is isolated from the user's device and does not execute on their device, preventing any sort of breakouts of the browser environment into any of, into a user's device or anything that it's connected to.

The other cool thing is that the point of time of the click click, Area One and Email Security is able to use the latest intelligence to define how should the user be able to interact with this site.

If we're still extremely suspicious, we can put it into a read-only state.

If we're feeling a little bit better about it, we can just put many alarm bells on top of the page to say You should be very thoughtful about what you're doing here and here are all the checkboxes you need to approve before you go down this path because it's, this is really fishy, right?

The other thing I want to make sure, if you can go back to that demo or that page itself, Phil.

The attackers are going after the identity of the of the user. As we all know, identity is sort of increasingly the new perimeter and all other single sign on services that an organization uses.

Once you're able to harvest credentials of something such as a single sign on service that the organization might be using, you can get access to those applications.

You have a front-row view into everything that's happening within that organization.

If you look at this, this is a page that is a perfect replication of that kind of single sign on service with a domain that looks very similar to what the organization's domain might look, for that single sign on service.

So protecting them from going to such a fake information harvesting page is critical.

And oftentimes that page, when the link comes in, it's completely benign. But as Tim said, at click time at 9 a.m., it's weaponized and activated to become a credential harvester service.

So using isolation, along with the dynamic signals that we have within the email itself to isolate that for click-time protection protects the end user from getting their credentials compromised in this use case.

Yeah.

And to that point of harvesting identity, this is also a valuable way of protecting any sort of reconnaissance or harvesting data as well, since all traffic from the remote browser originates from, technically originates from Cloudflare's network.

So it will make it harder to detect what underlying network the user's connecting from, what type of device they're using, since it's indicated as the Cloudflare Remote Browser.

Absolutely.

And then there was another use case that we have talked about, which is the cloud services campaign use case, if it's a cloud storage service like OneDrive or SharePoint.

How does this combination of a service protect against those kinds of campaigns?

Yeah.

So what I can do is bring up kind of a live malicious site that is hosted using sharepoint.com.

And so this is something, or this PDF is known to be malicious.

And if I were to click on it and open it, I could get infected. So this kind of use case is, is really good for the isolated browser which protects against that because the browser is kind of running on the Cloudflare network and not on my desktop.

Yeah.

That's definitely one of the powers of having a full-featured browser running at the edge of the network and away from the user's device is if, in the case of attachments or files that the user may want to view from that link, we're able to securely present that to the user.

In fact, any PDFs that the user opens in a remote browser, they are transposed into, well converted into the remote browser environment, which then sends safe vector draw commands to the users.

So even if the user is opening up a PDF document that's been linked to them from the email, none of the code of that PDF document executes on the user's local device and then they're protected from any attacks built into the PDF.

Tim, if you can share some thoughts on isolation browsers, or browser isolation.

There have been multiple different stances on that in the industry.

What is, how is Cloudflare doing it uniquely and differently to make sure that the end user is not impacted?

If you can share some thoughts on that.

Yeah, absolutely.

So if we take a step back and just think about what browsers actually do, it's a piece of software that runs on everyone's machine that, by typing in a URL, it will go out and download someone else's code and execute it on your local device.

And if there was any other software in the world where people wanted to deploy that in a business and say, we're going to install a piece of software that downloads code on the fly and it can come from any source, it would never pass a security review, but that is the world we live in.

We trust that with the web and browsers work very hard to protect themselves from any malicious code breaking out.

But we're still patching our browsers constantly because attacks are becoming more sophisticated.

Now, the way people have attempted to solve browser isolation in the past has been through one of two mechanisms.

One has been through something very close to your typical content disarm and reconstruction process by scrubbing the web page of any malicious HTML and then repackaging it and sending a clean version of the web page to the user.

This dumb scrubbing approach is quite fragile for two reasons.

One, the web is extremely complicated, so it's very easy to break websites and deliver an incompatible experience to the user as well as if if you want to stay on top of all of the emerging threats, you have to continually patch it.

So it's not a proactive and preventative measure.

It's more of a reactive measure for known security threats.

So the other end of the browser isolation space is actually running a full-featured browser in a cloud environment, but using a video-based solution to stream the web page live to the user.

Now, this video isn't a great experience for browser isolation for a couple of reasons.

One, it it adds quite a significant amount of latency and bandwidth to what they're viewing in the Web page.

Today, we're all using laptops with extremely high resolution screens.

And if we're using the Web browser all day, that's an enormous amount of bandwidth that we're consuming.

So the user experience isn't great, as well as the latency, as I mentioned with the encoding.

Users are used to a local experience, so any latency can impact productivity since users are interacting with all of their critical business applications in a browser all day, every day.

So the way we approached it is by actually looking deeper into how Web pages are rendered under the hood.

And what we found is Web pages are vector under the hood.

So after all of the HTML, JavaScript, CSS is computed, you result in some vector draw commands and we send them over the wire to the user's browser, which are very safe, easy-to-sanitize commands, like draw a square, draw a line, draw lots of squiggly lines, and you've got text all of a sudden.

And after sanitizing them and sending them to users, we're able to draw and reconstruct the full web page on the user's device without letting through any security threats, and you have the original code of the website or increasing the bandwidth that they need to connect to this remote system.

And as I mentioned, our network is so close to the users that every time they're typing or scrolling, the latency that they perceive is so low that it just feels like using a normal website.

We've definitely heard about that from customers.

Isolation browsers can impact end users and compatibility with websites out there.

Transparency, latency.

All of those issues prevent organizations from going and deploying browser isolation in a more broad manner.

And so this ability to draw upon this in a different way and then make sure that customers, their experience is transparent, along with focusing on links that are margin campaigns on an email, I think blends both of those in a in almost an optimal way to introduce browser isolation and organizations that are still on the edge about it.

Yeah.

Yeah. So tell me, how can we get access to this?

What's the next step to getting access to this?

And...

So if you go to blog.cloudflare.com, you'll see a blog post which is introducing browser isolation for email links to prevent modern phishing threats.

Down at the bottom, we have a link there which will allow you to connect to the waitlist to sign up for the beta.

So just type in your email there and we'll get in contact with you.

One of the things I and we're almost out of time.

We've got 2 minutes left, but one of the things I've been really excited about is we've been building this from the technical perspective, is how we've been able to connect existing Cloudflare products together to deliver this solution.

Phil, you and I have had a lot of fun working with Cloudflare Workers to deliver this, and it's been really interesting seeing this come together without needing to build new servers or anything.

It's just integrated with our existing features.

Yeah, it's been a lot of fun to use Workers for the solution there.

From a software development standpoint, extremely fun to code in and use and you get sort of instant worldwide scalability, a ton of fun and very useful.

So yeah.

Cool.

All right, well, with that, thank you, everyone, for hearing us talk about browser isolation and email security today.

As I mentioned, my name is Tim Obezuk, product manager for Browser Isolation, Shalabh Mohan, product manager at Area One and our distinguished engineer, Phil.

Phil Syme from Area One as well. Thank you all for watching and we'll see you all next time.

Thank you, bye.