Software Defined Perimeter (SDP): A Rick the Toolman episode.
By Rick Howard
May 23, 2022

CSO Perspectives is a weekly column and podcast where Rick Howard discusses the ideas, strategies and technologies that senior cybersecurity executives wrestle with on a daily basis.

Software Defined Perimeter (SDP): A Rick the Toolman episode.

Listen to the audio version of this story.

I’ve been binge watching  “Marvel Agents of Shield” over at Disney plus for the last month or so. I have to say, if you’re a Marvel fan or a science fiction fan or even a super spy fan, this little TV show that ran on ABC from 2013 to 2020 is really quite good. Created by Joss Whedon of “Buffy the Vampire,” “Firefly,” and “The Avengers” fame, the production values are really quite high for a TV show created almost ten years ago and it's the perfect mindless entertainment I’ve been craving during the Pandemic. 

I don’t know about you but, these past two years, I’ve been steering clear of anything too real or too serious with the Howard family’s evening entertainment activities. I just don’t need any more stress in my day-to-day life as I try to forget this dumpster-fire-of-a-world right now, with us just coming out of a Pandemic, a senseless war in Europe, and assaults on many fronts of our democratic liberal values in favor of authoritarianism. And “Agents of Shield” is a perfect palate cleanser.

There’s this trope in spy movies where the good guys eventually decide that they need to talk to the bad guys before the last act happens when they all try to kill each other. Watching “Agents of Shield” last night, I had an epiphany. I noticed that the good guys don’t grab an Uber, rock up to the bad guy’s evil lair, knock on the door, and say,” Hey, got a minute?” No, that’s just not how it's done. Instead, the good guys meet with the bad guys at some agreed-upon location nowhere near the evil lair. Some vetting gets done on both sides in the form of weapons pat-downs and insult trading, which are usually quite funny, and then, once both parties are satisfied, the bad guys put bags over the good guy’s heads and whisk them off to some safe house somewhere.

And I said to myself, “Hmmmm, isn’t that weirdly similar to how a Software Defined Perimeter (SDP) works?” And I hear what you're thinking. I feel you looking down your noses at me saying, “Only Rick could connect the dots from superhero stories to probably the best innovation in Identity and Access Management since AT&T patented the idea of two-factor authentication in 1995.” Well, yes, of course that’s true. And you’re welcome. But I guess that means we need to break out the Rick-the-Toolman toolbox and explain what SDP is, how we got here, and why it represents a better architecture for our zero trust first principle strategy.

Perimeter defense in the early internet days.

When the internet really started to take off for commercial and normal everyday people in the mid-1990s, the security architecture of choice was something called Defense-in-Depth. The idea was that you would place multiple security tools in the path of any would-be adversary group and if they managed to get past the first one, then the second one would stop them. If that failed, then the third one would, etc, etc. When security professionals talk about the security stack today, this Defense-in-Depth collection of security tools is mostly what they are referring to. In those early days, most of us only had three tools—a firewall, an intrusion detection system, and an anti-virus system—and that established the defense perimeter between our organization and the internet. In other words,  we used the security stack to create a barrier between the wild, wild West that was the internet and our bastion of commercial and personal activity. 

That was great if you worked inside the perimeter all day long and didn’t have to go to the internet for anything. But what happened immediately were all these exceptions. Our stated security policy was that we were going to block everything at the firewall that we didn’t trust. But for all kinds of good business reasons, we had to punch holes through the firewall to allow contractors, partners, and employees who operated outside of the firewall to access the things they needed inside the firewall. Sometimes, we would just open up the firewall with specific rules for each exception. By the 2000s though, we would just give them access to those resources via a Virtual Private Network (VPN) connection.

The difference between coming straight through the firewall and using a VPN can be found at layer 3 of the TCP/IP stack; the network layer. With a VPN, the client establishes a secure tunnel, an encrypted path at layer three, to the VPN server on the inside of the perimeter. Think of coming straight through the firewall as akin to walking through the front door of your office building. As you go through the card reader and the security checkpoint, everybody can see what you’re doing. With a VPN though, it’s like you’re in a Star Trek TV show. You walk into a transporter room on the outside of the firewall and pop out on the inside of the firewall completely bypassing any security.

This is great for the VPN user in that nobody in the middle of that communications path can observe the data that both sides are transmitting, especially the firewall. It’s all encrypted.  The bad news for the security team is that you can’t monitor traffic for malicious behavior. If you’re running all that traffic through a security stack (like a firewall and an intrusion detection system), it doesn’t matter. Whatever magic you thought your security stack was doing isn’t happening because it can’t see the data.

