New SDP 2.0 specification facilitates zero-trust maturity

The Cloud Security Alliance (CSA) recently published the Software-Defined Perimeter (SDP) 2.0 specification, which is created by their SDP and zero-trust working groups. Given that the original specification was published in 2014 and we’ve seen industry-wide eagerness to adopt zero trust, this update is timely. SDP ties closely to the pursuit of implementing a zero-trust architecture, and what follows are the key aspects of SDP 2.0 in zero-trust environments that CISOs and other security leaders need to know.

The U.S. federal government has published its own zero-trust strategy, the Cybersecurity & Infrastructure Security Agency’s (CISA’s) Zero Trust Maturity Model, and the National Security Telecommunications Advisory Committee’s (NSTAC’s) Zero Trust and Trusted Identity Management report. SDP 2.0 supports many of the recommendations and requirements in these documents, making it relevant for both private- and public-sector security leaders.

This high-level discussion of the SDP 2.0 specification helps security and technology leaders understand the core components and tenets of implementing an SDP. It also highlights the synergies among efforts such as cloud-native architectures, service-mesh implementations, and the broader pursuit of zero trust.

SDP focused on software, network assets

At a high-level, an SDP is essentially a perimeter focused on software, not hardware, and assets over networks. Given the widespread adoption of cloud computing and everything becoming software-defined and as-code, this evolution seems logical. SDPs also help enforce fundamental tenets of zero trust such as least-permissive access control, assuming breach, and trust-but-verify based methodologies.

As one of the SDP co-authors Juanita Koilpillai proclaimed, “The network perimeter is dead; long live the SDP.” Given this mentality, SDP shifts the protection focus from the network perimeter to the protection of organizational assets, which is key to successfully achieving zero trust. Even the federal zero-trust strategy calls for breaking down traditional network perimeters to make systems safely accessible over the internet.

SDP 2.0 architectural components 

SDP 2.0 includes fundamental architectural components to achieve its outcomes. These include SDP hosts and SDP controllers. It also includes both a control plane and data plane, which are pervasive in both cloud-native environments as well as those implementing a service mesh architecture.

An SDP controller can be thought of as a policy decision point (PDP) in the zero-trust context where you would define access control policies. An SDP host functions akin to a policy enforcement point (PEP) in the zero-trust context and helps enforce access policies from the SDP controller. SDP hosts typically sit in front of applications and services to control access as defined in organizational policies.

Building on this information, the SDP controller also communicates with internal entities such as identity and access management (IAM) services and possibly external ones if organizations are using cloud-based identity-as-a-service (IDaaS) options, for example.

Within the context of SDP hosts are both initiating and accepting hosts, aligning with the workflow of access requests. The initiating host (IH) generally provides information related to identity but in more mature organizations also signals such as device posture or geographic location.

Under the CISA Zero Trust Maturity Model, organizations considered “Advanced” in its Device pillar use real-time risk analytics associated with devices to facilitate access control decisions to data or organizational resources. Given this, it is obvious how SDP 2.0 facilitates this level of zero-trust maturity.

On the other end of an IH lives an accepting host (AH), which essentially function as PEPs to control access to organizational resources or services. They take instruction from the SDP controllers to facilitate and enforce access control decisions.

While there is much more detail than discussed here, you can now start to understand how these SDP 2.0 architectural components begin to take shape and align with the tenets of zero trust as widely accepted across the industry.

Cloud Security Alliance

SDP 2.0 deployment models

SDP 2.0 supports six deployment models. Some of the key aspects to consider are core components such as clients, servers, and gateways. Clients are humans or non-person entities (NPEs) requesting access to resources. An SDP gateway functions like an AH as previously discussed, operating as a PEP to organizational resources and data. In models where end-to-end protection is required, the AH and server function as a single host and enforce organizational access control policies directly without a gateway. Organizations should examine these various deployment models to use the deployment models that best align with their requirements.

SDP 2.0 workflows

A key aspect of successful SDP implementations are the associated workflows. This includes the workflow of initial and subsequent SDP controllers as well as those for onboarding AHs and IHs as previously discussed to implement the broader SDP architecture.

It should be evident by now how critical the SDP controllers are to a functional SDP architecture, and for this reason many organizations will deploy several SDP controllers to facilitate both load balancing and overall resiliency to mitigate concerns of a single point of failure (SPoF). Understanding these SDP workflows is key, so be sure to dig into the SDP 2.0 specification for further details.

Reduced attack surface 

Another fundamental aspect of SDP 2.0 is the pursuit to minimize organizational attack surface by reducing the visibility of resources to non-authorized entities. SDP uses Single Packet Authorization (SPA). SPA makes resources invisible to unauthorized entities through the use of cryptography. Devices with a cryptographic secret can establish network connections with SDP components, whereas those without the cryptographic secret simply cannot establish those connections. Take a second to think about how drastically different this scenario is from traditional network protections such as VPNs. Malicious actors attack vectors such as brute force, compromised credentials and more are severely limited due to this concept.

Mutual authentication

Another key aspect of SDP 2.0 is the implementation of mutual authentication between SDP components. Again citing both the federal zero-trust strategy and CISA’s Zero Trust Maturity Model, mature zero-trust environments encrypt all traffic where possible, not just to external locations but internal as well. Mutual TLS (mTLS) is emphasized in all the SDP deployment models and is supported by additional steps such as identity and device validation.

The SDP 2.0 specification lays the groundwork for protecting organizational data and resources in a far more mature fashion than typically done in most enterprises. Like any technological system, it isn’t infallible. Organizations should take time to understand both the architecture concepts, implementations and threat models associated with SDP architectures. Doing so will allow organizations to adopt SDPs in a secure and resilient fashion.