Networking

Software-Defined Perimeter (SDP) Security Essentials

I’ve written about SDP (software-defined perimeter) security a few times, as I think this model is a strong fit for today’s IT cocktail made of mobile applications, public cloud infrastructure, and pervasive security threats.

Just what is an SDP anyway? The model is really based upon the “black cloud” concept coming out of the Defense Information Systems Agency (DISA) where network access and connections are allowed on a “need-to-know” basis.  Similarly, the Cloud Security Alliance (CSA) refers to SDPs as “on-demand, dynamically-provisioned, air gapped networks.”

Several vendors, including Cryptzone and Vidder, actively market SDP offerings, while Google’s BeyondCorp is a homegrown SDP project that Google has made public and highly-visible. While these efforts clearly fall under the SDP category, I viewed the SDP model a bit more broadly. SDP is clearly associated with numerous innovations and initiatives of the past including next-generation firewalls, network access control (NAC), and even 802.1X, so there are plenty of SDP-like solutions from vendors like Cisco, HP (Aruba), and Pulse Secure (formerly part of Juniper).

More Software-Defined Perimeter (SDP) Definitions

While definitions vary slightly, SDP is also closely aligned with concepts like attribute-based authentication, so SaaS providers like Microsoft (Azure AD), Okta, and Ping play here as well. And old industry veterans like me may also remember Cisco’s 1990s concept of “directory-enabled networking (DEN),” a model in which network directories governed who could connect to what. SDP is quite similar to this visionary approach.

So SDP is well-aligned with burgeoning requirements and there are plenty of individual technologies in the SDP spectrum, but enterprise organizations can’t simply buy an SDP widget, deploy it on their network (or in the cloud) and voila, have a fully-functional SDP solution. Rather, large organizations interested in the SDP concept must consider things like:

  • Strong authentication up-and-down the stack. The SDP architecture defines a number of connection types including client-to-gateway, client-to-server, server-to-server, and private cloud-to-public cloud.  Each of these connections depends upon strong authentication from layer 2 or 3 up to layer 7, and this then mandates numerous technologies for authentication (i.e. biometrics, tokens, smart cards), encryption key management (key generation, key distribution, key rotation, etc.), certificate management, and PKI.Now cloud providers can help out with some of this burden and emerging standards like FIDO will also reduce the load, but in my humble opinion, few civilian organizations have thought through the ramifications of authenticating every transaction and encrypting every network session. This must be done strategically or it becomes an operations nightmare and IT risk — if I corrupt your key management servers or CA, you are hosed.
  • Massive efforts for data collection, processing, and analysis. As management guru Peter Drucker said, “you can’t manage what you can’t measure.”  With this quote in mind, large organizations should prepare themselves for an SDP effort that involved collecting, processing, and analyzing all types of data about endpoints, users, network flows, directories, authentication systems, threat intelligence, etc. And for SDP to work as advertised, all of this data collection, processing, and analysis must happen in real-time.To accomplish this, large organizations may need to gather new types of data, integrate cloud-based data sources into the mix, normalize disparate data formats, and build a distributed data management architecture that can handle the scalability requirements for this type of real-time data processing. It’s true that you can phase this effort in over a few years but CIOs and CISOs should still plan accordingly.
  • Granular business policies and enforcement decisions. As organizations gain the capabilities for fine-grained access controls, they will also have to figure out when and how to use them.  Based upon my experiences, this is harder than it seems and involves collective and thoughtful analysis and decision making across business, IT, and security executives. The goal? Define the fine line between permissible risk and business process disruption. Note that this may take a fair amount of trial and error to get right.

The Journey to Software-defined Perimeters (SDPs)

I’m a big fan of SDP, it clearly represents the culmination of a number of IT initiatives and will likely anchor enterprise network connections in the years to come. Those organizations that move forward with SDP must do so with eyes wide open — it may involve an IT-based Lord of the Rings-like journey to get there.

Jon Oltsik is senior principal analyst at ESG and founder of the firm's cybersecurity service. Read more ESG blogs here.

You can skip this ad in 5 seconds