Originally aired on July 8, 2020 @ 12:00 PM - 12:30 PM EDT
Over the past year, AJ Gerstenhaber has spoken to more than 500 organizations on the new frontier of perimeter security. He's learned a lot from all that listening, and wants to "whiteboard it out" with you and your team. He'll talk through the growth of perimeter security over the past two decades and the technology and market forces that have brought us to where we stand today. If you want a simplified perspective on securing the modern perimeter, you'll enjoy this session.
Cloudflare for Teams
Hi everybody. My name is AJ Gerstenhaber and I am in the product strategy group of Cloudflare, helping take Cloudflare for Teams, which is our new team security product suite, made up of two products, Access and Gateway, into the market. Today I'm going to be talking to you about the security perimeter and the way that it's changed over time. So we're going to spend some time talking about what the security perimeter is, what it looked like 15 to 18 years ago, and various factors that have influenced that perimeter and changed the scope of that perimeter over time, and then finally what it looks like today and what some major challenges that businesses may be facing who have traditional security parameters. So what is the security perimeter, right? The easiest way to think of the security perimeter is that if you're a business and you have a castle, the security perimeter is your moat around the castle. It keeps all the things that you need to be able to access, all the tools, all the keys to the castle inside the castle, and it keeps all the bad stuff, like the big scary Internet for instance, out of the castle. So it's an easy way to control what's inside stays inside and what's outside can't come in. So let's start with an example of a business that might adopt a security perimeter. Today we're going to talk about WidgetCorp. WidgetCorp, if you can believe it, sells widgets. So when WidgetCorp got started, let's say that this is WidgetCorp's timeline here. Let's say it's 2005. WidgetCorp is just getting started. They sold enough widgets, they got enough funding that they could start a big fancy office right on the tail end of the dot -com bus, and they are going to build a fancy new office in San Francisco, California, where all their people work and where all their work gets done, where their widgets are made and sold. So in order to facilitate selling widgets, they're a modern business. They're going to need to access, they're going to need to create digitally rather than relying on paper and fax machines and blockbuster video and all the stuff that was cool back then. They are going to build an on-prem data center, and in doing so, they're going to buy and maintain physical infrastructure to support the things that they need to run their business, which at the time, things like email, general corporate apps, internal administrative tools, file sharing systems, and we'll call it general infrastructure. All the business-critical servers they need to be successful doing their jobs. They also will probably need a CRM system to keep track of all the people that they've sold widgets to in the past and that they want to sell widgets to in the future. So this is 2005, and most of the people who work for WidgetCorp are within the four walls of their office. They use desktop computers, so there's not a big need for the ability to go remote, because everybody who needs to be able to access the email and the CRM and the corporate apps are there, right there in San Francisco. So how can we make sure that, in San Francisco, that their business is safe from the outside world? And this is getting in my way, so I'm going to erase it, just like a real whiteboard. Well, WidgetCorp is going to use this opportunity to secure their on-premise tools and build hardware to support what's called a firewall. The firewall does two things. Firewall keeps bad actors from getting in, and it inspects the traffic that's going out to the Internet. So fortunately, around 2005, most of what businesses like WidgetCorp would need to do to do their job doesn't involve going out to the open Internet. They host everything they need in this on-prem data center, so the people in the office can access the email and the CRM system and the corporate applications, et cetera. But if they need to go out to the Internet, WidgetCorp wants to be sure that the people who are navigating on the Internet are doing so in a secure way. The Internet was a very different place back in 2005, so the Internet was probably 90% cat videos and chain forwards. There wasn't a lot of business being done on the Internet, so when users in the SFO office needed to go out to the Internet, the easiest thing you could do is send their traffic through the firewall and do what's called inspecting that traffic to make sure it's not destined for a particularly malicious or objectionable cat video. After they've done that, their traffic would be allowed to go out to the Internet. An important thing to note is that this firewall is rated by bandwidth, so you want to make sure you know how many employees you have on the Internet. It's also really expensive, so two of the biggest expenses setting up WidgetCorp's office in SFO might very well be their on -prem data center and their firewall to protect all the things and build the proverbial moat around their proverbial castle of proprietary widget information. So that's SFO. Let's say, let's jump forward one year to 2006. The WidgetCorp has sold so many widgets over the course of the past year that they are actually going to open a satellite office in Los Angeles County, where they are taking their talents down to Long Beach. They want to be able to sell widgets on the California southern coast. I think it's called the Golden Coast. I think people say that, but they also want to remain lean and make this a profitable operation for their business, which means that, with all likelihood, they probably can't afford to build a second on-prem data center, because it's not just buying hardware. It's then spending the time to make sure that all the tools like their email and their CRM and their corporate applications and their file sharing can easily be replicated to a new data center and then can keep data sources secure between both data centers. So they're not going to do that. That sounds terrible. What they're going to do instead is one of two things. They could build a site-to-site VPN tunnel to send all of the Los Angelans, Los Angelians, Los Angelites. Anyway, they're going to send their traffic up to SFO. They're going to make a little hole in their firewall and allow this VPN traffic from LAX to be able to access all the things just like their on -premise. When you're thinking about the corporate perimeter and networking more generally, this brings up two really important points. The first is remote access. This is people who are not in the office needing to access tools that only exist in the office, thereby remote access, and we can do that by giving them a VPN tunnel, which means that we are giving them an IP address that allows them to effectively pretend that they're in the office, or we can do something else. And if you want to really put your stake in the ground, you can give a private line of the Internet called an MPLS link that would traverse all the way from LAX, SFO, and is a good example of what's called wide area networking, or WAM. This is also very expensive, very, very, very, very, very expensive, and it's also rated on bandwidth just like your hardware firewall. So the more bandwidth you have going from SFO out to the Internet, from LAX to SFO out to the Internet, two things are happening. One, you're expanding your costs a little bit. You're increasing the complexity of your network, and you're having to allow more and more things into your moat or into your castle past your moat, but you're also increasing cost based on how many users are on the network and what all traffic needs to go out to the Internet. Again, fortunately, most of the people in LAX only need access to email and your CRM system and your corporate apps. You don't have to go out to the Internet for those, so your costs are going to maintain relatively stable. One more important note here is that when people from LAX want to send their traffic out to the Internet, they have to make an extra stop by going to SFO before they can go out to the Internet, and that creates latency for those users. And of course, in 2005, I'm pretty sure I still had dial up, so I don't think latency was something that was really on my mind, but it does make a difference because it's faster to go from LAX to the Internet than it is to go from LAX to SFO to the Internet. So another thing to keep in mind. This actually starts to complicate even further because 2005 and 2006 were really, really good years, but in 2009, Widget Corp. wanted to go regional with this business. They had done so well in SFO and so well at LAX that they wanted to add an office in Phoenix, DFW, and Denver. So now, if you can imagine, this is starting to complicate a good amount more. Do we want to set up physical private links, MPLS links, from the Phoenix office back to San Francisco to the DFW office back to San Francisco to the Denver office back to San Francisco, or is that going to be too time and resource intensive while introducing latency for those people who are getting increasingly further and further away from San Francisco going to the Internet? So let's add one more complication to this mix. As your business grows, your needs grow, and this means that at the same time, outside of the four walls of their office, they're installing contractors all over America and an agency partner down in, based on my map, what I can only imagine is Juarez or something similar, perhaps Tijuana, to support their growing business, and that means that all these people who are now really outside the trusted network still need to have access to these internal systems, and now we're getting a little convoluted. Now it's hard to know what belongs on the network, what doesn't, what needs to go out to the Internet, and all the while, your hardware and your MPLS links and your VPN tunnels are all rated against bandwidth, so the more and more and more people that need to be able to use them or need more bandwidth, the higher your cost is going to get. So there are a couple things that you can do here. Theoretically, you could add what are called direct Internet access points or Internet egress points, which would mean putting firewalls around PHX and DFW in Denver. If you could imagine, this would be a huge capital expenditure. You could always set up an additional regional office where maybe all your Internet traffic for your southwest region went out through Denver, but that means needing to replicate your on-prem data center as it exists in SFO. All I'm saying is that it's not hard to imagine that it becomes really complicated for businesses to know how to approach this. You don't know which direction you're going to be growing, and the Internet is constantly changing, and this has effectively deeply complicated your remote access strategy. So originally, the idea of this perimeter where users were trusted when they were in SFO and everything outside of SFO was by default not trusted has been severely challenged because Denver, Phoenix, DFW, LAX, contractors all over the world, they're not going to be coming from that office. You're going to need to either give them access to sensitive systems, give them VPN access, or something else that's going to effectively challenge the very idea of the security perimeter. So it's no longer as simple as trusted inside, untrusted outside. As you can imagine, we're going to jump ahead to 2014. Widget Corp had a really, really good couple of years managing their regional offices, but something's starting to change. Now, one of their largest capital expenditures is just in maintaining their email and their CRM. It's become so vast, they have so many customers, and they have so much information flowing within their business, that this is one of their largest expenses. Fortunately, there are two things that are happening right now that are drastically changing the way that Widget Corp has to and can choose to think about hardware delivered services. That is the adoption of SaaS tools, and SaaS tools are going to start slowly over time replacing the on-prem network that they relied on. Their email, their CRM, their file sharing, and their infrastructure are all going to up and leave their data center and move to the Internet. So now, your email becomes Office 365, maybe G Suite. Your CRM becomes SFDC, because Salesforce is effectively the only one left standing at this point. Your file sharing might become Box or perhaps Dropbox, and your general infrastructure, everything you need to power your widgets, arguably probably the largest expense that you would experience within your on-prem data center, is going to shift to cloud compute. This is one of the biggest pieces of the puzzle. GCP and Azure have made it cheaper for you to stop refreshing your hardware that lives on-prem and send it all out to the open Internet, where you can rent the amount of hardware that you need to be successful, and it becomes infinitely scalable for your business. So now, your costs effectively become more predictable, and everything that you need to do becomes a little bit easier once you can shift to the cloud, and you no longer need to rely on maintaining on-premise boxes. But what does this mean? Now, everything that you have, your hardware and your hardware, your firewalls and your networking, were rated for cat videos and chain forwards. And sure, your network has grown over time, and you might have developed an ability to accommodate that growth in person traffic, but as all your business traffic shifts out of the on-prem data center and out to the Internet, that's going to 10x everything that's happening to your poor MPLS links, your poor VPN tunnels, and your hardware firewall. So now you're faced with a choice. You're effectively forcing modern business through legacy hardware, and worse, through legacy security controls. You're trying to make your perimeter, your security perimeter, effectively cover the Internet more generally, and as you can see, while it might save you a little money to move to SaaS tools, it's going to cost you a whole lot more money if you need to route your legacy setup through your firewall out to the Internet for every single thing that your employee needs to do to be successful. So let's go ahead and jump to 2020, because I think I can help simplify this a little bit. Something really big happened in 2020 that some of you may be familiar with. It may have impacted some of you individually, but there's a global pandemic, and that pandemic not only has shifted your on-prem resources, your data center, and everything that lives in it out to the Internet, it's taken your people out of the four walls of your data center, or out of your office, out of the four walls of your office, out of the four walls of Denver and Phoenix and DFW, and your agency contractors are somewhere else. No one is where you expect them to be. So at this point, really, what is your corporate perimeter? It's simply the idea that you have people outside your network and things outside your network and some legacy hardware that's trying desperately to connect the two. And again, it's really easy to appreciate how a business might have found themselves in this position. Effectively, this doesn't happen overnight. This happens over a long period of time where there are gradual changes to business and gradual changes to the Internet that effectively impact the way that you think about networking. But especially with the rise of remote work in 2020, something's got to give. So what I would like to do is switch gears a little bit and maybe try to define the modern security perimeter. Based on what we know today, after what's happening over the last 15 years, how can we design a new perimeter that might make more sense for business? So let's jump to a brand-new whiteboard here. If you no longer have a trusted network and all of your workloads are effectively in the cloud, maybe a little is left on-prem. But the Internet now includes your internal tools and the open Internet, which, of course, you need to be able to operate on in order to effectively do business. And your people have all effectively left the office. Maybe one day they'll go back. We got a larger high-rise in SFO, which is nice. I'm going to draw a third floor. Widget Corps really had a great year, or a great 15 years. Your people are far away from your things. Your things are far away from the office. What can we do in order to help develop a new perimeter? Let's instead think about what the actual goal is. What do we want to be doing? Really, we want to secure our internal tools so that only trusted people, wherever they are, on whatever device or whatever network they're coming from, need to be able to access your internal tools, and they need to have a secure experience as they navigate the open Internet. So, really, it's about access. It's about access to your internal systems, things that are proprietary to your business, and access to the Internet in a safe and secure way. So, if all these tools are now being delivered via the cloud or via edge networks, shouldn't your security frameworks also be delivered via edge networks? At the core, if we're trying to deliver secure access to both internal applications and to the Internet for your people, you need two things. You need a bouncer for your internal applications, and you need a bodyguard for your people as they navigate on the open Internet. So, if the goal is to deliver consistent security policy in front of applications, regardless of where the requests come from, that's kind of the idea of zero -trust networking. So, if you're not familiar with Zero Trust networking, and I tried writing this out earlier, and you can't write as fast as I talk, but zero -trust networking is the idea that there is no trusted network, just like we drew out the perimeter with the castle in the moat. All that's gone. All that we have left standing today is people and applications and a gap between the two. So, we need a way to ensure that each request to each application is validated and authorized by a either first or third -party source that you've deemed valid to authorize that request. So, what this means is that you just need to make sure that your people can access the tools they need to do their job and can access the Internet in a secure way. So, let's talk about edge networks for a second, because this is where Cloudflare comes in. Cloudflare runs a globally distributed network with over 200 points of presence that historically has provided security performance for public-facing websites, securing inbound requests for the world's most mission-critical assets, right? But let's talk about how you can make that network become your perimeter and effectively work as your security controls. So, to illustrate this, I'm going to draw a picture of a cloud there. Let's talk about the bouncer first. So, if you want to make sure that you have a bouncer in front of your internal applications, what you want is to serve something in front of those internal applications to everyone who could possibly be trying to access them. So, that means that let's just draw out here, for your internal tools, let's say this is something that lives in GCP, and it's an administrative tool that you've moved out to the Internet, but you now have no good way to serve to your users, so you're still using a VPN and a subnet to make sure that your people can access what they need to. So, what we're going to do is we're going to, instead, broadcast that internal tool behind Cloudflare. And what Cloudflare can do, since it's both close to your internal tools and close to your users, is be a low -latency bouncer that can sit in front of your applications and check to make sure that your users, as they navigate on the open Internet, are who they say they are, and should, therefore, be able to access those internal tools. And that works for any sort of tool that you could have. So, anything that shifts to the Internet, you can rely on a third-party edge network like Cloudflare to be near your users and near your applications and provide secure remote access to those applications, so effectively acting as a bouncer for your internal tools. Now, this gets a little more complicated, because Cloudflare has a history of operating as a reverse proxy network, which means that we sit at the DNS layer. It can intercept DNS requests that are destined for specific URLs, just like that. But what if we weren't just at the DNS layer, and what if we don't control the whole Internet? So, how can we sit in the middle of the request from your people to the open Internet? How can we act as a bodyguard as people operate on the Internet? Effectively, again, since we are within 99 percent, within 100 milliseconds of 99 percent of the world's connected population, we have a unique ability to be an extremely low-latency friend near your people, your networks, and everything that happens on the open Internet. So, a couple things are going to happen. The bodyguard is effectively going to replace your firewall. So, we've determined how we can facilitate remote access with cloud networks, rather than relying on a traditional casual remote model, but how can we secure your users like a bodyguard? How can we be the outbound firewall for your users? How can we inspect their traffic regardless of where they're going? Well, that's simple, and that's something that is a bit of a roadmap item for Cloudflare, so I'm not going to get too in-depth with it, but I can tell you about the theory. So, when your users operate on, let's say, a cell phone or a laptop, they might have our 1.1 app installed. 22.214.171.124 is our public recursive DNS resolver that secures users' DNS requests as they operate on the Internet, and effectively is, in some essence, a VPN, because it creates a tunnel from your network, from your user, to Cloudflare's network, but what if we could take that tunnel and use Cloudflare's network the same way that we used our outbound firewall that we had to pay for hardware that was rated for bandwidth that couldn't support the Internet? Shift that model to a network that can support the Internet, like Cloudflare, because we see I think it's 10 % of all Internet requests per day. I think that stat was wrong. Don't quote me on that stat, but if we could send all Internet traffic for all users out to Cloudflare, and then Cloudflare handles the inspection, because Cloudflare is built to support the Internet more largely, then you could feel secure that now, when before you had to sacrifice and choose which of your offices could access the Internet directly, now you can do the opposite. Now you can send all your Internet traffic from LAX, from your partners, from Denver, from DFW, and from SFO straight out to Cloudflare, rather than relying on simple Internet egress points to do the work for you. So, in essence, the modern perimeter is going to be cloud providers that can do one of two things for you, or both. They can give you secure access to your applications and your internal tools, or they can give you secure access to the Internet, which means keeping your users safe as they operate on the Internet by inspecting their traffic and keeping them safe from things like malware and phishing attempts as they operate on the open Internet, which no one controls. So, again, this model will hopefully do a couple of things. It will save cost for businesses that are relying on hardware or trying to force modern business Internet bandwidth through legacy hardware, and it will allow people to have a better experience as they operate on the Internet. Direct Internet breakout points from every user and from every office means that everyone goes straight to the Internet. Today's modern, extremely latency-sensitive user will have a great experience they'll have fast, performant Internet, and you, as the administrator, as the business, WidgetCorp, will know that your traffic is secure, your castle effectively is still intact, even though it's been distributed all over the Internet, but your proprietary ability to sell widgets is consistently safe and moderated. One thing about this model that I think is really interesting is that it's something that we effectively realized was an issue, simply as a result of being a growing business starting around 2010, we maintained VPNs, we had firewalls, we had to give our users secure access to the massive infrastructure that we were running all over the world. So, one of the things that we immediately ran into was this idea that if our users in San Francisco have to VPN to our own infrastructure in Singapore, they're going to have a frustrating, latent experience, but we're supposed to know how to operate on the Internet, we're supposed to be the ways for the Internet, as some people say it. So, in that regard, we weren't using our own network as a core competency until we built the access product to give our own internal users better and secure access to the Internet more generally. So, that is a good example of kind of recognizing our own issues and using our product strategy division as a flywheel to develop new products that now I personally and every other member of the company use every day, because Cloudflare is a lot like Widget Corp in the way that they have branched out into multiple offices all over the world, we've adopted to a modern security strategy, and we host infrastructure all over the world and are responsible for internal applications and internal tools that run our business. In order to access those internal tools securely, we leverage our own cloud network, our own edge network distributed all over the world to authenticate every single request to adopt a full Zero Trust security strategy for our users and the experience that they have navigating through our applications. Okay. I think that's it. I'm going to stay on for another minute. Maybe I'll end my screen share and just talk to you. At any rate, I appreciate everyone coming to listen to my presentation today. I hope you found it valuable, and I hope that this is helpful in the way that you think about navigating the security perimeter. Effectively, again, I really want to stress that it's no one's fault that it got to be this way. It was so fast in the way that the Internet developed and was developed and became a core tool for business that nobody could have really anticipated the needs of business in 2005, 10 years in the future. There are a lot of businesses today that are still sending a lot of traffic through legacy applications or legacy hardware and need a better direct Internet breakout strategy to facilitate that. One thing I'm really excited about over the next year or so is how Cloudflare can actually help those businesses achieve a better strategy to do direct Internet access and to secure your traffic as your perimeter is now the Internet.