Implementing an SDP architecture for added network security
A key component of a software-defined perimeter requires client authentication before connection, while also making a network's internals invisible to outsiders.
Software-defined perimeter, or SDP, is a relatively new technology that offers significant improvements in network security when compared with a fixed perimeter. SDP products are new, and the process for implementing the technology is still being developed. In this article, we examine SDP architectures and the requirements for their implementation.
SDP significantly improves network access security, particularly for clients who are connected to untrusted networks. Clients are restricted to specific services, greatly improving security over a traditional VPN. The rest of the network is inaccessible and invisible to outsiders.
Some proponents of SDP have said it's the same thing as zero-trust network access, while others highlight the differences. Many of the principles are similar and will require careful consideration.
SDP reverses the TCP mechanism, which is connect, then authenticate. Instead, SDP requires authentication before connecting. Using this methodology, servers do not operate with open TCP ports, waiting for a connection. Instead, the controller informs the server of an incoming connection after authentication has been performed.
SDP architecture encompasses several models
A publication from the Cloud Security Alliance (CSA) describes several SDP architectural models. Organizations will implement multiple models to support the communications that the organizations use. All models use a central security controller for authentication and authorization of clients and to register servers and services.
The diagram below shows the SDP client-server architecture that covers two of the CSA models: client to server and client to gateway.
The connection process uses the following steps:
Each server registers with the SDP controller. Servers can either have an internal gateway function or rely on an external gateway.
Clients connect to the SDP controller to authenticate, authorize and learn the desired service's connection details.
Clients connect to a server over an encrypted channel, either through an internal server gateway or through an external gateway.
Using this same model of authentication controller, SDP software agents and gateways, any system can connect with any other system over a secure channel without allowing external actors to learn the structure of the network.
Keep in mind that some SDP documents refer to clients as initiating hosts and servers as accepting hosts. This nomenclature -- also known as IH and AH, respectively -- clarifies the roles when one server connects to another server.
Protect applications, data and servers
Unsurprisingly, an SDP implementation will depend on a detailed requirements analysis. Your fundamental requirement is to improve network security, which will require some implementation criteria. Ultimately, you'll need to work with potential vendors to determine the detailed requirements of your implementation.
You'll need to know which applications, servers and data you wish to move under the SDP umbrella. The architectural model you select will depend on whether SDP agents exist for the client and server OSes. You'll need gateways in some cases and built-in SDP agents in others.
Next, identify where the protected applications and data reside. SaaS applications may require protection by a gateway. Internally developed applications in the cloud or corporate data center may use an SDP agent provided by the vendor.
Your requirements should rely on SDP's inherent capability that makes the network's internals invisible and inaccessible to unauthorized access, regardless of location.
Clients and supporting infrastructure
As you set up your SDP architecture, you'll need to determine the set of client OSes and their locations -- such as in office, work from home or mobile -- so you can make sure the SDP vendor has client-side agents for those clients. Another option is to use a remote desktop implementation to a supported client in the organization's control.
IoT clients may need special proxy gateways, so check that they can be supported.
The additional security offered by SDP comes at a price: increased complexity.
Also, verify that the SDP endpoints can integrate with your existing identity and access management systems for authentication and authorization. Additionally, verify how the SDP product uses DNS and other network services. You should expect to find some critical dependencies that could affect the overall system if some component of the supporting infrastructure fails.
Beware configuration complexities
The additional security offered by SDP comes at a price: increased complexity. Additional components and communications are required to establish a successful session. You have client and server communication with a controller, which itself must function correctly. Some architectures require additional gateways as a proxy security endpoint for services that incorporate an SDP agent.
You will need to define the policies that drive the SDP system configuration. Expect to spend some time learning how to build good policies and configurations. Just like with firewall rules, a defective policy can open an unintended security hole. Your vendor should have best practice recommendations on how to build good policies and configurations.
SDP controllers share an interesting parallel with VoIP call controllers. Namely, resilient designs are required because they control how clients connect and are critical components of a properly functioning system.
Be sure to talk with your prospective SDP vendors about the management of their systems, and ask them the following questions:
Can critical parameters be monitored with your existing tools?
Can the system send syslog messages to a logging server?
Can logging of security events be separated from controller and gateway operational events, making it easier to identify system problems?
Work with vendors on troubleshooting
To detect common problems in your SDP architecture, you should learn how to monitor the controller, gateways and agents. Then, spend some time investigating problems that affect system performance. The controller will have limits on the connection request volume, and you should understand those limits before you try a full production rollout. Also, build troubleshooting runbooks to guide the diagnostic process when a failure occurs. The SDP vendor can provide guidance regarding common problems.
Spend time understanding how the SDP products function with your existing network security systems. It is unlikely you'll be able to eliminate VPN concentrators, firewalls and other security systems. You should make sure they aren't duplicating functionality and that they play well together.
Finally, determine if SDP will change how you monitor applications and their servers. Is an access policy needed for it, or is some additional software required? Avoid opening up full access to the servers from the management systems.
As with any new technology, you'll want to follow a progressive rollout that starts small and expand as you learn. Identify specific use cases first, and then broaden the implementation for more applications and clients as you gain experience. It will take some effort to set up a proof of concept, but it will be a valuable training exercise. In particular, look for how to detect and diagnose problems in the SDP implementation. The additional security may require that you change troubleshooting processes.