Both architectures (straight through the firewall and VPNs) are just poor designs. Leaving holes in the firewall for employees to get through also provides bad guys the same opportunity. If they manage to sneak through one of the holes, they basically have access to everything inside the perimeter. VPNs are worse in that the tunnel completely bypasses the security stack.

In our “Agents of Shield” analogy, this architecture is similar to the good guys rocking up to the bad guy’s evil lair and knocking on the door. They know where it is and now it’s just a matter of time until they find an unlocked door or open window that they can sneak through. 

And you're asking yourself, if the spies in the movies know better than this, why is the security community doing it? Isn’t there a better design? Of course there is.

Software Defined Perimeter becomes a new model.

In the early 2000s, the U.S. military started experimenting with the idea of de-perimeterization under the project name, “the Jericho Forum.” The idea was to decouple the identification and authorization functions away from the sensitive workload. In other words, you wouldn’t connect to a system by going through the firewall or through a VPN tunnel,  and then try to log in to it. Instead, you connect to a separate system, an SDP Controller outside the firewall, that verifies your identity and validates that you have a need-to-know and a need-to-access. If you’re authorized, then the SDP Controller establishes a VPN-like tunnel connection between you and the workload, but to nothing else. That system hid the workload, and all the workloads, in a kind of “Black Cloud” as the DOD called it. In other words, any random bad guy on the internet couldn’t easily see or find the sensitive workloads protected behind the perimeter. All they could see is the SDP controller handling the identity and authorization function. This is more akin to the “Agents of Shield” model and to our zero trust strategy. You go to a mutually agreeable spot, validate each other, and then get whisked off to a safe house, not the entire evil lair. Unfortunately, the DOD never built it. 

In 2010, Google announced that it had been breached by a massive Chinese cyber espionage attack, “Operation Aurora.” In the weeks that followed, we learned that there wasn’t just one Chinese government entity operating inside the Google network. There were three: the Chinese equivalents of the FBI, the Department of Defense, and the CIA. And in a nod to government bureaucracies everywhere, they each didn’t know the other two were in there until Google went public with the information. 

Fun fact: my editor, John Petrik, reminded me that one of the indicators of Chinese government involvement was the time when the attacks occurred; mostly between 9:00 and 5:00 Shanghai time. It was as if the Chinese hackers were checking in on a time clock. I remember back in those days when we all thought how significant time zones were in attribution. If the attacks occurred between 9:00 and 5:00 Moscow time, then of course the Russians did it. In hindsight, that seems a bit naive. Today, if I'm planning an offensive cyber operation, there would always be a false flag component to emulate some known adversary and leave behind timezone traces that match. I'm just saying.

In response to the Aurora attack, Google’s Site Reliability Engineers (SREs) redesigned their internal security architecture from the ground up using the concepts of de-perimeterization and the zero trust philosophy. A few years later, they released a commercial product called BeyondCorp that incorporated many of the ideas they developed internally. 

In 2013, the non-profit Cloud Security Alliance announced their Software Defined Perimeter (SDP) Initiative and released their 1.0 specification a year later. In 2020, NIST released their Zero Trust Architecture document that outlined some of the early discussion of software defined perimeter. Finally this year (2022), the Cloud Security Alliance Announced version 2.0 of its specification document.

Today, de-perimeterization is known in the industry as Software Defined Perimeter; an unfortunate name because, as I have said in other essays,  it has nothing to do with perimeter defense at all. It completely decouples the login process from the workload. If I were in marketing, I would call it something like a Software Defined Wormhole or Black Hole Identity and Authorization or maybe even, Identity and Authorization Ducts. Maybe I should just stick to cybersecurity.

The future of SDP.

To my mind, SDP is by far a superior cybersecurity first principle architecture and is better suited to help us accomplish our zero trust initiatives. It comes built in with an identity and authorization function and keeps access to work loads limited to a need to know. Unfortunately, the architecture is not widely known despite the best efforts of the Cloud Security Alliance and the NIST. In a survey done by the Cloud Security Alliance back in 2020, only a quarter of the respondents even had heard about it. For those that did, they said the number one reason that prevented adoption is that it was too hard to rip and replace existing security technologies to do so. That is unfortunate. If zero trust is indeed a cybersecurity first principle, SDP is most likely the long-term path to get there. It has the added benefit of paralleling the “Agents of Shield” model. 

SDP Timeline.

1996

  • A Microsoft employee developed the peer-to-peer tunneling protocol, or PPTP, the precursor to modern VPNs

