Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
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]
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]
There are several techniques for delivering a software-defined perimeter (SDP). These include:[5] ======
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.
The SDP framework has the following workflow (see Figure 2):
While the general workflow remains the same for all implementations, the application of SDPs can favor certain implementations over others.
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]
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]
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.
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.
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]
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]
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
