CSA's Software-Defined Perimeter Specification, V2: Catching up and Looking Ahead

Earlier this month, the Cloud Security Alliance (CSA) released version 2 of the Software-Defined Perimeter (SDP) specification. We’ve collectively experienced a great deal of change in the information security industry since the first version of this specification was released in April 2014, especially in the realm of Zero Trust security, and it was time for a refresh and update. While version 1 of the SDP specification doesn’t mention “Zero Trust,” it’s clear that Zero Trust and SDP share common roots; in fact, many Zero Trust models specifically reference SDP, and it was important for us to include this in the updated SDP spec.

The principles and goals of SDP are now fully mainstream as part of Zero Trust security and we have seen widespread awareness and general agreement on their importance. But we are still in early days in terms of deployments and scope and this is an important time for us as an industry to show real progress and value with this approach. Given today’s threat landscape, our commercial and government entities are facing an even more urgent need to obtain the benefits promised by Zero Trust security principles.

SDP specification updates

This revised version of the SDP specification remains true to the original architecture, design principles and components. And it is a testament to the thoughtfulness of the team that authored the original spec—thank you for giving us a solid foundation on which to build.

The core elements of the SDP architecture are still part of the spec: the concept of a Controller (the Policy Decision Point), identities (SDP Initiating Hosts) authenticating and obtaining access to authorized services, and access via SDP Accepting Hosts (often referred to as SDP Gateways, acting as Policy Enforcement Points). Inter-component communications are protected by Single-Packet Authentication (SPA). This is depicted in the figure below, from the v2 specification.

In this revision, we have added and expanded in several areas:

SDP and Zero Trust

Given Zero Trust’s position at the forefront of the information security industry today, we felt it was important to acknowledge the connections between SDP and Zero Trust and elaborate on how an SDP architecture is a sound way to achieve Zero Trust security.

SDP component workflows

In this revision, we elaborated on the two types of workflows—Onboarding and Access—and examined the role that each of the SDP components play. Specifically, we looked at how Controllers, Accepting Hosts and Initiating Hosts are onboarded as part of an SDP deployment, as well as how Initiating Hosts actually obtain access to an SDP-protected resource.

Revision of the recommended SPA message format

This revision improves upon the SPA message format from v1 in several ways. For instance, the new format includes a nonce and a timestamp to prevent SPA message reuse. It also adds a hash-based message authentication code (HMAC) for message integrity and expands the format to include optional message fields. This last enhancement can be used for an interesting side use case proposed in the spec—that of using a SPA packet as a means of securely transmitting small amounts of information, without incurring the overhead of a connection.

SDP and IoT devices

This revision includes a discussion of how SDP can be used to secure access to and from IoT devices, including “IT” devices like printers and VOIP phones and “OT” devices like industrial control systems. We believe this is an interesting area where SDP can be applied and bring value.

SDP and access policies

Ultimately, SDP and Zero Trust systems are designed to control access based on dynamic and context-sensitive policies. In this section of the spec, we address why access policies are important and how they are approached in the NIST 800-207 model. Defining the specifics of access policies is beyond the scope of this revision of the specification but definitely is an area of future work for the CSA’s working groups.

Expansion and clarification of the SDP message protocol

Finally, recall that the original SDP specification also included a representative network protocol for the interactions between the different components (Controller, AH, IH). This revision clarifies this protocol and messages.

Much accomplished, much left to do

While this may sound like a clichéd campaign slogan from a politician seeking re-election, it does in fact capture the state of where we are with Zero Trust. We, as an industry, have made good progress on championing the need for Zero Trust security adoption and are beginning to see enterprises benefit from embarking on and advancing their journeys. But we still have a long way to go, both within each individual enterprise, as well as more broadly across the industry.

As an enterprise security professional, I’m encouraging you to plan and begin your Zero Trust security journey if you haven’t started and to continue to move forward if you have. Think big but start small, so you can learn, build momentum and develop the internal champions you’ll need on the way.

As industry participants, we all need to collaborate on defining interaction and integration patterns, as well as standardized APIs and message protocols for the extended Zero Trust ecosystem. We need these defined and debated (and deployed) if Zero Trust is going to meet its promise and potential. This includes work around expanding the scope and effectiveness of a Zero Trust policy model in ways that are standardized and interoperable. It also includes development of common mechanisms to define and exchange Zero Trust context and events. We also need to document and celebrate successes with case studies and examples of the business, security and technical value obtained from Zero Trust security initiatives.

I’m pleased that we have reached the milestone of publishing v2 of the CSA SDP specification and I’m excited about the work—and progress—that lies ahead.

Additional resources:

Press Release: Cloud Security Alliance Issues Expanded Specification for the Software-Defined Perimeter (SDP)
Publication: Software-Defined Perimeter (SDP) Specification v2.0
Blog: VPN vs. ZTNA vs. SDP vs. NAC: What’s the difference?
Blog: Implementing your Zero Trust security journey
Learn more: Appgate SDP