Will the Real SDP Please Stand Up?

The term Software Defined Perimeter (SDP) has recently gained popularity and represents a new and agile way to provide secure access in a Zero Trust model. SDP is a set of specific requirements defined by the Cloud Security Alliance (CSA) that provides contemporary secure remote access capabilities in a way that is more effective and secure than VPN/firewall/ NAC combination.

However, SDP is architecturally distinct and requires a bit of rethinking. It builds on the networking concept of a separate data plane and control plane that is found in a Policy Decision Point (PDP) and Policy Enforcement Point (PEP) model and extends with an authentication component. In the SDP authentication process, the “Controller” is the policy decision point for authenticating access and the “Gateway” is the point at which access is granted or denied to services. This capability highlights an important distinction from other approaches because with the PDP traffic isolated from the gateway, you can now support a centralized policy model and authentication where users are simultaneously granted access across a hybrid cloud environment — potentially with multiple connections. Once the connection is established and the gateways are identified for the user; the gateways perform a hybrid role where they make real-time decisions based on device posture and defined conditions while periodically checking for changes from the controller. This not only provides resiliency in the case of a controller outage, but it also improves performance by isolating failure zones and providing scale-out capability of both the controllers and gateways.

Since the SDP model is comprehensive and architecturally distinct, it doesn’t rely upon any legacy access mechanisms or tunneling. This means if you see something that calls for a VPN or Firewall in addition to SDP, it is straying far from even the loosest interpretation of the SDP model and likely limiting in performance, security, or agility thus unable to stand up against today’s remote access demands or meet the needs of elastic hybrid cloud workloads.

Authentication before communication

The other unique element of the SDP is Single Packet Authorization (SPA), which requires cryptographic authentication in the first packet of all network sessions, ensuring only authorized clients can access any part of the network.

Originally created in 2007, SPA cryptographically verifies the initial network packet, offering a DDoS proof authentication mechanism and protection against exploitation since services are only exposed to authorized devices. Transmission Control Protocol (TCP) streams not started with SPA are dropped by SDP and are never processed by controllers or gateways, mitigating DDoS effects. SPA provides additional security measures beyond just DDoS prevention, including spoof prevention and keeping unauthorized devices from accessing protected resources. This protects against credential reuse attacks when usernames and passwords are compromised.

How strong is SDP?

In February 2014, CSA sponsored the Software Defined Perimeter Hackathon, offering an all-inclusive trip to Black Hat and DEFCON for anyone who could defeat SDP security. After a global deluge of more than 10 billion packets, no attack was successful, and the prize remained unclaimed. This illustrates well the strength of the SDP approach.

We are passionate and recognized leaders in the SDP space with strong participation in CSA’s SDP working group and experience integrating SDP solutions. Join us on the Zero Trust journey that industry research experts at Forrester and Gartner predict will significantly change the secure access landscape over the coming years.