Implementing SASE with Cloudflare

Are you still running your own VPN hardware in your office to protect your users' access to the Internet and internal resources? Did you know there's a much, much better way of doing it? Did you know that VPN hardware is now constantly under attack? Loads of vulnerabilities reported by all the major brands such as Cisco, Fortinet and Palo Alto. Did you know that Cloudflare can recreate your corporate network? Well, I'm going to talk to you about this over the next 10 minutes and go into all the details about how Cloudflare can totally revolutionize your corporate security. So I'm Simon. I work here at Cloudflare. And over the past 10 years, we've seen this big shift in the change of how your corporate networks are architected. It used to be this kind of castle and moat model where you had employees coming into the office, connect to the local Wi-Fi and all the applications they needed, email servers, SharePoint servers, remember them, were inside the office. And then you might have connectivity to the Internet to read news websites. But over the past 10 years, a lot of that stuff has moved to the Internet. You've got SaaS applications, infrastructure as a service with Amazon, AWS and Google. And now this new world means that everything is all over the place. And it's turned out that the Internet has started to be your corporate network. Internet bandwidth has got better. Reliability of the Internet has increased. And so now more and more people consider accessing enterprise applications over the Internet to be perfectly normal. It means Workday, Salesforce, they're all just sat on the Internet. So what the industry has done is we've developed this new kind of security concept called SASE or Secure Access Service Edge. So what that means is it's not that the networks have moved to the cloud, but more the intelligence and the security controls of the networks are now running in the cloud as well. So all the things that you need to do that you were doing on-prem like firewall services, VPN access into remote applications, DLP monitoring, data at rest and in transit over your networks, we can now do all of that on edge networks in the cloud. And so if you're going to do that with Cloudflare, one of the most important things is that the network you're using in the cloud is big. And Cloudflare is enormous. We've got thousands of servers in over 330 cities around the globe. We've got 13,000 or more networks that we're paired with, making us one of the largest paired networks in the world. We have 348 terabits per second of capacity on our network. That's 70 times larger than the largest denial of service attack that we've seen on record to date. So now that you're moving your traffic from your networks, from your users, from your offices into Cloudflare, you'll know that you're connecting to a very, very big and high capacity network. So what I'm going to talk about over the next four or five minutes is just how you do this. What are the components of connecting into this new corporate network? And so we start with applications. So we're going to connect applications because they're the things users are accessing. And there are two primary types of applications you're going to connect. The first one is self-hosted, so applications where you're running the servers yourself. And then there's SaaS applications. Did you know you can use Cloudflare to kind of make SaaS applications only accessible on this new private network? So let's walk through this. So the first one, self-hosted applications. What we do there is we create tunnels from your servers back to Cloudflare. So remember, Cloudflare is essentially your new corporate network. And we install software on the application servers or on servers in those application networks. And those tunnels secure connectivity from Cloudflare into those application environments. And those tunnels, they create multiple connections to more than one data center. So if there's a problem anywhere in that connectivity, it's highly reliable. And that gives us access then to those private self-hosted applications. But I mentioned SaaS applications. So how do we do that? So we actually use a few techniques. The first one is with your SaaS application, you redirect a single sign-on to Cloudflare. And then Cloudflare becomes essentially an SSO proxy to your downstream identity providers. So your user goes to, for example, Salesforce. Salesforce redirects them to Cloudflare to authenticate. Cloudflare then says, who do you want to authenticate to? Okta. So you then authenticate with Okta. Okta then redirects you back to Cloudflare with a whole bunch of information about the user, what group you're in, how they authenticated, and all that information can be used in a Cloudflare policy to then decide whether or not that user gets to Salesforce. Now, we can't go to Salesforce then and install software in their servers to be able to monitor all that traffic. So after authentication, how do we make sure we can see the traffic going to Salesforce so we can do things like looking for contractors downloading files that they shouldn't? So what we can do in the SaaS application is limit access to only a certain set of IP addresses and then make those IP addresses Cloudflare IP addresses. And then what you do is you force all the traffic either from the network or from user devices through Cloudflare. And we're going to talk about that. So that the only way to get access to Salesforce is to have your users come through a network connected to Cloudflare or be on a device connected to Cloudflare. Another really important application to connect to Cloudflare is your email. It's one of the biggest ways that attackers are getting through to your employees and it creates a lot of risk inside your organization. So we can connect your email services in two different ways. First of all, redirect your MX records so that you point all of your email traffic through us first. And that works for any email service and we can filter out all the bad emails. Or for Microsoft and Google, we can actually connect via API and look inside all those inboxes and start pulling out bad emails that they're getting. So we've connected applications, we've connected SaaS apps, self-hosted apps, and we're protecting your email. The next big area we need to connect as part of recreating your corporate network are the networks themselves. And so there are two different kind of audiences for how these networks get connected. There are IT and application administrators and they manage your application networks. And then you have your network admins and they're more interested in your routers and firewalls and they administrate your site networks. So we've already mentioned from an application network perspective, it's really easy. We have software you can deploy on servers running next to your application servers or on the application servers themselves. And we have a variety of different software agents which support different types of network connectivity. That's dead easy to deploy. Then for your network administrators, we can connect directly to your hardware. So routers, firewalls, we can create GRE or IPSec tunnels straight from them into Cloudflare. So now considering all these different methods, we can do software tunnels, we can connect in site networks, we can even connect in entire data centers. So if your applications and services are running inside a data center that we're already in, we can use something called Cloudflare Network Interconnect which is essentially going from your switch to our switch in the data center, no Internet involved, direct connectivity. So we've connected applications and networks all into Cloudflare, but what about if your end user is not sat on a laptop connected to a network that's also connected to Cloudflare? How do we actually connect the device to Cloudflare on its own? So here we have a user agent we can install on the device, and it creates, just much like we connect the tunnels into networks via software and to the routers, the device agent can also create a secure tunnel straight from their machine, and we do laptops and we do mobile devices straight into Cloudflare, and that traffic then sees the rest of the new corporate network is visible to that machine, and again you can write policies to what that particular laptop can access, what network and what application. You might also have scenarios where the end user can't install any software, so how do you give them access to private applications on your network? So our massive network you can actually run on those servers' headless browsers. We call this remote browser isolation. So you can give the end user the ability to access internal applications, but it runs on a browser that's running on our network, and now that gives us the ability to do things like stopping copy and paste, stop them from downloading or uploading files, so it gives you more control over how that user is accessing your internal applications. So now we've got devices, networks, applications, all connected into Cloudflare. We actually want to make sure who is accessing and also if the device they're on is secured. So we want to verify users and devices. So we do this, as I mentioned, first of all, from a user perspective, we're authenticating to your existing identity services, and those identity services give us information about the user, about the groups they're in, how they're authenticated, and you can have multiple identity providers all connected into Cloudflare, so you can authenticate contractors using an IDP, your internal employees. You can use consumer-based authentication services like Facebook, LinkedIn, or GitHub. All of those can be integrated together to allow you to control access to your applications. But you want to secure devices as well, so the device agent that I talked about earlier that connects devices from a connectivity perspective, that device agent also tells us information about the device. Is the disk encrypted? Is the firewall enabled? Is it running the latest version of the operating system? All that information can be associated with the user and their request and also used in a policy to control access to the application. And we integrate with CrowdStrike and Microsoft Intune and SentinelOne and other third parties that can also provide information, so you can write a policy to make sure that they can only connect to the application network if their device is secured by that solution. So now you can see here we've got a diagram of how all of these different environments can be connected together all through Cloudflare. But connecting all of this together, having visibility into users, it really doesn't mean anything unless you can actually write a policy to define who gets access to what. So this really is kind of the critical part of this whole endeavor. Now, how do you write policies and where do they live? Well, we've got two main services that control access to all of the things we're talking about. One is our secure web gateway, and that is looking at traffic that's typically going for the Internet. You can write policies to make sure that users aren't accessing sites that have malware or part of phishing campaigns or so on and so forth. And then we have our Zero Trust Network Access Service, which is what's routing access into your private applications and networks. And both of these services are sharing common pieces of policy, such as what the device looks like, the user identity, the network they're coming from. We even have things like DLP profiles that allow us to look at that traffic and determine whether or not the content is sensitive and should be going where it's going. So let's walk through a few examples of these policies in action. So here you can see we have an employee on a secured device, and they're accessing a database administration tool. And because of that secured device, the policy says, yep, allow them to connect, route that traffic across our service and into that downstream application. But then we have a contractor here working in another country. We want to give them access, but we only want to give them access to the web administration tool, not to the database itself. And we want to isolate that access on a browser that's running on our edge that gives us more control over what they can do in that application. So here are some other examples, and this is looking a little bit more at what the policies look like. And we can see one is blocking high-risk websites. So I mentioned our secure web gateway, which is looking at all traffic leaving devices and networks through to the Internet. And you can just say, you can pick categories such as malware or spyware or bot campaigns or anonymizers. And what that's doing is we are maintaining these categories within Cloudflare so that you can just say, I don't want these bad categories people visiting them, and we make sure that we're maintaining an up-to-date list of IPs and domain names that constitute these types of threats. And then you just write a block rule, and now all traffic, no matter where they come from, it's going to be blocked to those sites. You might also want to allow sites, but you feel a little risky, but say your marketing department still needs to use social media, so you can write here an isolation policy where you say, I'm going to allow access to these sites, but when I do, we're going to use our remote browser isolation, and I'm going to disable their ability to print or download files or upload files, and gives you controls over what they can do on that website. And then we have other policies. As I mentioned, we use our DLP profiles. So our DLP profiles can be based on pattern matching. We have pre-built DLP profiles for financial information, for health information. You can also update your own data sets of information that you're trying to look for and analyze. And then those DLP profiles can be used to say, for example here, if the request is for something that constitutes customer account information, and the request is going to a domain which is one of the company applications, but the user is in contractors, then we're going to block that. So we're going to block contractors from transferring any customer account information from any company application. And then the other example here is preventing the upload of sensitive company information to non-approved cloud storage. So here we can see profiles such as customer accounts and finance information, and we're identifying traffic that's going to Dropbox or Google Drive or Microsoft Drive, and we're explicitly looking at the HTTP method put, and then we're blocking that as well. So thanks for listening. Just been walking through some examples of how you can totally recreate your corporate network on Cloudflare. If you want to learn more, go visit our channels on YouTube, on Cloudflare TV, or read more on our product documentation at developers .Cloudflare.com.