ESG Blog: Software-defined Perimeter (SDP): Important Initiative, Ineffective Name
SDP is all about creating dynamic and secure network segments between a source and destination system.

Apr 10, 2018
Jon Oltsik   ESG Blog: Software-defined Perimeter (SDP): Important Initiative, Ineffective Name
Author: Jon Oltsik

 

confusionFor the past year or so, I’ve made the following statement, "No one has an SDP budget, but everyone has an SDP requirement."

Why the disconnect? Let’s start with the demand side. At large organizations, technology users are a disparate group of employees, business partners, consultants, customers, business partners, suppliers, etc. Individuals within each group access business applications and technology services from different devices and locations, while applications reside in data centers, public clouds, at SaaS service providers, etc. 

Each end of the access pipe is dynamic, yet IT and security professionals must figure a way to provide users with seamless and secure access to business applications and IT services. Old standards like RADIUS servers, 802.1X, and VPNs simply weren’t built with these use cases in mind.

Enter SDP. In my view, SDP is all about creating dynamic and secure network segments between a source and destination system. Typically, the source is an endpoint system and the destination is a business application, but this isn’t always the case (the source could be an IoT devices, or both source and destination could be two cloud-based workloads for example). Additionally, the source can be any type of device in any location and the destination can be any type of application or service in any location, accommodating for mobility, BYOD, and cloud computing. 

SDP connections rely on strong authentication of users and devices and then enforce access policies based upon identity attributes (i.e., users, device type, device profile, locations, etc.) and other risk factors. SDP also sets up a direct and encrypted link between the two systems. In other words, there is no need to "hairpin" the connection through a VPN on a corporate network.  Finally, users/devices are permitted to access certain assets on the network but remain blind to all other assets (where they don’t have permission).

SDP is timely and meets lots of enterprise requirements so there should be universal demand for this type of technology, right? Unfortunately, the supply-side is doing its best to confuse the market by presenting this technology with geeky terminology like:

  • Software-defined perimeter. I’m met with blank stares whenever I use the term in an end-user presentation. The word "perimeter" is most associated with security technologies like firewalls and gateway devices or network architectures like DMZs, so many people tend to associate SDP with things like virtual firewalls rather than dynamic and secure access controls.  You know you are in trouble when you must pause and define a concept. 

  • "Black clouds." This one came out of the US Defense Information Security Agency (DISA) around 2007. The point was to communicate that access controls were enforced on a need-to-know basis so if you didn’t need to know, the cloud (i.e., network) was black or invisible to you. Good concept but the term "black cloud" is also meaningless without a whole lot more detail.

  • Zero-trust networking. I give Forrester a lot of credit for coming up with this one. The problem here is that zero-trust presents network security and access controls from a networking technology perspective (i.e., looking from the network up to the application). I find that most SDP projects are driven by business rather than technical needs, and zero-trust networking means nothing to business planners. 

  • If you want to understand SDP architecture, use cases, lessons learned, and best practices, it’s well worth your time to research what Google has done with BeyondCorp (i.e., the name of its proprietary SDP architecture). Once again however, BeyondCorp doesn’t communicate anything to business, IT, and security decision makers without a whole lot more context. 

I firmly believe that these geeky terms are confusing the market and stalling progress. 

My suggestion is that we abandon the techno-speak and start to refer to SDP as ubiquitous secure access services (USAS). In parsing this term:

  • Ubiquitous, as access controls are designed to connect any user/device, from any location, to any business application or services regardless of whether they are on-premises, reside in public clouds, or live in SaaS data centers.

  • Secure, as access controls are based upon strong authentication, end-to-end encryption, and a trust relationship between source and destination systems. Furthermore, users/devices are provided access directly to authorized applications/services while remaining black-listed from unauthorized applications/services (and the network itself).

  • Access, as USAS is designed to enable approved business access requirements and can be governed by granular access polices. In other words, the driver is business access, everything is else is about how we make this happen. 

  • Services, because access controls are provided to all types of users needing secure connectivity to all types of applications. In other words, USAS becomes a network service, much like file and print became LAN-based network services in the 1990s.

Whether USAS catches on or not, my main point is that IT and security professionals remain in the dark about SDP, zero-trust networks, and BeyondCorp when they should be embracing this technology for secure business enablement. We as an industry need to educate and help the IT and security community rather than continue to confuse them. 


Post a comment