Your security stack is moving: SASE is coming.

Some of the good folks at Gartner— Neil MacDonald, Lawrence Orans, and Joe Skorupa— formalized what many of us have known for a while now; that perimeter defense is dead; that it no longer makes any sense to try to put all of our digital assets behind a single security stack or a series of mini-internal-security stacks deployed all over; that it is crazy to backhaul our network traffic in order to accomplish the same. The world has moved on. Our employees still connect to resources in our centralized data centers but they also interact with our organization’s data back at headquarters on their personal and company-provided mobile devices, in SaaS applications, and more and more, within applications running in the cloud and increasingly across multiple cloud providers like Google, Amazon, and Microsoft. I like to refer to these information repositories as data islands.

Beyond the perimeter: Intrusion Kill Chain Prevention or Zero Trust?

Since 2010, network defenders have been generally trying to protect these data islands with two strategies: Intrusion Kill Chain Prevention and Zero Trust. The Intrusion Kill Chain Prevention Strategy involves deploying defensive campaigns designed to defeat specific cyber adversaries; think of installing interdicting controls to your security stack at every phase of the intrusion kill chain for the sole purpose of preventing the success of Fancy Bear, Refined Kitten, and Lazarus, just to name three. The Zero Trust Strategy involves reducing our network’s attack surfaces by limiting employee and customer access to network resources based on need to know. 

When we just had perimeter defense to worry about, implementing these two strategies was hard enough. But now that our digital resources are scattered to and fro across all of our data islands, pursuing these two strategies has become a bridge too far. Five years ago, when most of us just operated a single perimeter, we already had too many tools to manage in our security stack. But It turns out that the service providers we use today on each of these data islands have their own product sets to sell for intrusion kill chain prevention and zero trust. In order to pursue our two grand strategies, network defenders and network operators have to deploy different tools that have the same functionality but operate in different environments and that don’t easily integrate. Consequently, the complexity of orchestrating the security of those data islands with all of those product sets has grown exponentially and the chances of declaring success with our two grand strategies have drastically reduced. 

Enter SASE: the cloud-delivered Secure Access Service Edge.

The Gartner team published their SASE paper in August 2019 and immediately legitimized this incipient category of services. Here is their big take-away:

The digital inversion of usage patterns will expand further with the growing enterprise need for edge computing capabilities that are distributed and closer to the systems and devices that require low latency access to local storage and compute” by connecting "a worldwide fabric of points of presence (POPs) and peering relationships.

In other words, you no longer have to install, maintain, and operate your security stack in one or more internal and central locations and then “trombone” your network traffic back to it in order to get the benefit from it. Instead, the first hop from your user’s device or your organization’s servers, regardless of where they sit in the world, will be to a cloud provider’s SASE service. The SASE service will provide your security stack for all of your users and devices and will also provide efficient peer-routing to the destination. This accomplishes two things.

First, it simplifies the orchestration of your two security strategies. Instead of managing multiple vendor security products, some that perform the same function only in different environments, all traffic goes through a copy of the same security stack with the same policy. If your SASE vendor allows your own DEVSECOPs teams to update the security platform through automation, your ability to deploy defensive campaigns designed for specific adversaries will become easier. If your SASE provider uses a security platform that automatically updates its own intrusion kill chain prevention controls for all known adversaries, then the chances that your intrusion kill chain strategy will succeed will have significantly improved too. If your SASE provider uses a security platform that facilitates zero trust rules through automation, then your chances of successfully implementing your zero trust strategy likewise will greatly improve.

Second, by choosing the right SASE vendor who has established the essential peering relationships with the key content providers that you most likely will use, your network latency will be drastically reduced. That sounds complicated I know. 

Some necessary history.

Let me simplify it by diverging a bit to discuss how the Internet has evolved since inception. In Andrew Blum’s "Tubes: A Journey to the Center of the Internet,” he described this evolution. He would probably hate my reduction of his ideas, but basically the internet has gone through several phases:

