Jump to content

Software-defined perimeter

From Wikipedia, the free encyclopedia
(Redirected from 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 (CSA) 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

[edit]

The traditional enterprise network architecture is based on the premise of creating an internal network that is separated from the outside world by a fixed perimeter, typically consisting of firewall functions. These firewalls block external users from accessing the internal network while allowing internal users to connect to external resources.[3] Traditional fixed perimeters help to protect internal services from external threats. This is achieved by blocking external visibility and access to internal applications and infrastructure. However, the weaknesses of this traditional fixed perimeter model are becoming increasingly problematic due to the widespread use of user-managed devices and phishing attacks, which provide untrusted access inside the perimeter. Additionally, the rise of SaaS and IaaS has extended the perimeter into the internet.[4] Software-defined perimeters address these issues by allowing application owners to deploy perimeters that maintain the traditional model's value of invisibility and inaccessibility to outsiders, while being deployable anywhere—on the internet, in the cloud, at a hosting center, on a private corporate network, or across some or all of these locations.[1]

Authorization techniques

[edit]

There are several techniques for delivering a software-defined perimeter (SDP). These include:[5] ======

  • Single Packet Authorization (SPA) uses proven cryptographic techniques to make internet-facing servers invisible to unauthorized users. Only devices that have been seeded with the cryptographic secret can generate a valid SPA packet and, as a result, establish a network connection.[6]
  • First Packet Authentication involves a single-use, cryptographically generated identity token inserted at both ends of a TCP/IP session for authentication. If the request is allowed, the gateway applies a security policy forward, redirects, or discards, based on the identity.
  • Authenticate Before Connect ensures that endpoints are provisioned with unique, cryptographically generated identities (commonly using X.509 certificates and JSON Web Tokens). These endpoints establish outbound connectivity into a mesh overlay that only "listens" for authenticated and authorized endpoints. This approach ensures that both the source and destination never require inbound connectivity and can work even in challenging NAT scenarios.

Architecture

[edit]

In its simplest form, the architecture of the Software-Defined Perimeter (SDP) consists of two components: SDP Hosts and SDP Controllers. SDP Hosts can either initiate or accept connections. Interactions with the SDP Controllers manage these actions through a control channel (see Figure 1). As a result, the control plane is separated from the data plane in a Software-Defined Perimeter, enabling greater scalability. Additionally, all components can be made redundant for higher availability.

Figure 1: The architecture of the software-defined perimeter consists of two components: SDP Hosts and SDP Controllers

The SDP framework has the following workflow (see Figure 2):

  1. One or more SDP Controllers are brought online and connected to the appropriate authentication and authorization services (e.g., PKI, device fingerprinting, geolocation, SAML, OpenID, OAuth, LDAP, Kerberos, multifactor authentication, and other similar services).
  2. One or more Accepting SDP Hosts are brought online. These hosts connect to and authenticate with the Controllers. However, they do not acknowledge communication from any other host and will not respond to any non-provisioned requests.
  3. Each Initiating SDP Host that comes online connects to and authenticates with the SDP Controllers.
  4. After authenticating the Initiating SDP Host, the SDP Controllers determine a list of Accepting SDP Hosts with which the Initiating Host is authorized to communicate.
  5. The SDP Controller instructs the Accepting SDP Hosts to accept communication from the Initiating SDP Host and applies any optional policies required for encrypted communications.
  6. The SDP Controller provides the Initiating SDP Host with the list of Accepting SDP Hosts and any optional policies required for encrypted communications.
  7. The Initiating SDP Host establishes a mutual VPN connection with all authorized Accepting SDP Hosts.
Figure 2: Workflow of the architecture of the Software Defined Perimeter

SDP deployment models

[edit]

While the general workflow remains the same for all implementations, the application of SDPs can favor certain implementations over others.

Client-To-Gateway

[edit]

In the Client-To-Gateway implementation, one or more servers are protected behind an Accepting SDP Host, which acts as a gateway between the clients and the protected servers. This implementation can be used within an enterprise network to mitigate common lateral movement attacks, such as server scanning, OS and application vulnerability exploits, password cracking, man-in-the-middle attacks, Pass-the-Hash (PtH), and others.[7][8][9] Alternatively, it can be implemented on the internet to isolate protected servers from unauthorized users and mitigate attacks like denial-of-service, OS and application vulnerability exploits, password cracking, man-in-the-middle attacks, and others.[10][11]

Client-To-Server

[edit]

The client-to-server implementation offers features and benefits similar to the previously mentioned Client-To-Gateway implementation. However, in this case, the protected server runs the Accepting SDP Host software, rather than using a gateway in front of the server running that software. The choice between the Client-To-Gateway and Client-To-Server implementations is typically based on factors such as the number of servers being protected, load balancing methods, server elasticity, and other topological considerations.[12]

Server-To-Server

[edit]

In the Server-To-Server implementation, servers offering a Representational State Transfer (REST) service, a Simple Object Access Protocol (SOAP) service, a remote procedure call (RPC), or any kind of application programming interface (API) over the internet can be protected from unauthorized hosts on the network. For example, in this case, the server initiating the REST call would be the Initiating SDP Host, and the server offering the REST service would be the Accepting SDP Host. Implementing an SDP for this use case can reduce the load on these services and mitigate attacks similar to those mitigated by the client-to-gateway implementation.

Client-To-Server-To-Client

[edit]

The Client-To-Server-To-Client implementation creates a peer-to-peer relationship between the two clients and can be used for applications such as IP telephony, chat, and video conferencing. In these cases, the SDP obfuscates the IP addresses of the connecting clients. As an alternative, a user can opt for a Client-To-Gateway-To-Client configuration if they wish to hide the application server as well.

SDP applications

[edit]

Enterprise application isolation

[edit]

For data breaches involving intellectual property, financial information, HR data, and other sensitive data exclusively available within the enterprise network, attackers may gain entry by compromising a computer on the network and then moving laterally to access high-value information assets. In this scenario, an enterprise can deploy an SDP inside its data center to partition the network and isolate high-value applications. Unauthorized users will be denied access to the protected application, thereby mitigating the lateral movement on which these attacks depend.[13]

Private cloud and hybrid cloud

[edit]

The Software-Defined Perimeter (SDP) model, traditionally used to secure physical infrastructures, is also adaptable to private cloud environments, offering flexibility and scalability. Enterprises can use SDPs to secure public cloud instances, either in isolation or as part of a unified system that spans private and public clouds, as well as cross-cloud clusters.

For Software-As-A-Service (SaaS) providers, SDPs enhance security by designating the service as an Accepting Host and all users as Initiating Hosts. This configuration allows SaaS vendors to leverage the internet's global reach while reducing exposure to potential threats.

Infrastructure-As-A-Service (IaaS) providers can offer SDP-as-a-Service, providing customers with a secure on-ramp to their cloud infrastructure. This mitigates various attack vectors while enabling customers to benefit from IaaS agility and cost savings.

Platform-As-A-Service (PaaS) providers can integrate SDP architecture into their offering, providing an embedded security solution that mitigates network-based attacks.

As a growing number of new devices are connected to the Internet [12], back-end applications that manage these devices and/or extract information from them can become mission-critical, acting as custodians for private or sensitive data. SDPs can be used to conceal these servers and their interactions over the internet, thereby enhancing security and uptime.[14]

See also

[edit]

References

[edit]
  1. ^ a b "Software Defined Perimeter". Cloud Security Alliance. Retrieved 29 January 2014.
  2. ^ Gartner, Market Guide for Zero Trust Access. "Gartner SDP Guide". gartner.com.
  3. ^ Barrie, Sosinsky (May 2004). "Perimeter networks". Search Networking. Retrieved 30 January 2014.
  4. ^ Wagner, Ray; Ray Wagner; Kelly M. Kavanagh; Mark Nicolett; Anton Chuvakin; Andrew Walls; Joseph Feiman; Lawrence Orans; Ian Keene (2013-11-25). "Predicts 2014: Infrastructure Protection". Gartner. Retrieved 19 February 2014.[dead link‍]
  5. ^ "DEFINITIVE GUIDE TO SOFTWARE-DEFINED PERIMETER" (PDF). Appgate. 2020. Retrieved 2024-09-18.
  6. ^ "Appgate | Make Resources Invisible with Single Packet Authorization". Appgate. Retrieved 2024-04-07.
  7. ^ McClure, Stuart (July 11, 2012). Hacking Exposed 7 Network Security Secrets & Solutions. McGraw Hill. ISBN 978-0071780285.
  8. ^ Micro, Trend. "LATERAL MOVEMENT: How Do Threat Actors Move Deeper Into Your Network?". Trend Micro. Retrieved 19 February 2014.
  9. ^ "Data Breach Investigation Report". Verizon. Retrieved 19 February 2014.
  10. ^ "IBM X-Force 2012 Mid-Year Trend and Risk Report". IBM X-Force Research and Development. Retrieved 19 February 2014.
  11. ^ "Global Threat Intelligence Report". Solutionary. Retrieved 19 February 2014.
  12. ^ a b Middleton, Peter; Kjeldsen, Peter; Tully, Jim (November 18, 2013). "Forecast: The Internet of Things, Worldwide, 2013". Gartner (G00259115). Retrieved 29 January 2014.[dead link‍]
  13. ^ Moubayed, Abdallah; Refaey, Ahmed; Shami, Abdallah (October 2019). "Software-Defined Perimeter (SDP): State of the Art Secure Solution for Modern Network". IEEE Network. 33 (5): 226–233. doi:10.1109/MNET.2019.1800324. S2CID 189892671.
  14. ^ Refaey, Ahmed; Sallam, Ahmed; Shami, Abdallah (October 2019). "On IoT applications: a proposed SDP framework for MQTT". Electronics Letters. 55 (22): 1201. Bibcode:2019ElL....55.1201R. doi:10.1049/el.2019.2334. S2CID 203048330.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software-defined_perimeter&oldid=1259163008"