Jump to content

Software-defined perimeter

From Wikipedia, the free encyclopedia

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

Background

[edit]

The premise of the traditional enterprise network architecture is to create an internal network separated from the outside world by a fixed perimeter that consists of a series of firewall functions that block external users from coming in while allowing internal users to get out.[3] Traditional fixed perimeters help to protect internal services from external threats. This is achieved via simple techniques for blocking visibility and accessibility from outside the perimeter to internal applications and infrastructure. But the weaknesses of this traditional fixed perimeter model are becoming ever more problematic because of the popularity of user-managed devices and phishing attacks, providing untrusted access inside the perimeter, and SaaS and IaaS extending the perimeter into the internet.[4] Software-defined perimeters address these issues by giving application owners the ability to deploy perimeters that retain the traditional model's value of invisibility and inaccessibility to outsiders but can be deployed anywhere: on the internet, in the cloud, at a hosting center, on the 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). This includes:[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 will be able to generate a valid SPA packet, and subsequently be able to establish a network connection."[6]
  • First Packet Authentication: A single-use, cryptographically generated identity token is inserted on each side of a TCP/IP session for authentication. If allowed, the gateway applies a security policy – forward, redirect, or discard – for the connection request based on the identity.
  • Authenticate Before Connect: Endpoints are bootstrapped with unique, cryptographically generated identities (commonly using x509 and JSON Web Tokens). They establish outbound connectivity into a mesh overlay which only "listens" for authenticated and authorized endpoints. This approach ensures source and destination never require any inbound connectivity as well as work even in challenging NAT scenarios.

Architecture

[edit]

In its simplest form, the architecture of the SDP consists of two components: SDP Hosts and SDP Controllers.[6] SDP Hosts can either initiate connections or accept connections. These actions are managed by interactions with the SDP Controllers via a control channel (see Figure 1). Thus, in a Software Defined Perimeter, the control plane is separated from the data plane to enable greater scalability. In addition, all of the components can be 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 optional authentication and authorization services (e.g., PKI, device fingerprinting, geolocation, SAML, OpenID, OAuth, LDAP, Kerberos, multifactor authentication, and other such services).
  2. One or more Accepting SDP Hosts are brought online. These hosts connect to and authenticate to the Controllers. However, they do not acknowledge communication from any other Host, and will not respond to any non-provisioned request.
  3. Each Initiating SDP Host that is brought on line connects with, and authenticates to, the SDP Controllers.
  4. After authenticating the Initiating SDP Host, the SDP Controllers determine a list of Accepting Hosts to which the Initiating Host is authorized to communicate.
  5. The SDP Controller instructs the Accepting SDP Hosts to accept communication from the Initiating Host as well as any optional policies required for encrypted communications.
  6. The SDP Controller gives the Initiating SDP Host the list of Accepting Hosts as well as any optional policies required for encrypted communications.
  7. The Initiating SDP Host initiates a mutual VPN connection to all authorized Accepting Hosts.
Figure 2: Workflow of the architecture of the Software Defined Perimeter
SDP Deployment Models

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 such that the Accepting SDP Host acts as a gateway between the clients and the protected servers. This implementation can be used inside an enterprise network to mitigate common lateral movement attacks such as server scanning, OS and application vulnerability exploits, password cracking, man-in-the-middle, 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 such as denial of service, OS and application vulnerability exploits, password cracking, man-in-the-middle, and others.[10][11]

Client-to-server

[edit]

The client-to-server implementation is similar in features and benefits to the client-to-gateway implementation discussed above. However, in this case, the server being protected will be running the Accepting SDP Host software instead of a gateway sitting in front of the server running that software. The choice between the client-to-gateway implementation and the client-to-server implementation is typically based on the number of servers being protected, load balancing methodology, elasticity of servers, and other similar topological factors.[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 the ones mitigated by the client-to-gateway implementation.

Client-to-server-to-client

[edit]

The client-to-server-to-client implementation results in a peer-to-peer relationship between the two clients and can be used for applications such as IP telephone, chat, and video conferencing. In these cases, the SDP obfuscates the IP addresses of the connecting clients. As a minor variation, a user can also have a client-to-gateway-to-client configuration if the user wishes 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 sets of data exclusively available within the enterprise network, attackers may gain entry to the internal network by compromising one of the computers in the network and then move 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 not have network access to the protected application, thus mitigating the lateral movement upon 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, leveraging their flexibility and scalability. SDPs can be used by enterprises 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 can enhance security by designating the service as an Accepting Host and all users as Initiating Hosts. This allows SaaS vendors to utilize the global reach of the Internet 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 allowing customers to benefit from IaaS agility and cost savings.

Platform-as-a-service (PaaS) providers can include SDP architecture as part of their offering, providing an embedded security solution that mitigates network-based attacks.

A vast number of new devices are being connected to the Internet.[12] Back-end applications that manage these devices and/or extract information from them can be mission-critical and act as custodians for private or sensitive data. SDPs can be used to conceal these servers and their interactions over the Internet to enhance 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=1256374242"