In 1969, UCLA and the Stanford Research Institute established the first internet connection. As Blum would say, the internet took in its first breath.

In the 1970s, Vint Cerf and Robert Kahn invented TCP/IP and by 1983, TCP/IP became the standard internet communication protocol. At this point, the internet was just one large network. There were other private networks, but they couldn’t talk to each other.

In 1989, Yakov Rekhter and Kirk Lougheed invented BGP (on three cocktail napkins at a internet conference) as a temporary measure to connect the internet to the other private networks. BGP became the de facto way to do this even today.

In 1995, the National Science Foundation let a contract to establish four main hubs of internet traffic and converted the original mesh network into a hub and spoke network:

• Sprint NAP in Pennsauken, New Jersey
• Ameritech NAP in Chicago
• Pacific Bell NAP in San Francisco
• MAE-East NAP in Virginia

By the late 1990s, a bandwidth problem emerged called the Chicago problem. If my business lived in Minneapolis, Minnesota and I wanted to send an email to another business in Minneapolis, that traffic would have to go all the way to Chicago before it would get delivered. The solutions that emerged were Internet Exchanges (IXs) located in regional areas. They would provide the local connectivity and would only send traffic to the big hubs when needed. 

Fast forward to the early 2010s. Content providers like Google, Netflix, Akamai, and others decided it was in their best interests to build their own high speed networks to support their own customers. They started laying their own fiber across the globe. Today, these content providers own over 50% of the fiber deployed across the world as opposed to the traditional network providers like ATT and others. And here is the kicker. The content providers would plug their networks straight into the Internet Exchanges; a process called peering. So, if I am a GSuite customer, instead of my traffic going to my internet service provider to the local internet exchange to one or more of the big internet hubs in order to reach the front door of the Google network, because of the peering network, it goes to the Internet service provider, to the internet exchange and right into the backdoor of the Google network.

And thus SASE.

Which finally brings me to SASE. In August 2019, Gartner coined the SASE phrase, but companies like Opaq, CATO, and Palo Alto Networks have been providing the service for a few years.

The SASE vendors install a security stack into the same data centers as the Internet Exchanges and peer with the same content providers like Google and Netflix. The customer's first hop, regardless of the data island they are sitting in, is through a one of the SASE vendor’s nodes. The SASE vendor uses the same shared responsibility model as cloud providers do. They maintain and secure the physical facilities and keep the blinky lights running on the network and security gear. The customer keeps the security policy up to date on the security stack.

For example, let’s say that your organization is a Google Suite shop. Your employees use all the Google Apps to get their work done: GMAIL, Google Drive, Google Calendar, Google DOCS, etc. By using a SASE vendor that peers with the Google network, your employees will go directly to whatever data and workload source they require without having to traverse the entire internet to get to Google’s front door. Your second hop is not to the internet, it is to the Google network. The key is that no matter where the data originates from --the traditional perimeter, the data center, employee’s mobile devices, or workloads in cloud environments (IaaS, PaaS, and SaaS)— the data is traversing the same security stack with the same policy that you maintain. 

The benefits are amazing. Customers move their complex network management off their premise and let their SASE vendor manage it. They move their complex security orchestration to their SASE vendor too. It is the perfect solution for small and medium sized businesses who don’t have the resources to manage complex environments and it is a good solution for Fortune 500 company non-essential applications. Within five years, SASE will be perfect for all sizes.

Secure Access Service Edge (Cloud-Delivered) is a fundamental shift in internet data flow on the same level of significance as standardizing on TCP/IP, installing BGP Routing, and instantiating content provider peering relationships. The interesting part is that for the first time in internet evolution, the security solution is built in as the main feature to use it. And, if done correctly, the burden of orchestrating our internal security stacks becomes less complex. We might actually have a chance to achieve our two strategic security objectives of deploying defensive campaigns automatically for every phase of the intrusion kill chain and deploying a realistic and useful Zero Trust policy.