2001

  • James Yonan developed OpenVPN and used GPL (GNU General Public License) to publish it.

2004

  • The Jericho Forum began talking about De-perimeterisation. 

2007

  • The US military incorporated some of those ideas into  their Black Core initiative in 2007.  
  • Somewhere between 2007 then and 2010, the community started to refer to De-perimeterisation as Software Defined Perimeter or SDP.

2010

  • Google got hit by a massive Chinese cyber espionage attack coined Operation Aurora, their Site reliability Engineers rolled out an internal version of SDP as part of a network redesign. 
  • John Kindervag releases his "No More Chewy Centers: Introducing The Zero Trust Model Of Information Security,” that formalizes the zero trust theory for the community.

13 November 2013

  • Cloud Security Alliance Announces Software Defined Perimeter (SDP) Initiative
  • Google launched a commercial offering of their internal SDP architecture called Beyond Core. 

April 2014

  • Cloud Security Alliance releases its “SDP Specification 1.0.”

2017

  • Evan Gilman and Doug Barth publish their Cybersecurity Canon Hall of Fame book, "Zero Trust Networks," in which they outline how they built their own SDP and zero trust networks. 

August 2020

  • NIST releases their Zero Trust Architecture document that outlines some of the early discussion of software defined perimeter. 

10 March 2022

  • Cloud Security Alliance Announces issues Expanded Specification for the Software-Defined Perimeter (SDP)

References.

Book Review: Zero Trust Networks: Building Secure Systems in Untrusted Networks,” by Ben Rothke, Cybersecurity Canon Project, Ohio State University, 17 October 2018. 

Cloud Security Alliance Issues Expanded Specification for the Software-Defined Perimeter (SDP),” Cloud Security Alliance, 10 March 2022. 

CSA Announces Software Defined Perimeter (SDP) Initiative,” Cloud Security Alliance, 13 November 2013. 

"Jericho Forum Commandments," by the Jericho Forum, The Open Group, May 2007.

"No More Chewy Centers: Introducing The Zero Trust Model Of Information Security," by John Kindervag, Forrester, 2010.

Software-Defined Perimeters: An Architectural View of SDP,” by Daniel Conde, IEEE, March 2017.

Software Defined Network (SDN) or Software Defined Perimeter (SDP) … What’s the Difference? | Waverley Labs,” by Juanita Koilpillai, Waverleylabs.com, May 25, 2016.

Software-Defined Perimeter (SDP) Specification V2.0,” by Jason Garbis and Juanita Koilpillai, Cloud Security Alliance, 2022. 

THE HISTORY OF VPN,” by VUK MUJOVIĆ, Le VPN, 17  August 2018. 

The State of SDP Survey: A Summary,” by Bob Flores, Jason Garbi, Junaid Islam, Juanita Koilpillai, Shamun Mahmud, Cloud Security Alliance, 9 June 2020.

"Vision for a Net-Centric, Service-Oriented DoD Enterprise: Department of Defense Global Information Grid Architectural Vision," by DOD CIO, June 2007.

"Visioning White Paper: What is Jericho Forum?" by Nick  Bleech, Gary Yelland, Steve Purser, Steve  Greenham, Shane Tully, John Walsh, and David Gracey, February 2005.

VPN History & the Future of VPN Technology,” CactusVPN, 3 September 2018. 

VPN History – Everything You Need to Know about VPN Development over the Past 25 Years (and a Quick Glim,” By Septimiu-Vlad Mocan, TechNadu, 4 February 2020. 

Zero Trust Architecture: NIST Special Publication 800-207,” by Scott Rose, Stu Mitchell, and Sean Connelly, Cybersecurity & Infrastructure Security Agency (CISA), Department of Homeland Security (DHS), August 2020.

"Zero Trust Networks: Building Secure Systems in Untrusted Networks," by Evan Gilman and Doug Barth, Published by O'Reilly Media, 30 June 2017.

Related Cyberwire Episodes

18 MAY 2020

CSOP S1E7:: Cybersecurity first principles: zero trust


31 AUG 2020:

CSOP S2E7:: Identity Management: a first principle idea.


07 SEP 2020:

CSOP S2E8: Identity Management: around the Hash Table.

  • Hash Table Guests:
  • Helen Patton - CISO - Ohio State University (2)
  • Suzie Smibert - CISO - Finning
  • Rick Doten - CISO - Carolina Complete Health (2)
  • Link: Podcast (21)
  • Link: Transcript
  • No Essay