I’ve written about Software-Defined Perimeter (SDP) a few times, as I think this model is a strong fit for today’s IT cocktail made up of mobile applications, public cloud infrastructure and pervasive security threats.
What is an SDP? 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. In addition, 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 such as Cisco, HP (Aruba) and Pulse Secure (formerly part of Juniper).
+ Also on Network World: Learning about SDP via Google BeyondCorp +
While definitions vary slightly, SDP is also closely aligned with concepts such as attribute-based authentication. So, SaaS providers such as Microsoft (Azure AD), Okta and Ping play here as well. And old industry veterans like me may also remember Cisco’s 1990s concept titled directory-enabled networking (DEN), a model where 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 such as these:
- 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 connection 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. 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 stated, “You can’t manage what you can’t measure.” With this quote in mind, large organizations should prepare themselves for an SDP effort that involves 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.
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.