bluebay2014 - Fotolia
How software-defined perimeter authentication ups security
Find out how the emerging software-defined perimeter model increases security by its design and how it can serve as a building block to zero-trust security.
What is the software-defined perimeter? At first blush, the name seems to carry the definition. It's a perimeter that's defined in software, right?
Not quite. The software-defined perimeter (SDP) is an emerging security model that has a set of specific characteristics defined by the Cloud Security Alliance (CSA).
The two most important of these SDP characteristics are the following:
- The two ends of the connection must be authorized before any traffic can pass between them.
- SDPs essentially hide devices and traffic from the public internet, even while using it as a transport mechanism.
How SDP works
Within an SDP architecture, before establishing a connection, devices at either end of a connection must authenticate with one another using single-packet authentication, a lightweight security protocol that validates a device or user's identity before permitting a connection to be established.
Specifically, the information for a connection request, including the requester's IP address, is encrypted and authenticated in a single network packet. It is essentially caller ID for network packets: "Hello, this is Alice calling Bob. Will you accept a call from me?"
But how is Bob to know that Alice is who she claims to be? Enter Authorization.
The senders' and receivers' identities can be authorized via a range of standard authorization mechanisms, including public key infrastructure services, device attestation, geolocation, SAML, OpenID, OAuth, LDAP, Kerberos, multifactor authentication, identity federation and other similar services. To continue the example, with software-defined perimeter, Alice and Bob must both be authenticated before the connection is established.
This authenticate-then-connect approach is the exact opposite of native TCP/IP, which follows a connect-then-authenticate model. By forcing a sender and receiver to authenticate before passing traffic between them, a software-defined perimeter can avoid a host of difficulties, including man-in-the-middle attacks, distributed denial-of-service attacks and other forms of identity hijacking.
Once the two ends of the connection are authorized, traffic can flow between them. An SDP architecture encrypts traffic using mutual Transport Layer Security, which keeps traffic private across the internet.
In essence, with software-defined perimeter, devices only connect to authorized systems, and SDP-protected traffic is always encrypted. Devices and traffic are, therefore, invisible to the rest of the internet.
Software-defined perimeter configurations
SDP can operate in a range of scenarios, depending on the types of devices and how they are connected. In the current version of the spec, SDP v2.0, the Cloud Security Alliance defines six scenarios:
- client to gateway;
- client to server;
- server to server;
- client to server to client;
- client to gateway to client; and
- gateway to gateway.
The client is typically the end-user device -- laptop, tablet, smartphone or IoT device -- running the SDP software. A gateway is a system that provides authorized users and devices with access to protected processes and services. The gateway can also enact monitoring, logging and reporting on these connections.
Typically, the gateway serves as a front end to systems that aren't natively running SDP software. The server is a system that delivers the desired services to the client, but is running SDP gateway software. Basically, the difference between a gateway and a server is the gateway provides stand-alone SDP functionality, while the server includes the SDP software within the server itself.
The client-to-gateway scenario is essentially a virtualized, software-based instance of the concept of a remote-access server. Enterprise users would most commonly deploy this scenario in providing access to legacy resources that are protected behind the gateway.
The client-to-server scenario is essentially today's mobile-to-cloud paradigm, in which the remote device gets access to the cloud-based services protected by SDP.
Users would be most likely to deploy the server-to-server scenario when protecting multiple virtual machines or containers within a public or private cloud.
The client-to-server-to-client scenario would most commonly be deployed in an enterprise-to-enterprise connection, for example, if Bob and Alice were at different companies and wished to connect.
The client-to-gateway-to-client scenario is a variation of client-to-server-to-client that supports peer-to-peer network protocols that require clients to connect directly to one another while enforcing SDP access policies.
Finally, the gateway-to-gateway scenario is still under development by the CSA, which envisions it will likely be used for scenarios in which the client software can't be deployed for some reason -- for example, in certain IoT scenarios where the sensors or actuators lack the storage or computational horsepower to run the SDP agent.
What's next for SDP specs?
The CSA is actively working on expanding the specifications for SDP, and several vendors are pursuing SDP integration in their products. That said, according to information issued by the CSA, most end-user organizations don't yet fully understand software-defined perimeter. Of those that do, the primary use cases are as a replacement for network access control and VPNs. One hurdle, according to the CSA, is the lack of technical details for SDP implementation.
If SDP sounds interesting, it's worth contacting the CSA and reading up on the technology. SDP can serve as a building block toward zero-trust security, another game-changing cybersecurity paradigm.