Recommended reading.

"A History of an Internet eXchange Point,” Juan Camilo Cardona Restrepo and Rade Stanojevic, ACM SIGCOMM Computer Communication Review, 2 April 2012 , Last Visited 1 January 2020.

"Google and Netflix Are Teaming Up Against Internet Providers,” Victor Luckerson, Time, 22 May 2014, Last Visited 1 January 2020.

"Google builds its own subsea cable from the US to France,” by Frederic Lardinois, TechCrunch, 17 July 2018, Last Visited 1 January 2020.

"Google Is About to Build Its Own Undersea Internet Cables: The cloud is going underwater.” By David Grossman, Popular Mechanics, 16 January 2018, Last Visited 1 January 2020.

"Google's third subsea cable will pump data from Portugal to South Africa,” by Stephen Shankland, CNET, 28 June 2019, Last Visited 1 January 2020.

"Here's Why Netflix And Google Are Pouring Resources Into Their Own Content Distribution Networks,” by Mark Hoelzel, Business Insider, 3 June 2014, Last Visited 1 January 2020.

"How ARPANET Works,” by Jonathan Strickland, howstuffworks, 28 December 2007, Last Visited 22 February 2020.

"How the Internet Travels Across Oceans,” by Adam Satariano, New York Times, 10 March 2019, Last Visited 1 January 2020. 

"Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains,” by Hutchins, Clopper, and Amin, Lockheed Martin Corporation, 2010, Last Visited 5 August 2019.

"Internet Exchange Directory,” PCH - Packet Clearing House, , Last Visited 1 January 2020.

"ISP Tiers: Internet Service Provider 3-Tier Model,” Thousand Eyes, , Last Visited 1 January 2020.

“MAE-East,” by Revolvy.

"Open-IX: Netflix and Google’s Plan to Break Out of Equinix’s Gilded Cages,” by Yevgeniy Sverdlik, DataCenter Knowledge, 18 September 2014, Last Visited 1 January 2020. 

"Pull Your Head Out Of The Sand And Put It On A Swivel: Introducing Network Analysis And Visibility," by John Kindervag, Forrester, 23 January 2011, Last Visited 1 January 2020.

"The Art of Peering: The Peering Playbook,” by William B. Norton, DrPeering International, August 2010, Last Visited 1 January 2020.

"The Future of Network Security Is in the Cloud,” by Neil MacDonald, Lawrence Orans, and Joe Skorupa, Gartner, 30 August 2019, Last Visited 9 January 2020.

"The History of Border Gateway Protocol,” by Logan Rivenes, Datapath.io, 14 December 2016, , Last Visited 1 January 2020.

"The long life of a quick ‘fix:’ Internet protocol from 1989 leaves data vulnerable to hijackers,” by Craig Timberg, The Washington Post, 31 May 2015, Last Visited 28 February 2020.

"The three-napkins protocol: Quick fix for early internet problem left web open to attack,” by Craig Timberg, Stuff, 2 June 2015, Last Visited 28 February 2020.

"Tubes: A Journey to the Center of the Internet,” by Andrew Blum, Published by Ecco, 1 January 2012, Last Visited 10 March 2019.

"Von Clausewitz on War: Six Lessons for the Modern Strategist,” by Willie Pietersen, Columbia Business School, 12February 2016, , Last Visited 1 January 2020.

"When to peer and when to use transit,” DE CIX, Last Visited 1 January 2020.

List of acronyms.

CASB: Cloud Access Security Broker

DNS: Domain Name System

FWaaS: Firewall as a Service

Remote Browser isolation Capabilities.

SASE: cloud-delivered secure access service edge

SWG: Secure Web Gateway

UEBA: User and Entity Behavior Analytics

WAAP: Cloud-based Web Application and API Protection

WAF: Web Application Firewall

ZTNA: Zero Trust Network Access