Software-defined perimeter

A software-defined perimeter (SDP), sometimes referred to as a black cloud, is a method of enhancing computer security. The SDP framework was developed by the Cloud Security Alliance to control access to resources based on identity. In an SDP, connectivity follows a need-to-know model, where both device posture and identity are verified before access to application infrastructure is granted.^[1] The application infrastructure in a software-defined perimeter is effectively "black"—a term used by the Department of Defense to describe an undetectable infrastructure—lacking visible DNS information or IP addresses. Proponents of these systems claim that an SDP mitigates many common network-based attacks, including server scanning, denial-of-service, SQL injection, operating system and application vulnerability exploits, man-in-the-middle attacks, pass-the-hash, pass-the-ticket, and other attacks by unauthorized users.^[2]

Background

Software-defined perimeter

An SDP is a security methodology that controls access to resources based on user identity and device posture. It follows a zero-trust model, verifying both factors before granting access to applications. This approach aims to make internal infrastructure invisible to the internet, reducing the attack surface for threats like denial-of-service (DoS) and server scanning (Ref. [1]).

Traditional vs. software-defined perimeter

Traditional network security relies on a fixed perimeter, typically protected by firewalls. While this isolates internal services, it becomes vulnerable with the rise of:

• User-managed devices: These devices bypass traditional perimeter controls.
• Phishing attacks: These attacks can give unauthorized users access within the perimeter.
• Cloud adoption: Applications can be hosted anywhere, making perimeter control more complex.

SDPs address these issues by:

• Making applications invisible: Public internet cannot directly see internal resources.
• Enforcing access control: Only authorized users and devices can connect to applications.

SDP architecture and workflow

An SDP consists of two main components:

• SDP Controllers: Manage access policies and communication between devices.
• SDP Hosts: These can be initiating (requesting access) or accepting (providing access) applications.

The workflow involves:

1. Deploying SDP controllers and connecting them to authentication services (e.g., Active Directory, multi-factor authentication).
2. Bringing online accepting SDP hosts, which authenticate with the controllers.
3. Initiating SDP hosts authenticating with the controllers.
4. Controllers determining authorized communication and creating secure connections between hosts.

SDP deployment models

There are several ways to deploy SDPs, each suited for specific scenarios:

• Client-to-Gateway: Protects servers behind a gateway, mitigating lateral movement attacks within a network or on the internet.
• Client-to-Server: Similar to client-to-gateway, but the protected server runs the SDP software directly.
• Server-to-Server: Secures communication between servers offering APIs.
• Client-to-Server-to-Client: Enables secure peer-to-peer connections for applications like video conferencing.

SDP applications

SDPs offer security benefits in various situations:

• Enterprise application isolation: Protects sensitive applications from unauthorized access within the network.
• Cloud security: Secures public, private, and hybrid cloud deployments.
• Internet of Things (IoT): Protects back-end applications managing IoT devices.

Conclusion

Software-defined perimeters offer a dynamic approach to network security, aligning with zero-trust principles. They can enhance security for on-premise, cloud, and hybrid environments.

References

1. "Software Defined Perimeter". Cloud Security Alliance. Retrieved 29 January 2014.
2. Gartner, Market Guide for Zero Trust Access. "Gartner SDP Guide". gartner.com.