In traditional network, perimeter defense innately assumes that attacks are often originated from outside and hence, network perimeter worthy of stringent scrutiny. An analogy of perimeter defense is to compare it with medieval era castle with invincible walls, a well-defined entry point across the draw bridge (router), portcullis (firewall) and guards (IDS). Such a design may only protect outside attacks but how about attacks that may occur inside the wall.
Today, many network attacks may origin from inside or in fact in can come from anywhere. The dynamics of attacks today are more sophisticated, no way of knowing where it can originate from and today’s network may blur the line of perimeter making it difficult isolate traffic. Proliferation of new technology such smartphones, mobile-connected wireless devices, social networks, and IOTs are creating increasingly more security vulnerabilities blurring the line between internal and external networks allowing hackers to circumvent detection. For example, increase use of SaaS and virtualization makes fixed perimeter defense inadequate. According to McAfee, 52% of the respondents surveyed for indicated that they tracked a malware infection to a Software-as-a-service (SaaS). Moreover, 6.1 millions DDOS attacks and data breaches are reported in 2017 that occurred due to inadequate access control.
Software defined perimeters (SDP) address these issues by giving application owners the ability to deploy perimeters dynamically while retaining the traditional notion of impregnability and inaccessibility to “outsiders,” with ability to deploy anywhere – internet, cloud, hosting center, private network or across all these locations.
SDP aims to stop the attacks at the first place. It uses centralized controller that grant access based on assigned policies. The SDP brings together off the shelf security tools including PKI, TLS, IPsec and SAML etc, as well as concepts such as federation, device attestation, and geo-location to enable connectivity from any device to any infrastructure. The concept is proposed by CSA (Cloud Security Alliance) as a framework for dynamic network protection which is developed based on the Global Information Grid (GIG) Black Core network initiative proposed by the Defense Information Systems Agency (DISA) (Moubayed, Refaey & Shami, 2019). It adopts “need-to-know” model of DISA where the device’s identity is verified and authenticated first before granting access to the application infrastructure. Because of this selective process, infrastructure is referred to as “black” meaning infrastructure is unknown to users and cannot be detected. As a result, SDP can effectively mitigate many network-based attacks including server scanning, denial of service, and man-in-the middle etc.
SDP uses centralized or distributed controller to validate device and user credentials and relies on five separate security layers to grant or reject access:
- Single Packet Authentication (SPA): SPA is associated with device authentication for which SDP controller uses SPA to reject traffic from unauthorized device. Client’s device sent first cryptographically encrypted packet to SDP controller where the device’s authorization is verified before giving it access. Device further sent another SPA to SDP host which acts as gateway for protected servers to help it determine the authorized device’s traffic and reject all other traffic.
- Mutual Transport Layer Security (mTLS): The TLS (Transport layer security) was originally designed as a cryptographic protocol to enable device authentication and confidential communication for end-to-end communication security over networks. TLS is an IETF standard and defined in RFC 2246 for TLS 1.0, RFC 4346 for TLS 1.1, RFC 5246 for TLS 1.2 and RFC 8446 for TLS 1.3. Despite it’s capability for two way mutual encrypted communications, TLS is typically used to authenticate servers to client. However, SDP uses full power of TLS standards to enable mutual two-way cryptographic authentication. Additionally, SDP may also use IKE/IPSEC for similar purpose of creating tunnels encrypted communications.
- Device Validation (DV): For the continued communication, mTLS can only prove that device key has not expired or revoked but it cannot prove that it has been stolen. DV is an extra layer protection in which device is verified that is belongs to authorized user and is running trusted software.
- Dynamic Firewall: Unlike static firewalls with thousands of rules, SDP uses dynamic firewall with one constant rule in which to deny access to all connections. After vigorously verifying device and users, rule will be relaxed granting access to applications or resources.
- Application Binding (AppB): In this process SDP forces application to use TLS tunnel this ensures only authorized application can communicate whereas unauthorized application will be blocked.
Collectively, these protocols make it extremely difficult for hackers to access protected applications and services. Thus, SDP framework can address many security, privacy, and availability challenges including but not limited authentication & trust, access control, data privacy, data availability, and services availability.
SDP Architecture
In it’s simplest form SDP Framework consists of two main components: SDP controller and SDP Host. For the later, SDP host can either initiate connections or accept connections through the interactions with SDP controller via secure channel as depicted in figure below:
Figure 1. Architecture of SDP depicting SDP controller, Accepting and initiating host as Control and Data Channel path for communications.
SDP Controller: As the main component of SDP, it determines which SDP host can communicates with each other. SDP controller contains the details of the authorized clients and servers, provides the details of rules to the gateway and controls the authentication of each component. It uses a database for all the above purposes which contains the details of all the hosts involved. SDP controller authenticates these hosts with the help of certificates and may relay information as needed to external authentication services such as attestation, geo-location, and/or identity servers .
SDP Client/initiating Host (IH): Client machine or initiating SDP host trying to access service communicates with SDP controller to request a list of accepting Hosts to which they can connect. To facilitate this communication, controller will attempt to verify the client and obtain information that may include information such as hardware or software inventory. Once verified, client or IH will be allowed to communicate with Gateway.
SDP Accepting Host (AH): The Gateway acting as AH enforces the rules that prevent unauthorized access to the protected servers behind it. By default, the gateway will blocks all traffic, However, once SDP controller provides the list of authorized initiating (clients) and accepting hosts (servers) and list of permissible services, it sets up rules which allow a connection to be established between the two while preventing all other traffic.
SDP Work Flows
To establish communication SDP maintains a “work flow” process as depicted in figure 2. At t=0, gateway that comprises AH, initiate TLS connection to controller and sends a SPA packet as identified by item 1. From t0 to t1, SDP controller verifies the gateway using a certificate present in the gateway. Once verified establishes a mTLS secured connection with the gateway as identified in item 2. Followed by this at t=t2, SDP controller sends all the information about the initiating and accepting hosts as well as the authorized services to the gateway (item 3). Next, Client initiate communication a TLS connection with SDP controller at t=t3 and sends its own SPA packet (item 4). At t=t4 identified by item 5, controller verifies the client using a certificate present in the client and establishes a mTLS secured connection between itself and the client. Following this Client sends another encrypted authentication SPA packet
to the gateway at t=t5. Gateway decrypts the packet, verifies information and sets the firewall rules allowing communication from this client and blocking all other traffic (item 6). Now client initiate the connection to the service at t=t6 (item 7). At t=t7, the connection is established and data transfer takes place (item8).
Figure 2. SDP Work Flows depicting authentication and verification phase.
SDP Applications
With the five SDP protocols of authentication and verification, SDP makes it very difficult for attackers to access protected application. Some of the useful applications of SDP are described below:
Application Isolation for Enterprise: With increase data breaches, enterprise more than ever needs SDP to protect servers and applications inside its data center to isolate various applications such as financial information, HR and other databases while preventing unauthorized used access through the network.
Cloud Computing: Whether private, public or hybrid cloud, SDP can protect physical machines as well able to hide, secure and insolate cloud instances.
Software as a Service (SaaS): According to McAfee, 52% of the respondents surveyed for indicated that they tracked a malware infection to a Software-as-a-service (SaaS). This implies that SaaS vendors needs a dynamic security tools to protect their services since traditional security measures are ineffective against modern cyber threats. By offering Accepting host configuration for SaaS services and initiating hosts mechanisms for all clients, SDP allows SaaS vendors to leverage the global reach of the Internet without its added security concerns.
Infrastructure as a service (IaaS): With SDP-as-a-service, IaaS vendor can now offer protected on-ramp to their customers. This allows customer to take advantage of agility and cost savings offered by IaaS with security protection enabled by SDP.
Platform as a Service (PaaS): Similar to IaaS, SDP can be integrated to PaaS offering allowing PaaS vendors to differentiate their services without added security concerns.
Internet of Things (IOT): With 5G rolling out by next year, more and more IOT devices will be connected to enterprise and service provider networks. However, as such security is main headache that may slow adoption of IOTs. SDP offers device authentication and associated security protection enabling service providers and enterprise to integrate IOTs in their network with ease.
Reference
- Moubayed, A., Refaey, A. & Shami, A., 2019. Software-Defined Perimeter (SDP): State of the Art Secure Solution for Modern Networks. IEEE Network ( Volume: 33 , Issue: 5 , Sept.-Oct. 2019 ).
