There has been tremendous growth in the adoption of the software-defined perimeter (SDP) over the last few years. This has resulted in SDP becoming a disruptive technology, especially when it comes to replacing, or working together with the existing virtual private network. Why? Because the steps that software-defined perimeter proposes are needed. Today’s network security architectures, tools, and platforms are lacking in many ways when trying to combat the current security threats.
From a bird’s eye view, the stages of zero trust software-defined perimeter are relatively simple. SDP requires that endpoints both internal and external to an organization must authenticate and then be authorized before being granted network access. Once these steps are carried out, two-way encrypted connections are created between the requesting entity and the intended protected resource.
The SDP proposition
Security policy flexibility is offered with fine-grained access control that can dynamically create and remove inbound and outbound access rules. Therefore, SDP minimizes the attack surface for bad actors to play with. Small attack surface results in a small blast radius. So less damage can occur. A VLAN has a relatively large attack surface, especially as the VLAN, contains different services. SDP eliminates the broad network access that VLANs exhibit.
SDP has a separate data and control plane. A control plane essentially sets up the controls necessary for data to pass from one endpoint to another. Separating the control from the data plane renders protected assets “black,” thereby blocking network-based attacks. You cannot attack what you cannot see.
The IP address; not a valid hook
We should be aware by now that IP addresses are lost in today’s hybrid environment. SDP provides a connection-based security architecture instead of an IP-based one. This allows for many things. For one security policies follow the user regardless of location. Let’s say you are carrying out forensics on an event 12 months ago for a specific IP. However, right now that IP address is a component in a test DevOps environment. Do you really care? Anything tied to IP is ridiculous as we don’t have a valid hook to hang things on for security policy enforcement.
Identity-driven network access control is more precise in measuring the actual security posture of the endpoint. Access policies tied to IP addresses cannot offer identity-focused security.
SDP enables the control of all connections based on the pre-vetting of who can connect and to what services. This means that if you do not meet this level of trust you can’t for example, access the database server but you can access public-facing documents. Users are granted access only to authorized assets preventing lateral movements that will probably go unnoticed when traditional security mechanisms are in place.
Information and infrastructure hiding
SDP does a great job of information and infrastructure hiding. The SDP architectural components ( the SDP controller and gateways ) are “dark” which provides resilience against both high and low volume DDoS attacks. A low bandwidth DDoS attack may often bypass traditional DDoS security controls. However, the SDP components do not respond to connections until the requesting clients are properly authenticated and authorized allowing only good packets through.
A good security protocol that can be used here is the single packet authorization (SPA). SPA gives the SDP components a default “deny-all” security posture. The “default-deny” can be achieved because if an accepting host receives any packet, other than a valid SPA packet, it assumes the packet is malicious. The packet will get dropped and a notification will not get sent back to the requesting host. This stops reconnaissance right at the door by silently detecting and dropping bad packets.
However, SPA can be subject to Man-In-The-Middle (MITM) attacks. If a bad actor can sniff a SPA packet, they have the opportunity to then establish the TCP connection to the controller or AH client. But there is another level of defense in that the bad actor is unable to complete the mutually encrypted connection (mTLS) without the client’s certificate. SDP brings in the concept of mutually encrypted connections, also known as two-way encryption. The usual configuration for TLS is that the client authenticates the server but TLS ensures that both parties are authenticated. This means that only validated devices and users can become authorized members of the SDP architecture.
We should also keep in mind that the SPA is not a security feature that can be implemented by itself to protect all. It has its benefits but does not take over from existing security technologies. SPA should work alongside them. The main reason for its introduction to the SDP world is to overcome the problems with TCP. TCP connects and then authenticates. With SPA you authenticate first and only then connect.
The world of TCP & SDP
With TCP when a client wants to access an application they must first set up a connection. There needs to be direct connectivity between the client and the applications. So this requires the application to be reachable and is carried out with IP addresses on each end.
Then once the connect stage is done, there is an authentication phase. Once the authentication stage is done we can pass data. Therefore, we have the connect, then authenticate and data pass stage. SDP reverses this.
The center of SDP is trust
In SDP, before the client is allowed to set up the connection we first must establish trust between the client and the application. The trust is bi-directional and happens between the client and the SDP service and the application to the SDP service.
Once trust has been established we move into the next stage which is the authentication. Once this has been established we can then connect the user to the application. This flips the entire security model and makes it more robust. The user has no idea of where the applications are located. The protected assets are hidden behind the SDP service which in most cases is the SDP gateway or some are calling this a connector.
Cloud Security Alliance (CSA) SDP
With the Cloud Security Alliance SDP architecture, we have a number of components:
Firstly, the IH & AH: which are the clients initiating hosts (IH) and the service accepting hosts (AH). The IH devices can be any endpoint device that can run the SDP software, including items such as user-facing laptops and smartphones. Many SDP vendors have IH browser-based solutions whereby no SDP client software is required. The IH as you might expect initiate the connections.
With an SDP browser-based solution, the user is using a web browser to access the applications and will only work with applications that can speak across a browser. So it doesn’t give you the full range of TCP and UDP ports but you can do many things that speak natively across HTML5. Most browser-based solutions don’t give you the additional security posture checks of assessing the end user device than an endpoint with the client installed.
The AH’s accept connections from the IH’s and provide a set of services protected securely by the SDP service. The AH’s are under the administrative control of the enterprise domain. They do not acknowledge communication from any other host, and will not respond to any non-provisioned requests. This architecture enables the control plane to remain separate from the data plane achieving a scalable security system.
The IH and AH devices connect to an SDP controller that secures access to isolated assets by ensuring that the users and their devices are authenticated and authorized before granting network access. After authenticating an IH, the SDP controller determines the list of AHs to which the IH is authorized to communicate too. The AH’S is then sent a list of IH’s that they should accept connections from.
Aside from the hosts and the controller we have the SDP gateway component that provides authorized users and devices with access to protected processes and services. The protected assets are located behind the gateway that can be architecturally positioned in multiple locations such as the cloud or on-premise. The gateways can exist in multiple locations in parallel.
It will be common in the real world to have a user with multiple tunnels to multiple gateways. It’s not a static path or a one to one relationship, its a user to application relationship. The applications can exist everywhere whereby the tunnel is dynamic and ephemeral. For a client to connect to the gateway, tests should be performed such as latency or SYN SYN/ACK RTT testing to determine the performance of the Internet links. This ensures that the application access path is always through the best gateway, improving application performance.
Keep in mind that the gateway only connects outbound on TCP port 443 (mTLS) and as it acts on behalf of the internal applications, therefore it needs access to the internal apps. As a result, depending on where you position the gateway, either internal to the LAN, private virtual private cloud (VPC) or in the DMZ protected by local firewalls, ports may need to be opened on the existing firewall.