Software-Defined Perimeter Architecture Guide Preview: Part 3
Blog Article Published: 09/18/2018
Part 3 in a four-part series
By Jason Garbis, Vice President/Secure Access Products, Cyxtera Technologies Inc.
Thanks for returning for our third blog posting, providing a preview of the forthcoming Software-Defined Perimeter (SDP) Architecture Guide. In this article, we’re focusing on the "Core SDP Concepts” section of the document, which introduces the underlying principles of SDP, and in which we explain the benefits that SDP provides. In the table below, we list five categories, and for each we explain several aspects of SDP that deliver benefits, along with some color commentary.
One of the key security benefits that SDP provides is that not only are the organization’s servers protected by the SDP Gateway, but the SDP infrastructure itself is secured against access by unauthorized users. This makes it safer to deploy SDP components in internet-facing roles, compared with traditional security infrastructure (such as VPNs) which are directly and easily accessible to attackers.
|Servers are “Blackened”||The SDP components (Controller, Gateways) will not respond to any connections until the clients have been authenticated and authorized with the use of protocols such as Single Packet Authorization (SPA).||External network attacks and cross domain attacks mitigated.|
|Mitigates Denial of Service attacks||Internet-facing services are typically placed behind a ‘deny-all’ gateway/firewall, commonly an SDP Gateway, and are therefore protected from DoS attacks. The SDP Gateway itself is protected against DoS attacks by SPA (see above).||Bandwidth DDoS.|
|Bad Packet detection||The first packet to an accepting host (AH) from any other host is a SPA packet (or similar construct). If an AH receives any other packet, it is viewed as an attack, and future packets from that host can be rejected.||External network and cross domain attacks quickly detected.|
Mutual Two-way Encrypted Connections
Another key element of SDP is that all communications between components – typically the Client and the Controller & Gateways—are encrypted with mutually-validated TLS. This ensures that these elements can validate each other, ensuring the integrity of the system.
|Device Authentication||The connections between all hosts must use mutual authentication to validate the device as an authorized member of the SDP.||Ensures that connections cannot be initiated from invalid or unauthorized devices.|
|Disallows forged certificates||Mutual authentication schemes pin certificates to a known valid root managed (or trusted) by the SDP.||Reduces attacks from credential theft.|
|Disallows Man-in-the-middle attacks||Mutual handshake ensures secure and tamper-proof communications between components.||Prevents Man-in-the middle attacks.|
SDP and the Need-to-Know Access Model
Because SDP is built upon a whitelist access policy model, users are only permitted access to those specific network resources that are permitted by policy—not to an entire subnet or network. The SDP philosophy is that application-level authentication is insufficient security, and that the ability to access a network resource—even without credentials—is in fact a privilege that should be explicitly granted.
|Allows fine-grained access control||Only authorized users and devices are allowed to make connections to servers, based on access policies.||Theft from external users from unknown devices is reduced.|
|Makes forensics easier||All bad packets can be analyzed and tracked for forensics activities.||Bad packets and connections are reduced.|
|Enforces device validation||Device validation proves that the key is held by the proper device requesting connections.||Threats from unauthorized devices are reduced and mitigates credential theft.|
|Protects from compromised devices||Because users are only granted access to authorized applications and to no other ones, the threat of lateral movement from compromised devices is eliminated.||Mitigates threats from lateral movement.|
SDP acts as a logical (and in some implementations, actual) firewall, dynamically adjusting network access based on policies. This permits enterprises to create dynamic enclaves—essentially adapting user access to network resources based on membership attributes, such as directory group membership.
|Allows dynamic membership-based enclaves||Access to protected resources enabled by dynamically creating and removing access rules.||Mitigates network-based attacks.|
Application Layer Access
The final key element of SDP is that users only have access to specified, permitted network resources (referred to as “Applications”, even though they may be admin-level services such as SSH or RDP). By preventing all unnecessary network-level access, organizations benefit by having a reduced attack surface, preventing reconnaissance (such as port scanning) by unauthorized users, and enabling the detection of attempted malicious activity.
|Eliminates broad network access||With SDP, identities no longer have broad access to network segments or subnets. Devices can only access specific hosts and services permitted by policy.||Minimizes attack surface. Eliminates port and vulnerability scanning by malware or malicious users|
|Enables control of application and service access||SDP can be used to protect different types of services, such as application and system services. SDP systems can control which devices and applications are permitted to access specified services.||Limits attack surface, and prevents malware or malicious users from connecting to resources.|
That’s a brief overview of the SDP Core concepts. In our next (and final) preview posting, we’ll be discussing the SDP Policy model. You can read our earlier installations here and here.
Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.
Trending This Week
#1 The Evolution of Private Cloud Computing and Shared Responsibility
#2 Top Threat #5 to Cloud Computing: Insecure Software Development
#3 Securing Your File Transfer in the Cloud
#4 What is a CASB and How Do You Even Say It?
#5 Single-Tenant Versus Multi-Tenant SaaS Solutions: When Does it Matter?
Sign up to receive CSA's latest blogs
This list receives 1-2 emails a month.