ℹ️ API-Based email scanning
Welcome to Cloudflare CIO Week 2023!
This CIO Week we’ll demonstrate how Cloudflare is helping CIOs keep data, devices and employees both safe and fast across hybrid and remote environments. We’ll show how Cloudflare accelerates digital transformation and modernizes networking and security towards a Zero Trust model.
In this episode, tune in for a conversation with Cloudflare's Shalabh Mohan and Ayush Kumar about Cloudflare's new API-based email scanning using the Microsoft 365 API.
Tune in all week for more news, announcements, and thought-provoking discussions!
Read the blog posts:
For more, don't miss the Cloudflare CIO Week Hub
Hi everyone, welcome back to Cloudflare TV and to CIO Week. I'm sure you all have seen some really cool announcements that have already happened this week.
But in this segment, we're really excited to illustrate a new deployment method for Area 1 security, and how you can start leveraging this through our open beta.
So just to introduce myself, my name is Ayush Kumar.
I'm a product manager at Area 1 security.
Today, I'm joined with Shalabh Mohan, who is the head of product at Area 1.
And today, we just announced our API -based email scanning tool, which is an open beta.
So now what that means is customers are able to onboard their new domains using the Microsoft Graph API.
So I think to kick us off, Shalabh, do you think you could give us a quick overview of, you know, what is Area 1?
How does it work?
Sure, thank you, Ayush, and great to be here. At Cloudflare Area 1, our focus is to solve one of the biggest, most perplexing cybersecurity threats that organizations face, which is the end users.
And most end users get targeted by attackers through phishing.
And email is one of the primary ways through which these attacks happen.
And so that's what we are focused on, ensuring that your organizations are protected against targeted attacks that are coming at you, whether it's advanced attacks through BEC messages, or credential harvesters, link -based campaigns.
The vast majority of these campaigns could manifest themselves in various different ways and vectors.
And that's what our service gives you the ability to both detect, protect, and also make sure that your end users are always sort of secure without getting targeted by these threat actors.
One of the big things that we have done over the past several years is this notion of being ahead of the attacker, being preemptive in nature.
Attackers take time to create the infrastructure.
They take time to actually create targeting infrastructure that allows them to go after organizations, do reconnaissance, set up the actual sort of campaign.
And in that time, that gives us the ability to go out and find where this is getting stood up.
And so using our vast network, and CloudFest sees approximately about a third of the DNS traffic globally every day, we're able to go out and call for these campaign elements and campaign infrastructure elements and use those in our models and ensure that you're protected.
And coupling that with our advanced language and neural network models to understand what kind of campaigns are coming at you, what's the conversation that's happening within a message itself, allows us to be really accurate in detecting what is bad and good and ensuring that your inbox is always protected.
Yeah, absolutely. We're always ahead of the game here at Area 1.
In the past, we've had a lot of different deployment types.
I'm sure you'll dive into them a little bit deeper. But I guess for those who are watching or will watch this later, why would I want to onboard a domain with this new API-based onboarding mechanism?
Yeah. So the thing is, with email, what's happening is as attackers are coming at you, you want to make sure that you have an ability to assess what the message is, allow our models to be able to understand, and then if it is something that is potentially malicious or suspicious, flag that appropriately.
So there's a variety of different ways you can go about it.
You can actually deploy inline. You can be in an MX position, MX record position, where we see all messages up front before it hits the inbox.
You can use offline methods like journaling or through a connector.
And now with the Graph API method, we have the ability to, in a very passive way, understand what's sitting in your inbox or what's flowing into your inbox.
So the goal here is just to give customers choice and flexibility and give them the best way possible to help make sure that their messages get scanned for these threats and these attacks without disrupting the ongoing business that is relying on the email traffic.
Right. Yeah, absolutely. I think as we look at other deployment types, API, we're always trying to offer more flexibility.
So I know there's a lot of customers and some of our early users who use this.
Do you maybe have an example of a customer who decided, you know what, API is the way I want to handle things and how it worked out for them?
Yeah, absolutely. Without disclosing the customer name itself, we find many different use cases.
One of the classic use cases that we find is the messaging team is the one that's responsible for everything that's related to Office 365 and it's related to infrastructure that they're running.
And email is a business critical application.
The security team is responsible for ensuring that the inboxes are clean and the attacks against the organization are stopped.
And a lot of times the preference of the security team is something that can work offline instead of what the messaging team is leveraging.
So we find use cases where we'll find the specific team is interested in assessing the posture of the organization, doing a quick passive scan to know what is sitting in my inbox, what kind of traffic am I getting, what kind of threats am I getting, without making any changes to the routing rules or email traffic that's coming at the organization.
Another good use case that we find with customers is M&A.
Let's say you're a large organization or even a small organization, you're bringing an onboarding and additional domain, you're bringing an onboarding and additional entity.
And before you want to do that, you want to make a baseline assessment of the security posture of that organization.
And as we all know, email is one of the biggest exposure events for the organization.
So using this deployment method, they can do that passively very quickly.
And within five minutes, you're up and going, and then you start getting visibility into what's happening with that entity.
So M&A is a very classic use case.
A third use case is you want to make sure that you have the ability to create different scanning profiles for different kinds of domains within your organization.
So you might have a primary domain that's running in line, but a secondary domain that could potentially be used through GAF API and deployed through that for a passive assessment on what's happening within the inbox.
So we see all across different use cases, and we're happy to provide that flexibility using this new option, Ayush.
Right. Absolutely. And I think as I speak to customers, definitely the ones where I've seen ears perk up is the M&A example where they want to have something, they're caught up in kind of this IT handover, and they're trying to get protection onto whoever they've acquired their email.
So rather than being roadblocked on waiting for things like MX records to be handed over or access to be given, they're just able to quickly take the domain, have the right authorizations, and you're protecting those set of email inboxes almost instantly.
And we'll have a demo of that later in this broadcast to just show you guys how easy it is to really get something like this set up.
So I think maybe customers...
One of the questions I've gotten as I've spoken to customers is, I want to onboard a domain via the API, am I losing any protection or is this a different product?
Maybe Shahab, could you mention the product, right? Yeah. Yeah.
I'm glad you asked the question, Ayush. So any of the products and capabilities that we create within the service, we want to make sure that the protection levels are the same for the customer.
These are just another deployment method to give flexibility and the ease of insertion within a customer's environment.
The same detection models apply, the same overall visibility to what's being caught, what's being detected applies for the organization.
So we want to make sure that none of that changes.
Now, the goal here in the initial open beta that we're pushing out is give you visibility to these threats that are coming through.
And then with additional version that we'll come out with, you'll start getting the ability to remediate or start retracting these messages using the same deployment model.
Today, customers have the ability to retract using the Graph API, but then coupling that with just the deployment using the Graph API completes the whole cycle for the customer itself.
All detections are available, whether it's link-based campaigns, attachment, payload-based campaigns, URLs, or just classic, your advanced BEC campaigns, whether it's a baseline campaign, just a BEC type one or going all the way to a vendor-compromised attack that could be coming after the organization.
The models are applied independent of the deployment method to make sure that the customer has the entire surface area of protection at all times.
Yeah. And I think as we were working on this product, this onboarding type was to really make sure that whatever the customer wanted, it was about flexibility, but it never detracted from kind of the Area 1 experience that they were going through.
I think one of the things that I think I hear a lot from customers is, is there differences between, I'm using the API now, is there a difference or loss in fidelity of data that I would get from MX or from a different deployment type?
Yeah, that's a good question. I know that there's no loss of data fidelity, but every deployment method has its unique set of options in terms of how you remediate the message and what actions you can take.
Clearly, if you're in the MX record position, then with the service, we have the ability to stop these attacks from even getting into the inbox in the first place.
You want to make sure that the end user has as little interaction with a threat active message as possible.
And by being in the MX position or in line, you get that option, you get that flexibility.
Now, if you're using the graph API to do passive assessment and remediation after fact, at that point, the message is in the inbox, admittedly for a very short period of time, but you want to make sure that that flexibility has the trade-off of ensuring that the message reaches there, but we're quickly using the graph API to take that action.
Also, capabilities such as link isolation are best approached in an inline mode because you want the ability to rewrite the URL and isolate the user from going into something that could be potentially malicious.
And that is usually the case when you're deployed in the MX position or in line.
But with the graph API, you do get the visibility to what attacks might be sitting inside your organization, and then you can take specific actions based on the remediation options that the service gives you.
And I think, again, kind of hammering on this nail of flexibility of deployment is with the graph API, we are on the Azure marketplace, so you can get more information about the deployment type as well as other things.
And right now it's not transactable on the marketplace, but as we look forward, that's something that we're going to be aiming for.
So I think as we give more of these levers and these ways of flexibility, I don't know if you wanted to talk about that or the ease of deployment that comes with that.
Yeah. Two things, and hopefully our viewers can see this where this is going.
We want to get to a place where it is deployed in multiple modes.
And in a lot of cases, organizations and the customers are already doing that using existing capabilities that the area of one service provides.
But imagine when you are deployed in line for a certain set of domains, but also using the graph API for internal domains or other certain specific kinds of traffic.
And so that gives you the utmost protection across the entire sort of surface area of what your threats could be, whether it's threats coming at you from the outside in, the threats that we call north-south threats, or threats that are propagating within your organization by somebody whose account has been taken over.
So those are sort of east -west threats, a lateral movement of those threats.
By having the ability to do multimode deployments using both graph and inline over time gives you the most comprehensive protection for your email, for your inbox today.
So we were super excited to take that initial step and give you advanced capabilities over time as we get customer feedback and learn from customers and specific use cases that are super, that are interesting to them.
Yeah. And I think one of the points you brought up, which I've heard a lot is, I think a lot of customers I speak to are really preoccupied or their IT teams are very preoccupied with, how do I know if someone outside my organization has sent me a phishing email?
And as you mentioned that north-south protection is there, but I think oftentimes you don't think about, whether it's someone internally who's had an internal account takeover, or if it's just someone maybe like a disgruntled employee or someone who's acting in ill faith, this is a great way to really have the full compass of protection within your organization where that multimode deployments will allow you to kind of gather.
So I think, yeah, the focus and the vision of where we're going for this is definitely very exciting.
I'm really pumped to be working on it alongside you.
So I think we've hyped up our viewers enough.
I think it's worth maybe sitting down and showing how this works in real life.
Let's do a live demo and let's pay heed to the demo gods.
Yes, demos never work when they need to.
So if you're an Area 1 customer, this is kind of the screen that you're prompted to when you log in.
Granted right now, because this is a test domain, we just don't have a lot of email flow going.
But just to show how easy it is to get a domain onboarded, you can navigate to the settings field, which will pull up all the settings attributed to the tenant and start looking at the domain.
So before, if I wanted to add a new domain, it took a little bit of time in terms of getting the domain set up, setting up the MX records, and filling out some of these fields, which I mentioned in the past may be kind of roadblocked if you're a customer doing heavy M&A.
So with this new API scan, what our goal was to make this as turnkey as possible.
So rather than selecting MX records or hops, I can go to this new API scan beta.
And there's a hover tip just in case you're curious on what it actually means and what you're able to get.
But let's say I want to onboard a domain.
So I'm going to onboard this test company that we have. And I will start by first, you'll notice that there's two kind of authorizations we need.
And really what this is, is the way the graph API, we need to be able to read the messages.
And so the graph APIs publishes them. And so that's the first one is we just want to be able to read, protect, retract messages directly from the dashboard.
So in our drive to be turnkey, you just kind of press the button and you're immediately sent over to the Microsoft side of things where you can go through and see all the kind of requirements that we have when it comes to like what we're trying to read, what our permissions are and things along those lines.
So I'm not going to spend the time to go into them. We'll have a deployment guide that we'll publish after this TV segment, but you can read into it.
And we're just, again, just trying to read the messages and making sure we can accurately run our models on them.
But if I'm happy with what I see, I can hit accept and I'm sent back over to the area one side.
So as we can see, authorized, right? I gave area one permission to read the messages from the graph API.
And I think the second side of this is directory scanning.
So this is really interesting of getting information on groups and mailboxes.
For example, some of our models are built, maybe you have certain groups like a finance group, right?
We could assume that that group is probably getting sent maybe more phishing emails than other groups within the organization because they have the ability to authorize things.
So maybe, you know, they're getting an influx of malicious attachments, which may be masqueraded as an invoice, but in reality might be ransomware, right?
Or maybe just being sent false invoices so that they can pay them.
So this is a crucial part of this as well.
So like the one before, we'll go ahead and try to authorize access and we'll go through the same process.
This does have different set of permissions. Again, we'll have this all the permissions kind of posted so you can read about them in depth and we'll have them linked out properly.
But if you're happy with this as well, which I am, I'm going to hit accept.
And great. So I've authorized not only the ability of area one to read my messages, but also perform directory scanning so that we can run all of our models without having any sort of barriers to them.
So I hit- One thing to reiterate there, Ayush, is all of those permissions are being passed through permissions from Microsoft to authorize the graph API within the customer's tenant.
These are standard permissions that Microsoft expects as part this authorization service.
And we're just leveraging those and complying with Microsoft's asks there.
Yes, absolutely. So once you kind of hit publishing the domain, so you'll see this sync in progress, which depending on the size of your environment, how many mailboxes you have, mail flow, this can take a little bit of time.
We found it to go from a few minutes all the way to a few hours, but essentially, and I'll keep trying to see if- Oh, perfect.
Yeah. So one reason we had very little mail flow going is so we can have this synced very quickly, but you'll notice that once we're able to read messages as well as do a directory scanning, it will show from to be synced.
So now this domain is protected under area one.
Any detection, all detections will be available. And if anything was to happen, a phishing attempt or et cetera, we would be able to catch it.
So as Shalabh and I have been mentioning throughout this process, that really is what it takes to get a domain onboarded and we're kind of aiming for higher flexibility and how quick it is in this way.
And Ayush, if you can go back to the main dashboard, once you have onboarded the domain, assuming you have more consistent traffic, this is where you'll start seeing visible information about the kind of attacks that are coming at you at the organization, both at an aggregate level, but also granularity about what these threat types are, where these attacks, who are they going after?
What are the different dispositions of the attacks? Sometimes they're just plainly explicitly malicious.
Some of them are on the edge, sort of could be suspicious.
Then there's classic spoofs. Also, if there's any spam or bulk messages that are not being detected by your existing provider, any of this information is available to you for both investigation and detail assessment through the area one service.
Right. Yeah. You get the full suite right away as soon as that message goes from in progress to sync.
So now for testercompany.com, all my mailboxes are now protected as Charlotte mentioned, and you'll see the stats here.
So that's kind of a run through on how easy it is to just get in a new domain onboarded.
As I mentioned, it's in an open beta. We have been testing this with a handful of customers before this, but we were excited to kind of put this out in the public and get customers onboarded and get feedback for this product feature.
So, yeah, I think that's in a nutshell how easy it is and how turnkey we've made it.
So it's just easy to onboard domains now.
That's awesome. Irish, that was really, really well done.
And thankfully, the demo brought a smile upon us and the demo sort of went extremely well.
Any thoughts on where you're thinking based on customer feedback?
What are some additional capabilities and features that you're planning to add to this in coming reps?
Yeah, absolutely. I think we have some really great stuff in the pipeline.
I think right now, we're really great at, from the minute you've turned on the API scanning part, we're able to read all the incoming messages.
But as we look forward, we also kind of want to look backwards. So if you're a customer who's just now bought into Area 1 and you want to see, okay, what did I miss in the last 30 days?
What did I miss before? Maybe there's some malicious emails that are still sitting within my inbox.
So kind of the next part of this, rather than looking forward, maybe let's give a little bit more backwards visibility and be able to retract or remediate messages that might have malicious attachments still on them, which, as you know, is just a risk happening if some person was to errantly click on a download, run something or click on a link.
So I think that's kind of the immediate future is, as we're great at looking forward, let's also do some work in looking backwards and saying, let's clean up your inbox a little bit more.
I know we have this goal of inbox zero internally, which is, let's keep it clean.
Let's keep your inbox as clean as possible.
That's really awesome. And then if customers want to learn more about this and want to sign up for the beta, what kind of resources do they go after to get that information and where do they sign up?
Yeah. So I think if you're a customer already, talk to your contact within Cloudflare.
This isn't an open beta, so you should be able to do it and onboard emails directly or onboard domains directly through the dashboard.
And if you run into any problems, please reach out to your Cloudflare representative and we'll definitely work through any problems that we see.
But if you're watching this and you're on the fence about is Area 1 for me or not, you can go to Cloudflare.com and get a phishing risk assessment started and we'll walk through the process.
You'll get connected with someone from the team, but we'll also walk you through as you onboard the domain, give you access and start maybe a risk assessment to make sure maybe Area 1 is a great fit for you and it's worth pursuing further.
So I think those are two ways for the two groups that may be watching this.
And I know there's a blog post that was published. And so there's some detailed information available in the blog as well, Ayush, for the viewers to take a look at and get some of their questions answered about this new feature.
Absolutely. And there'll be their screenshots within that blog post. So if you're less of a video learner and more of one that likes to read through things, they'll have some screenshots so you can go out at your own time and onboard a domain and know the steps, the in-between steps that I just took here.
And that should be published on the Cloudflare blog as well.
Awesome. Super excited. And Ayush, and hopefully you get lots of good customer feedback soon so that we can start getting it out there in front of the entire sort of customer base that Cloudflare has.
So thank you for walking us through this. Yeah. Thank you, Shahab, for answering our questions, but thank you all to the viewers.
And if you're looking to sign up a domain, take the steps that are necessary, but we're super excited.
Thank you, Ayush.