Software-Defined Perimeter

ARCHITECTURE
GUIDE
SDP Working Group Software-Defined Perimeter Architecture Guide

11

ACKNOWLEDGMENTS
CSA thanks everyone who contributed and supported us
throughout the development of this guide.

LEAD AUTHORS CONTRIBUTORS CSA GLOBAL STAFF

Jason Garbis Junaid Islam Preeta Raman Shamun Mahmud
Juanita Koilpillai Nya Murray Michael Roza
Aaron Palermo

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

TABLE OF CONTENTS
Acknowledgments............................................................................................................ 1

Introduction...................................................................................................................... 4

Purpose of this Paper...................................................................................................... 5

Target Audience.................................................................................................................. 5

Overview of the Software-Defined Perimeter (SDP)................................................ 6

Security Benefits of SDP.................................................................................................... 6
Business Benefits of SDP................................................................................................... 7
Primary Functions of SDP.................................................................................................. 8
The Many Potential Uses of SDP...................................................................................... 10

SDP Architecture ............................................................................................................. 13

SDP Deployment Models................................................................................................... 14
Client-to-Gateway............................................................................................................ 14
Client-to-Server................................................................................................................ 15
Server-to-Server............................................................................................................... 16
Client-to-Server-to-Client................................................................................................ 17
Client-to-Gateway-to-Client............................................................................................ 17
Gateway-to-Gateway....................................................................................................... 18
SDP Deployment Models and Corresponding Scenarios .......................................... 19
SDP Connection Security................................................................................................... 21
Single-Packet Authorization (SPA)................................................................................. 21
Benefits of SPA............................................................................................................. 21
Limitations of SPA........................................................................................................ 22
SDP and Access Control.................................................................................................. 22

Complementary Architectures: Zero Trust and BeyondCorp................................ 23

Forrester’s Zero Trust Model............................................................................................. 23
Google’s BeyondCorp Model............................................................................................. 23

SDP and Your Enterprise................................................................................................. 25

Enterprise Information Security Architecture Elements................................................ 26
Security Information and Event Management (SIEM)................................................. 27
Traditional Firewalls........................................................................................................ 28
Intrusion Detection/Prevention Systems (IDS/IPS)...................................................... 30
Virtual Private Networks (VPNs).................................................................................... 30
Next-Generation Firewalls (NGFW)............................................................................... 31

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

Identity and Access Management (IAM)....................................................................... 32

Network Access Control (NAC) Solutions..................................................................... 32
Endpoint Management (EMM/MDM/UEM).................................................................. 33
Web Application Firewalls (WAF) .................................................................................. 33
Load Balancers................................................................................................................ 33
Cloud Access Security Brokers (CASB).......................................................................... 33
Infrastructure as a Service (IaaS)................................................................................... 34
Software as a Service (SaaS)........................................................................................... 34
Platform as a Service (PaaS) .......................................................................................... 34
Governance, Risk Management, and Compliance (GRC)............................................ 34
Public Key Infrastructure (PKI)....................................................................................... 35
Software-Defined Networking (SDN)............................................................................ 35
Serverless Computing Models....................................................................................... 35
Architectural Considerations......................................................................................... 35

Conclusion.......................................................................................................................... 36

Appendix 1: Additional Resources............................................................................... 37

Appendix 2: SPA Details.................................................................................................. 38

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

INTRODUCTION

The SDP approach Today’s network security architectures,

platforms fall short of meeting the challenges presented
tools and

combines technical by our current security threats. Whether you’re reading

the headlines in mainstream media, working day-to-day as a
and architectural network defender, or are a security vendor, these potential
threats may affect you. Ongoing attacks from a variety
components that protect of sources affect commercial enterprises, governmental

networked applications organizations, critical infrastructures, and more.

It’s time for us in the information security industry

and infrastructure more to embrace innovative new tools for network security–
specifically via Software-Defined Perimeter (SDP)
efficiently and effectively technologies—and to include all layers of network
stacks in our security efforts. The SDP approach combines
than traditional security technical and architectural components already proven to
protect networked applications and infrastructure more
tools. efficiently and effectively than traditional security tools. SDP
Specification: 1.0, published by the Cloud Security Alliance in
April 2014, outlines the basics of SDP technology:
“The principles behind SDPs are not entirely new. Multiple
organizations within the Department of Defense (DoD)
and Intelligence Communities (IC) have implemented a
similar network architecture based on authentication
and authorization prior to network access. Typically
used in classified or high-side networks (as defined by
the DoD), every server is hidden behind a remote access
gateway appliance to which a user must authenticate
before visibility of authorized services is available and
access is provided. An SDP leverages the logical model
used in classified networks and incorporates that model
into standard workflow. SDPs require endpoints to
authenticate and be authorized first before obtaining
network access to protected servers. Then, encrypted
connections are created in real time between requesting
systems and application infrastructure.14”

14 https://downloads.cloudsecurityalliance.org/initiatives/sdp/SDP_Specification_1.0.pdf

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

5
PURPOSE
As a group of security practitioners and solution
providers, we are passionate about information
security and cyber security. We believe SDP is an
important new solution for combating the security
threats we all face.

Since the publication of SDP Specification: 1.0, we as a Target Audience

working group comprised of software vendors, system and
security architects, and enterprises, have built and deployed The information found in this paper will benefit all

numerous systems adhering to these guidelines. Meanwhile, security, architecture and technical network teams

we have learned a great deal about SDP implementations— considering or currently implementing SDP projects in their

especially in areas in which the original specification was organizations.

lacking. The primary audience includes professionals working

With this guide, we intend to assist enterprises and in information security, enterprise architecture, and

practitioners in their acquisition of information about SDP; security compliance roles. These individuals are largely

to show the economic and technical benefits it can provide; responsible for the evaluation, design, deployment, and

and to assist users in implementing SDP in their organizations operation of SDP solutions.

successfully. We’ll consider this document to be a success if Additionally, those working as solution providers,

the following goals are achieved: service providers and technology vendors will also
benefit from the information provided herein.
• Increased market awareness, credibility, and
enterprise adoption of SDP
• Improved understanding of how SDP can be used in
different environments
• Motivation to use SDP to solve enterprise problems
• Use of this document to educate internal
stakeholders about SDP
• Enterprises successfully deploy SDP solutions based
on the architecture recommendations in this paper

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

OVERVIEW
Introduction to the Software-
Defined Perimeter (SDP)
SDP is designed to leverage proven, standards-based
components, such as data encryption; remote attestation (in
which a host authenticates remote access); mutual transport
layer security (TLS; a method for cryptographically verifying
client information); Security Assertion Markup Language
(SAML), which relies on cryptography and digital signatures
to secure appropriate access; and X.509 certificates, which
verify access via public keys. Incorporating these and other
standards-based technologies ensures that SDP can be
integrated with an organization’s existing security systems.
Since the initial publication of the Software-Defined
Security Benefits of SDP
Perimeter (SDP) specification by the Cloud Security Alliance
(CSA), CSA has seen tremendous growth in visibility and
• SDP reduces security risks by minimizing available
enterprise adoption of SDP innovation. While traditional
attack surface.
network security methods appear to be overwhelming IT and
• SDP protects critical assets and infrastructure by
security professionals across all industries, relevant examples
separating access control and data planes to render
of increased use and interest in SDP technologies include the
each of them “black,” thereby blocking potential
following:
network-based attacks.
• Five SDP working groups have made significant
• SDP provides an integrated security architecture that
progress in their areas of focus, including SDP
is otherwise hard to achieve with existing security
for IaaS, anti-DDoS, and Automotive Secure
point products, such as NAC or anti-malware. SDP
Communications.14
integrates the following discrete architectural
• Multiple commercial SDP offerings are now available
elements:
from multiple vendors, and in use at multiple
»» User-aware applications
enterprises.
»» Client-aware devices
• An open-source reference15 was implemented for the »» Network-aware firewalls/gateways
anti-DDoS use case of SDP.
• SDP provides connection-based security architecture
• Four SDP hackathons have resulted in zero instead of IP-based alternatives, because today’s
successful attacks on the SDP test infrastructure. explosion of IPs and loss of perimeter in cloud

• Industry analyst reports have begun to include SDP environments render IP-based securities weak.

in research and presentations. • SDP allows control of all connections based on

pre-vetting of who can connect; from which devices;
14 SDP-for-IaaS: https://cloudsecurityalliance.org/download/sdp-for-iaas/
Anti-DDoS: http://www.waverleylabs.com/open-source-sdp/ and to what services, infrastructure and other
Software-Defined Perimeter Working Group Initiatives: https://cloudsecurityalliance.org/
parameters.
group/software-defined-perimeter/#_initiatives
15 http://www.waverleylabs.com/open-source-sdp/demo/

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

Business Benefits of SDP

SDP provides many business benefits, which we outline here for quick reference. We look forward to collaborating with the SDP
community to provide in-depth qualitative and quantitative examinations of these benefits in a future publication.

BUSINESS AREA BENEFITS OF IMPLEMENTING SDP

Replacing traditional network security components with SDP reduces licensing and
support costs.
Implementing and enforcing security policies using SDP reduces operational complexity
and reliance on traditional security tools.
Cost and labor savings
SDP can also reduce costs by reducing or replacing MPLS or leased line utilization, as
organizations can reduce or eliminate the use of private backbone networks.
SDP can bring efficiency and simplicity to organizations, which can ultimately help
reduce labor needs.

IT processes can act as a drag on business processes. SDP implementations, on the

Increased agility of IT
other hand, can be driven automatically by IT or IAM events. These benefits accelerate IT,
operations
making it more responsive to business and security demands.

SDP delivers reduced risk compared to traditional approaches. SDP suppresses threats
and reduces attack surfaces, preventing network-based attacks and the exploitation of
GRC benefits application vulnerabilities.
SDP can feed into and respond to GRC systems (such as when integrating with SIEM) to
streamline compliance activities for systems and applications.

Compliance data collection, reporting, and auditing processes can be improved by SDP,
through the centralized control of connections from users on registered devices to
Compliance scope increased specific applications/services.
and compliance costs
SDP can provide additional traceability of connectivity for online businesses.
reduced
The network microsegmentation provided by SDP is frequently used to reduce
compliance scope, which can have a significant impact on compliance reporting efforts.

SDP can help enterprises rapidly, confidently, and securely adopt cloud architectures
by reducing the costs and complexity of the required security architecture to support
Secure cloud computing applications in the public-cloud, private-cloud, data-center, and mixed environments.
adoption
New applications can be deployed faster with equivalent or better security than other
options.

SDP enables businesses to implement their priorities quickly and securely. Examples
include:
• SDP enabled transition from on-premises call-center agents to home-based agents
Business agility and • SDP enables the outsourcing of non-core business functions to specialized third-
innovation parties
• SDP enables customer-facing kiosks on remote third-party networks and locations
• SDP enables deployment of company assets onto customer sites, creating stronger
integration with customers and generating new revenue

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

Primary Functions of SDP

SDP is designed to include five layers of security, at minimum: (1) authenticate and validate devices; (2) authenticate and authorize
users; (3) ensure two-way encrypted communications; (4) dynamically provision connections; and (5) control connections to
services while keeping them hidden. These and additional components are typically incorporated in SDP implementations.

INFORMATION/INFRASTRUCTURE HIDING

Components of SPD Security Threats Mitigated or

Additional Benefits
Architecture Reduced

The SDP components (controller, gateways)

will not respond to connections until clients
All external network attacks and
Servers “blackened” attempting access are authenticated and authorized
cross-domain attacks
with security protocols, such as single packet
authorization (SPA).

Internet-facing services are typically placed behind

Bandwidth and server DoS attacks
a “deny-all” SDP gateway (acting as a network
Denial of Service (DoS) (However, note that SDP should
firewall), and are therefore resilient against DoS
attacks mitigated be augmented by upstream anti-
attacks. SDP gateways are protected against DoS
DoS services provided by an ISP.)
attacks by SPA.

The first packet to an accepting host (AH) from

All external network and cross
any other host is a SPA packet (or similar security
Bad packets detected domain attacks are detected
construct). If an AH receives any other packet, it
quickly.
reads it as an attack.

MUTUALLY ENCRYPTED CONNECTIONS

Components of SPD Security Threats Mitigated or

Additional Benefits
Architecture Reduced

Connections between all hosts must use mutual

Users and devices Connections from unauthorized
authentication to validate devices and users as
authenticated users and devices
authorized members of the SDP.

Forged certificates Mutual authentication schemes pin certificates to a

Attacks aimed at credential theft
disallowed known and trusted valid root managed by the SDP.

Mutual handshake technology protects from man-

Man-in-the-middle attacks in-the-middle attacks that exploit online certificate
Man-in-the middle attacks
disallowed status protocol (OSCP) responses before the server
certificate is revoked.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

“NEED TO KNOW” ACCESS MODEL

Components of SPD Security Threats Mitigated or

Additional Benefits
Architecture Reduced

All bad packets are analyzed and tracked for

Forensics simplified Bad packets and bad connections
forensic activities.

Data theft from external users Only authorized users and devices are allowed to
Fine-grained access control
from unknown devices make connections to servers.

Threats from unauthorized Keys are proved to be held by proper devices

Device validation
devices; credential theft requesting connections.

Systems protected from Threats from lateral movement of Users are granted access only to authorized
compromised devices compromised devices applications.

DYNAMIC ACCESS CONTROL

Components of SPD Security Threats Mitigated or

Additional Benefits
Architecture Reduced

Access to protected resources is enabled by

Dynamic, membership-
Network-based attacks dynamically creating and removing access rules
based enclaves
(outbound and inbound).

APPLICATION LAYER ACCESS

Components of SPD Security Threats Mitigated or

Additional Benefits
Architecture Reduced

Attack surface minimized; port

Devices can only access specific hosts and services
Broad network access and vulnerability scanning by
permitted by policy, and cannot access network
eliminated malware and malicious users
segments and subnets.
eliminated

Attack surface minimized;

SDP controls which devices and applications are
Application and service malware and malicious users
permitted to access specific services, such as
access control prevented from connecting to
application and system services.
resources

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

10

The Many Potential Uses of SDP

Because SDP is a security architecture, it provides benefits at many different levels, which do not all fit neatly into a narrow scope
of classic use cases. This list is not intended to be comprehensive, because there are many other scenarios to which SDP can apply.
The chart below provides several likely examples of types of connections that can be secured by an SDP implementation.

NETWORK LIMITATIONS OF EXISTING

BENEFITS OF UPGRADING TO SDP
SCENARIO TECHNOLOGY

SDP allows the creation of identity-centric

Traditional network solutions provide only
access controls that are relevant to an
coarse-grained network segmentation
organization, which are enforced at the
and are oriented around IP addresses.
network level. For example, SDP can support
Identity-driven network Even with newer platforms like software-
allowing only finance users web access to a
access control defined networking (SDN), enterprises have
financial management system, and only from
difficulty enforcing user access controls
corporate-managed devices. SDP can also
that are timely, identity-focused, and
allow only IT users secure shell (SSH) access
precise.
to IT systems.

SDP enables network microsegmentation,

Increasing network security by based on user-defined controls. Fine-grained
Network
microsegmenting services is labor-intensive control of network access to specific services
microsegmentation
with traditional network security tools. is automated by SDP, eliminating manual
configuration.

VPNs provide secure remote access

SDP secures both remote and on-premises
for users but are limited in scope and
users. Organizations can use SDP as a holistic
capability. They do not secure on-premises
solution, and retire VPN point solutions. SDP
Secure remote access users, and typically provide only coarse-
solutions are also designed for fine-grained
(VPN4 alternative) grained access control (access to entire
access control. All unauthorized resources
network segments or subnets). This
are inaccessible to users, which adheres to
security and compliance risk often violates
the principle of least privilege.5
the principle of least privilege.

Securing third party access enables a

business to innovate and adapt. For example,
Security teams typically attempt to control
users may be transitioned from corporate
third-party access through a combination
offices to home offices to reduce costs, or
of VPN, NAC, and VLANs. These solutions
Third-party user access may sometimes work remotely­—in which
are generally siloed, and cannot provide
case, certain functions can be outsourced
fine-grained or comprehensive access
securely to third-party specialists. On-
control across hybrid environments.
premises access for third-party users can be
controlled and secured easily.

4 Specifically, we’re discussing VPNs for remote enterprise user access, not site-to-site VPNs or consumer VPN scenarios.
5 In a paper published by Gartner on September 30, 2016, the authors write: “By 2021, 60% of enterprises will phase out network VPNs for digital business communications in favor of soft-
ware-defined perimeters, up from less than 1% in 2016.”
“It’s Time to Isolate Your Services From the Internet Cesspool” https://www.gartner.com/doc/3463617/time-isolate-services-internet-cesspool.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

11

NETWORK LIMITATIONS OF EXISTING

BENEFITS OF UPGRADING TO SDP
SCENARIO TECHNOLOGY

Access to privileged services can be

Privileged user (typically admin) restricted to authorized users and secured
access commonly requires heightened at the network level. Privileged services
security, monitoring, and compliance can be hidden from unauthorized users,
Securing privileged user oversight. Traditionally, privileged access thus limiting the attack surface. SDP can
access management (PAM) solutions manage ensure access is only allowed when specific
access through credential vaulting, which conditions are met (e.g. during a defined
does not provide network security, remote maintenance window or only from specific
access, or context-sensitive access. devices), and then access can be logged for
compliance reporting.

Access to applications can be restricted

by integrating user/identity awareness,
Providing fine-grained authorization to
network awareness and device awareness;
high value applications with sensitive data
by not exposing a full network; and by
Securing access to high- currently may require complex and time-
relying on applications or application
value applications consuming changes to several layers of
gateways for access control. SDP can also
functionality. (E.g. application, data external
facilitate application upgrades, testing and
access.)
deployment, and provide the required
security framework for DevOps CI/CD.

In managed security service provider

(MSSP) and larger-scale IT environments, Access to managed servers can be controlled
admins need periodic network access to by a business process (such as an open
Securing access to managed servers, potentially on networks service desk ticket). The SDP can overlay
managed servers with overlapping IP address ranges. This is complex network topologies, simplifying
difficult to achieve with traditional network and streamlining access, while logging user
and security tools, and can lead to onerous activities to meet compliance requirements.
compliance reporting requirements.

Organizations are periodically required

With SDP, networks can be quickly and non-
Simplifying network to rapidly integrate previously disparate
disruptively interconnected without requiring
integrations networks—for example, in M&A or disaster
wholesale changes.
recovery scenarios.

Adoption of Infrastructure-as-a-Service Improved IaaS security. In addition to hiding

(IaaS) has grown dramatically, yet many an application behind a default-deny firewall,
Enabling secure organizations using IaaS still cite security all traffic is encrypted, and user access
transition to IaaS cloud as a concern. For example, IaaS access policies can be defined consistently across a
environments controls may be disconnected from the heterogeneous enterprise. See SDP for IaaS,
enterprise, and limited in scope to the published by CSA on February 13, 2017, to
cloud provider. learn more.6

6 https://cloudsecurityalliance.org/download/sdp-for-iaas/

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

12

NETWORK LIMITATIONS OF EXISTING

BENEFITS OF UPGRADING TO SDP
SCENARIO TECHNOLOGY

SDP can require 2FA prior to granting access

Security and compliance concerns may
to specific applications. SDP can use in-place
require the addition of 2FA to existing
Strengthening multi-factor authentication (MFA) systems
“legacy” applications. This can be difficult to
authentication schemes for improved user experience, and can
achieve for non-web apps and for apps that
add MFA to enhance the security of legacy
cannot easily be modified.
applications.

SDP reduces compliance scope (via

Streamlining enterprise Compliance reporting can create
microsegmentation), and automates the
compliance controls and tremendously time-consuming and costly
compliance reporting task (via identity-centric
reporting workloads for security and IT teams.
logging and reporting of access).

Traditional remote access solutions

expose hosts and ports on the Internet, SDP uses a default-drop firewall, and can
Distributed denial
and are subject to DDoS attacks. Not only be deployed with no visible presence to
of service (DDoS)
do all good packets get dropped, but low unauthorized users, allowing only good
prevention
bandwidth DDoS attacks bypass traditional packets through.
DDoS security controls.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

13

SDP ARCHITECTURE
The primary components of SDP architecture include
SDP Architecture
the client/initiating host (IH), a service/accepting host
(AH), and an SDP controller, to which the AH and IH both SDP
1. Controllers online
controller 4. List of authorized
connect. SDP hosts can either initiate connections (initiating Accepting Hosts
3. Mutual TLS
hosts, or IH), or they can accept connections (accepting hosts, to Controller determined

5. Accept
or AH). IH and AH connections are managed by interactions 6. Receive list communication from
of IPs of
with SDP controllers via a secure control channel. This structure Accepting
Initiating Host

is what enables the control plane to remain separate from the Hosts
accepting
data plane in order to achieve a completely scalable security SDP host
initiating
system. In addition, all of the components can be redundant SDP host

for scale or uptime purposes. By following the workflow

7. mTLS
outlined here, connections between these three components Tunnels accepting
SDP client SDP host 2. Mutual TLS
can be secured using the techniques outlined in Figure 1. to Controller

control channel
HOW IT WORKS
data channel

The SDP client software on the IH initiates connections to the

SDP. Figure 1: SDP Architecture, previously published by CSA in
SDP Specification 1.0
IH devices including laptops, tablets and smartphones are
user-facing, meaning the SDP software is run on the device
itself. The network can be outside the control of the enterprise
operating the SDP.
AH devices accept connections from IHs and provide a set
of services protected securely by the SDP. AHs typically reside
on a network under the enterprise’s control (and/or a direct
representative).
An SDP gateway provides authorized users and devices
with access to protected processes and services. The gateway
can also enact monitoring, logging, and reporting on these
connections.
IH and AH devices connect to an SDP controller, which
is an appliance or process that secures access to isolated
services by ensuring that users are authenticated and
authorized, devices are validated, secure communications are
established, and user and management traffic on a network
remain separate.
The controller and AH are protected by single-packet
authorization (SPA), making them invisible and inaccessible to
unauthorized users and devices. SPA is referenced throughout
this document and in detail on page 21.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

14

Security in an SDP follows this specific step-by-step workflow:

1. One or more SDP controllers are added and activated 5. The SDP controller instructs the AHs to accept
within the SDP and connected to authentication communication from the IH and initiates any optional
and authorization services, such as AM, PKI service, policies required for encrypted communications.
device attestation, geolocation, SAML, OpenID, OAuth, 6. The SDP controller gives the IH the list of AHs, as
LDAP, Kerberos, multi-factor authentication, identity well as any optional policies required for encrypted
federation, and other similar services. communications.
2. One or more AHs are added and activated within the 7. The IH initiates a SPA to each authorized AH. The IH
SDP. They connect to and authenticate the controllers then creates two-way encrypted connections (e.g.
in a secure manner. The AHs do not acknowledge mutual TLS, or mTLS) to those AHs.
communication from any other host, and will not 8. The IH communicates with target systems via the
respond to any non-provisioned requests. mutually encrypted data channel, through the AH.
3. Each IH is added and activated within the SDP and (Note: Step 8 is not depicted in Figure 1 on the previous
connects with and is authenticated by SDP controllers. page).
4. After authenticating an IH, SDP controllers determine
a list of AHs to which the IH is authorized to
communicate.

SDP Deployment Models

CSA’s SDP Specification 1.0 introduced the following potential ways organizations can deploy an SDP architecture:

• Client-to-Gateway • Server-to-Server • Client-to-Gateway-to-Client

• Client-to-Server • Client-to-Server-to-Client • Gateway-to-Gateway

Client-to-Gateway

When one or more servers must be protected

behind a gateway, the connections between client/ Client-to-Gateway Model
controller
IH and gateway are secured regardless of underlying environment

network topology. Gateways may be in the same

location or distributed internationally.
server
In this model, the client/IH is connected to the 2. 1.
environment

gateway directly via an mTLS tunnel where the connection

S1
client
terminates. To secure the connection to servers, environment server
additional precautions must be taken. The SDP controller 3. environment

may be located in the cloud or near the protected servers

S2 S3
SDP client
so the controller and servers are using the same SDP
STEPS: 1. Registration // 2. Request // 3. Connection
gateway.
In Figure 2, servers (in one or more environments) Figure 2: Client-to-Gateway Model: One or more servers are
are protected behind an SDP gateway acting as AH. To protected behind the Gateway
secure connections to servers through the gateway,

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

15

server environments should be controlled by the organization

operating the SDP. Client-to-Server Model

The protected servers are unreachable except from a controller

properly onboarded client/IH, and the gateway and controller environment

are secured with SPA with a default-drop firewall, so they are

“dark” and inaccessible to unauthorized users and potential
1.
attackers. 2.

Protected servers can be included in an SDP without

server
making any changes to the servers. The network on which client
environment

they reside, however, will need to be configured to permit environment

3.

inbound connections to protected servers from the gateway

only, which will prevent unauthorized clients from bypassing SDP client
the gateway(s).
STEPS: 1. Registration // 2. Request // 3. Connection
This model preserves the ability for an organization to use
its existing network security components—such as IDS/IP—by Figure 3: Client-to-Server Model: Server runs the Gateway
deploying them between the SDP gateway and the protected software locally
servers. Traffic is also monitored after being extracted from
in the cloud.
the mTLS tunnel that connects clients to the gateway(s).
The server is protected behind an SDP gateway (acting
The client/IH may be a device or may itself be a server.
as AH). The secure connection to the server (in the server
(See “Server-to-Server” on page 16.)
environments) going through the gateway, may be under the
The Client-to-Gateway model is suited for organizations
control of the owner of the application/services on the server,
moving their applications to the cloud. Regardless of where
giving the owner full control of these connections.
the server environment is located (cloud, on-premises or
The protected servers are unreachable except from an
nearby), organizations must ensure data is secured between
appropriately onboarded client/IH, and the gateway and
the gateway and applications.
controller are secured with SPA with a default-drop firewall.
This model is also suited to securing on-premises legacy
This means the servers are “dark” and inaccessible to internal
applications, because no changes are required to the IH.
and external attackers and unauthorized users, which provides
superior protection from an inside threat.
Client-to-Server
With this model, the protected servers will need to be
When an organization is moving applications to an IaaS outfitted with the gateways. The network on which the servers
provider to secure connections end-to-end, this model reside will not need to be configured to restrict inbound
combines a server and gateway in a single host. The client/ connections to the protected servers. The gateways (the
IH may be located in the same location as the server, or enforcement points) on these servers use SPA to prevent
distributed. In either case, connections between client/IH and unauthorized connections.
server are secured end-to-end. This model makes it easier to use existing network
This model provides organizations a great deal of security components, such as IDS/IPS or SIEMs. Traffic can
flexibility, because server-gateway combinations can be moved be monitored by analyzing these dropped packets from the
between multiple IaaS providers as needed. This model is also SDP gateway/protected servers, thereby preserving the mTLS
appropriate for securing on-premises legacy applications that connections between the client/IH and the servers. (Also note
cannot be upgraded. that the client/IH, although depicted as a user device, may
In this model, the client/IH is connected directly to a secure itself be a server. In this instance, refer to the Server-to-Server
server via an mTLS tunnel, at which point the connection model below.)
terminates. The SDP controller may be located on the server The Client-to-Server model is well-suited for organizations
(so the controller and server are using the same gateway), or moving their applications to the cloud. Regardless of where

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

16

the server environment is located (cloud or on-premises), The SDP controller may be located on the servers so that
organizations have full control over connections to their the controller and the servers are using the same SDP gateway.
applications in the cloud. The SDP controllers may also reside in the cloud.
Servers are protected behind an SDP gateway acting
Server-to-Server as AH. The secure connections to the servers (in the server
environments) going through the gateway are under the
This model is best suited for Internet of Things (IoT) and
control of the owner of the application/services on the server
Virtual Machine (VM) environments, and ensures that all
by default, giving the owner full control of these connections.
connections between servers are encrypted regardless
The protected servers are unreachable except from other
of the underlying network or IP infrastructure. The
whitelisted servers, and the gateway and controller are secured
Server-to-Server model also ensures communications are
with SPA with a default-drop firewall, so the servers are “dark”
explicitly permitted by an organization’s SDP whitelist policy.
and inaccessible to attackers and unauthorized users (both
Communications between servers across untrusted networks
internal and external), providing for extra protection from the
are secured, and servers remain hidden from all unauthorized
insider threat.
connections using a lightweight SPA protocol.
With this model, the protected servers will need to be
This model is similar to the Client-to-Server model on
outfitted with the gateways or lightweight SPA protocol
the previous page, except that the IH is itself a server, and
mechanisms. The network on which the servers reside will not
can also act as an SDP AH. Like the Client-to-Server model,
need to be configured to restrict inbound connections to the
the Server-to-Server model requires that the SDP gateway or
protected servers. The gateways (the enforcement point) on
similar lightweight technology be installed on each server and
these servers utilize SPA to prevent both internal and external
renders all server-to-server traffic “dark” to other elements of
unauthorized connections.
the security ecosystem. Network-based IDS/IPS will need to
This model makes it easier to use network security
be configured to get dropped packets from the SDP gateway
components such as IDS/IPS and SIEMs. Traffic can be
instead of externally. In addition, organizations may rely on
monitored by analyzing all the dropped packets from the
host-based IDS/IP systems.
SDP gateway/protected servers, thereby preserving the mTLS
connections between the protected servers.

Server-to-Server Model
This model is well suited for all environments in which
organizations are moving their IoT and VM environments to

controller
the cloud. Regardless of where the server environment is
environment
located (cloud or on-premises), organizations can have full
control over the connections to their environments in the
1. 1. cloud.
2. 2.

server server
environment environment

3.

STEPS: 1. Registration // 2. Request // 3. Connection

Figure 4: Server-to-Server Model: Any communication

including API calls and system services.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

17

Client-to-Server-to-Client This model makes it easier to use network security

components, such as IDS/IPS and SIEMs. Traffic can be
In some instances, peer-to-peer traffic passes through an monitored by analyzing all the dropped packets from the
intermediary server, such as in IP phone, chat and video SDP gateway/protected servers thereby preserving the mTLS
conferencing services. In these cases, the SDP obfuscates connections between the clients and the protected server.
the IP addresses of connecting clients, encrypts network This model is well suited for all environments in which
connections between the components, and protects the organizations are moving their peer-to-peer applications to
server/AH from unauthorized network connections via SPA. the cloud. Regardless of where the server environment is
located (cloud or on-premises), organizations can have full
control over the connections to the clients.
Client-to-Server-to-Client Model

controller
environment
Client-to-Gateway-to-Client
2.
This model is a variation of Client-to-Server-to-Client,
2.

above. This model supports peer-to-peer network protocols

client client
environment environment requiring clients to connect directly to one another while
1. enforcing SDP access policies.

SDP client SDP client

server
environment
3. 3. Client-to-Gateway-to-Client Model

controller
environment

2. 2.
STEPS: 1. Registration // 2. Request // 3. Connection

Figure 5: Client-to-Server-to-Client Model: Used for peer-to- client client

peer-style services such as IP phone or chat. environment environment

1.

The SDP controller may be located on the servers (so SDP client SDP client

controller and servers are using the same SDP gateway) or in

3.
the cloud. As depicted above, the server is protected behind
3.

an SDP gateway acting as AH. The secure connections to the

server going through the gateway are controlled by the owner
STEPS: 1. Registration // 2. Request // 3. Connection
of the applications/services on the server by default.
The protected server is unreachable except from other Figure 6: Client-to-Gateway-to-Client Model: Used to secure
appropriately onboarded clients, and the gateway and client-to-client communications.
controller are secured with SPA with a default-drop firewall,
so the server is “dark” and inaccessible to attackers and This results in a logical connection between the clients
unauthorized users (both internal and external) providing for (each acting as either IH, AH, or both depending on the
extra protection from the insider threat. application protocol). Note that the application protocol will
With this model, the protected server will need to be determine how the clients connect to one another; the SDP
outfitted with the gateways or lightweight SPA protocol gateway acts as a firewall between them.
mechanisms. The network on which the servers reside will More information will be added for this model in a future
not need to be configured to restrict inbound connections to publication.
the protected server. The gateway (the enforcement point)
on the server use SPA to prevent both internal and external
unauthorized connections.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

18

Gateway-to-Gateway

The Gateway-to-Gateway model was not included in the

initial publication of SDP Specification 1.0. This model is
well-suited for certain Internet of Things (IoT) environments. In
this scenario, one or more servers sit behind the AH such that
the AH acts as the gateway between clients and servers. At the
same time, one or more clients sit behind an IH such that the
IH also acts as a gateway.

Gateway-to-Gateway Model

controller
environment

1. 1.
2. 2.

client/server IH client/server AH
environments environments

3.

STEPS: 1. Registration // 2. Request // 3. Connection

Figure 7: Gateway-to-Gateway Model: One or more servers or

clients are protected behind the Gateway

In this model, client devices do not run the SDP software.

The devices may include those for which it is not desirable or
possible to install an SDP client, such as printers, scanners,
sensors, and IoT devices. In this model, the gateways operate as
firewalls, and also potentially as a router or proxy, depending
on the implementation.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

19

SDP Deployment Models and Corresponding Scenarios

The table below shows which deployment models can take advantage of which SDP scenarios. Each type of deployment requires
different connections to be secured.

CLIENT- CLIENT-
CLIENT- CLIENT- SERVER- GATEWAY-
TO- TO-
NETWORK SCENARIO TO- TO- TO- TO-
SERVER- GATEWAY-
GATEWAY SERVER SERVER GATEWAY
TO-CLIENT TO-CLIENT
Identity-driven network
Y Y* Y Y Y Y**
access control
All SDP models support identity-driven network access control.
* This model provides secure connections to the network and the service.
** The degree to which SDP can identify devices for this model depends on the way the specific SDP implementation performs
device identification and validation. For example, MAC addresses provide weaker identity validation than 802.1x.
Network microsegmentation Y* Y ** Y *** Y Y Y
All SDP models provide network microsegmentation by securing individual connections.
* This model provides microsegmentation by securing connections between clients and gateways, but does not micro-segment
connections to servers behind gateways.
** This model provides network microsegmentation by securing all connections to servers. In addition, servers hosting
gateways are hidden.
*** This model provides network microsegmentation by securing all connections to the server. In addition, servers hosting the
gateway are hidden.
Securing remote access
Y Y Y Y Y Y
(VPN alternative)
SDP is a replacement for traditional VPNs. In all cases, the controller and gateway/AH must be accessible to remote devices so
they can use SPA to initiate connections.
Third-party user access Y Y Y* Y Y Y
SDP supports third-party access for all scenarios depending on the connections required to be secured. Third parties may be
remote or on-premises, and may also have a separate identity provider to which they authenticate.
* SDP secures connections from all third-party applications accessing internal applications for this model, with the third-party
application acting as the client.
Securing privileged user
Y Y N Y Y N
access
SDP secures privileged user access for connections from the client. Typically, privileged user access refers to clients accessing
servers, but can apply to all the models, depending on the application in question.
Securing access to high-value
Y Y Y Y Y N
applications
All models except Gateway-to-Gateway secure all connections related to high-value applications secured by that particular
model.
Securing access to managed
Y Y* Y Y N Y
servers
This scenario is for service provider access to managed servers. The servers can be hidden by gateways entirely, or in the case
of a managed services environment, only the management plane is hidden by gateways.
* In this model, the SDP gateway software is deployed on the server. The servers are hidden, and the MSSP/managed service
detects and controls connections to services.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

20

Simplifying network
Y Y* Y* Y Y Y
integrations
All SDP deployment models support this scenario, with different types of secure connections required.
* For these models, an additional advantage is that the services on the server can be hidden with a gateway.
Secure Transition to IaaS
Y Y Y Y Y Y
Cloud Environments

This scenario involves moving services from on-premises to the cloud.

Robust Authentication
Y Y Y* Y Y Y
Schemes
All SDP models provide the ability to strengthen authentication, often via multi-factor/step-up authentication.
* This model, with no user, cannot prompt for a one-time password. It can support multi-factor authentication, however, such
as using a PKI or a server-based HSM. Identity management systems can (and should) also be used for systems or devices, and
not just users.
Streamlined Compliance
Y Y Y Y Y Y
Controls and Reporting

All SDP models help enterprises streamline compliance by integrating the controls.

DDoS Attack Prevention Y Y Y Y Y Y

Because all SDP models use SPA within the gateway, they increase the organization’s resilience to DDoS attacks. In cases where
a deny-all gateway is not used, Internet-facing services are more frequently subject to DDoS compared to internally-hosted
services.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

21

SDP Connection Security Client-to-Gateway Model

As an architecture, SDP provides the protocol to secure client gateway server

connections at all layers of a network stack. Figure 8
mTLS native traffic
depicts the connections secured by each SDP deployment (secured by (unchanged)
SDP)
model. By deploying gateways and controllers at key locations,
implementers can focus on securing connections most critical Client-to-Server Model
to their organizations and can secure these connections from
client server
network-based and cross-domain attacks.
mTLS
(secured by SDP)
Single-Packet Authorization (SPA)

One of the most critical elements of SDP technology is that Server-to-Server Model
it requires and enforces an “authenticate before connect”
server server
model, which compensates for the open and insecure
nature of TCP/IP. SDP accomplishes this through single- mTLS
(secured by SDP)
packet authorization (SPA), a lightweight security protocol
that validates a device or user’s identity before permitting
network access to the relevant system component (controller Client-to-Server-to-Client Model

or gateway). client server client

The information for a connection request, including the
mTLS mTLS
requester’s IP address, is encrypted and authenticated in (secured by (secured by
SDP) SDP)
a single network message. The purpose of SPA is to allow a
service to be darkened via a default-drop firewall. The system
Client-to-Gateway-to-Client Model
should drop all TCP and UDP packets and not respond to those
client gateway client
attempts, providing no information to potential attackers
that the port is being monitored. After authentication and mTLS mTLS
(secured by (secured by
authorization, the user is granted access to the service. SPA SDP) SDP)
is integral to SDP, where it initiates communication in the
connections made between clients and controllers; gateways Gateway-to-Gateway Model
and controllers; and clients and gateways.
gateway gateway
While implementations of SPA may differ slightly, they
native traffic mTLS native traffic
should share the following tenets: (unchanged) (secured by (unchanged)
SDP)
1. Packet must be encrypted and authenticated
2. Packet must self-contain all necessary information;
Figure 8: Connections secured by each deployment model
packet headers alone are not trusted
3. Packet must not depend on admin or root-level IP, which follows a “connect, then authenticate” model. Given

access in order to generate and send; no raw packet today’s cyber security threat landscape, it is unacceptable

manipulation allowed to permit malicious actors to scan and connect to our

4. Server must receive and process packets as silently as enterprise systems. SPA in combination with SDP addresses

possible; no response or verification will be sent this vulnerability in two ways. Applications using the SDP
architecture are hidden behind an SDP gateway/AH so they
BENEFITS OF SPA are accessible only to authorized users. In addition, the SDP
SPA plays a huge role in SDP. One of the goals of SDP is to components themselves—the controller and gateway—are
overcome the fundamentally open/insecure nature of TCP/ protected by SPA. This allows them to be deployed securely

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

22

in Internet-facing situations, ensuring legitimate users have SDP and Access Control
productive and reliable access, while remaining invisible to
unauthorized users. SPA offers the critical benefit of service The value of SDP as an emerging architecture is that

darkening. A default-drop firewall stance mitigates port it strengthens access control management and sets

scanning and related reconnaissance techniques. This type standards for implementing user access management,

of firewall renders SPA components invisible to unauthorized network access control, and system authentication

users, significantly reducing the attack surface of an entire control. SDP has the ability to enforce access control by

SDP. SPA offers more security than VPNs, with open ports and preventing any network-level access from unauthorized users

other known vulnerabilities in many implementations. and/or using unvalidated devices. Because SDP deploys a

Another advantage of SPA over similar technologies is deny-all gateway, it blocks or allows or prevents network

zero-day protection. When a vulnerability is newly discovered, packets from flowing between the IH and AH. At a minimum,

it is inherently less damaging when only authenticated users SDP enables organizations to define and control their own

can access the affected service(s). access policies determining which identities should access

SPA also protects against Distributed Denial of Service which network services and from which validated devices.

(DDoS) attacks. A relatively small amount of traffic has the SDP does not attempt to displace existing identity

potential to take an HTTPS service offline, if that service is and access management solutions, but enhances user

exposed to the public internet for attack. SPA only makes a authentication-only access control. SDP significantly decreases

service visible to authenticated users, so any DDoS attack is potential attack surfaces by integrating user authentication

handled by a default-drop firewall instead of by the protected and authorization with other security components (see

service itself. “Primary Functions of SDP” on page 8). As an example,

user Jane might not have credentials to sign in to a company’s
LIMITATIONS OF SPA production financial management server, but if it is simply
SPA is only one part of SDP’s layers of security, and is not visible to her device on the network, it presents a risk. If
complete on its own. While SPA implementations should be Jane’s company implements an SDP architecture, the financial
designed to be resilient to replay attacks, SPA can be subject management server is hidden from Jane’s device. So even if
to Man-In-The-Middle (MITM) attacks. Specifically, if a MITM an attacker has a foothold on Jane’s machine, SDP will prevent
adversary is able to capture/alter a SPA packet, the adversary connections from her device to the financial management
may be able to establish the TCP connection to the controller/ server that she does not have credentials for. Even if Jane did
AH rather than to the authorized client. However, this adversary have credentials allowing access to the financial management
will be unable to complete the mTLS connection without the server, having an SDP client installed on her device provides
client’s certificate. The controller/AH should therefore reject additional protection. The attacker would still be thwarted by
this connection attempt and close the TCP connection. Despite multi-factor user authentication coupled with robust device
the MITM scenario, SPA is far more secure than standard TCP. validation.
SPA implementations may differ slightly from different
vendors. An open-source SPA reference implementation is
available in the Fwknop project, or “FireWall KNock OPerator.”14
For more detailed technical information about SPA, refer to
“Appendix 2” on page 38. Another excellent reference is the
chapter “Trusting the Traffic” in Zero Trust Networks by Evan
Gilman and Doug Barth (O’Reilly Media, Inc., 2017).

14 https://www.cipherdyne.org/fwknop/

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

23

COMPLEMENTARY
ARCHITECTURES
Zero Trust and BeyondCorp
In addition to the Software-Defined Perimeter, there are
two other new approaches in today’s security landscape:
the “Zero Trust” concept initially driven by industry analyst
firm Forrester, and Google’s internal “BeyondCorp” initiative.

Forrester’s Zero Trust Model

Forrester’s Zero Trust model15, which has increased in scope

over the past few years, is built on three principles:

• Ensuring all resources are accessed securely,

when explicitly allowed by an SDP control. This is the essence
regardless of the location of user or resource
of the principle of least privilege.
• Logging and inspecting all traffic

• Enforcing the principle of least privilege Google’s BeyondCorp Model

BeyondCorp is Google’s internal network and access

These foundations are aligned with what SDP provides. An
security platform, designed to enable their employees
SDP architecture may be the best way to implement the
access to internal resources. BeyondCorp heavily emphasizes
principles of Zero Trust. Because SDP strongly authenticates
device validation to manage corporate-issued Chromebooks.
users and devices, and also encrypts network connections, it
The system has been well-researched and documented,16 and
ensures that all resources are accessed securely, regardless
it has been a successful internal project at Google over the
of user location. Because SDP is typically deployed as an
past five years.
overlay across existing networks, SDP also ensures that all
BeyondCorp differs from SDP in a number of ways.
resources are accessed securely regardless of the location of
BeyondCorp is a web proxy-based solution that supports HTTP,
the resource—on-premises, in the cloud, or elsewhere. In an
HTTPS, and SSH protocols. SDP implementations generally
SDP implementation, network connections also are controlled,
support more (and in some implementations, all) IP protocols.
providing a centralized place to log which identities (human or
SDP also supports more fine-grained access controls than
machine) are accessing which resources. SDP can be integrated
BeyondCorp. In Google’s system, applications are assigned
easily with a network traffic inspection system if deep packet
to a small number of “trust tiers.” SDP supports finer-grained
inspection is desired. Finally, and perhaps most importantly,
and individualized access controls, driven by user and device
SDP inherently and strongly enforces the principle of least
context.
privilege. Because SDP begins with a default, deny-all gateway,
While Google’s BeyondCorp is not commercially available,
and access strictly follows a whitelist access model, identities
Google has included some elements of the platform in their
can only access networked applications (and the SDP itself)
open-source Istio platform for securing microservices.17

15 https://www.forrester.com/report/The+Forrester+Wave+Zero+Trust+eXtended+ZTX+Eco-
16 https://cloud.google.com/beyondcorp/#researchPapers
system+Providers+Q4+2018/-/E-RES141666 and https://go.forrester.com/blogs/next-genera-
17 https://cloud.google.com/istio/
tion-access-and-zero-trust/

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

24

Google has also launched a free component, called the Identity-

Aware Proxy (IAP),18 for controlling access into resources in the
Google Cloud Platform (GCP). The IAP is not an SDP, nor does
it have the full capability of BeyondCorp. According to Google,
“Cloud IAP is a building block toward BeyondCorp.”
If your enterprise is considering creating a Zero Trust
environment, or if your team likes the BeyondCorp approach,
you may also wish to evaluate SDP as it offers similar benefits
with multiple commercially available versions.
To summarize, SDP as an architecture can ensure a
successful implementation of Zero Trust principles. The
BeyondCorp implementation should provide readers with the
impetus to incorporate the SDP architecture into their BYOD
strategy.

18 https://cloud.google.com/iap/

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

25

SDP AND YOUR ENTERPRISE

Enterprise Information Security Architecture can be gateways and controllers can be logged in an SIEM for further
complex, considering that numerous stakeholders across analysis. The “who, when, what, where” information for every
an organization all have security risks and concerns. SDP connection becomes easier to collect.
ensures secure connections irrespective of the underlying IP
infrastructure. SDP can be the basis for enterprise security HOW DOES SDP AFFECT APPLICATION
RELEASE/DEVOPS PROCESSES AND TOOLSETS,
architectures because it comprises the following key concepts:
INCLUDING API INTEGRATIONS?
1. authorize users and validate devices before allowing
Many organizations have adopted high-velocity
connections
application release processes, such as DevOps or CI/CD.19
2. bi-directional encrypted communication
These processes, and their supporting automation framework,
3. dynamic rules on deny-all firewalls and hiding servers
require thoughtful integration with security systems, and SDP
4. integrate application context and fine-grained access
is no exception. SDPs can effectively secure connections by
control
authorized users to the development environment during
DevOps. SDP can also be used during operations to protect
In this section, we present a number of questions architects
connections even from legitimate users to specially protected
should consider as they plan to deploy SDP in their enterprise.
servers and applications.
The questions will help architects consider various aspects
Security architects must understand their SDP deployment
of security, including user populations, networks, server
model and how their organization’s DevOps mechanisms will
environments, and security and compliance requirements.
integrate with it. Security teams should look at the set of APIs
supported by their SDP implementation, as API integration is
HOW DOES AN SDP DEPLOYMENT FIT INTO
EXISTING NETWORK TECHNOLOGIES? often a requirement for DevOps toolset integration.
Architects must decide which SDP deployment model to
HOW DOES SDP IMPACT USERS, ESPECIALLY
use, and they must understand that for some models
BUSINESS USERS?
gateways may represent an additional in-line network
Security teams often strive to make their solutions
component. This may have implications on their organization’s
as transparent as possible for users. SDP supports this
network, such as requiring some firewall or routing changes
approach. If the principle of least privilege is achieved, users
to ensure protected servers are invisible and accessible only
will have full access to everything they need, and will not notice
through the SDP gateway.
that unnecessary access has been denied. Depending on the
SDP deployment model, users will run the SDP client software
HOW DOES SDP AFFECT MONITORING AND
LOGGING SYSTEMS? on their devices. Security architects should collaborate with IT
Because SDP uses mTLS between IH and AH, network to plan the user experience, client software distribution, and
traffic becomes opaque to intermediary services that device onboarding processes.
may be in place for security, performance, or reliability
monitoring purposes. Architects must understand what
systems are in operation, and how SDP-related changes to
the network traffic may affect these systems. Because SDPs
typically provide richer, identity-centric logging of user access,
they can also be used to augment and enhance existing
monitoring systems. In addition, all dropped packets from SDP
19 https://en.wikipedia.org/wiki/DevOps and https://en.wikipedia.org/wiki/CI/CD

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

26

Enterprise Information Security

Architecture Elements
Figure 9 below examines the primary elements of an
enterprise security architecture. The diagram is a simplified
view of a hybrid enterprise, depicting the primary elements
of a prototypical security infrastructure and the relationships
between these elements.

Enterprise Security Architecture

VPN
VPN Gateway Bastion Firewall NGFW
IDS/IPS
client Host
SIEM
IAM
GRC
SaaS PKI
& PaaS WAF
Load
CASB Balancers
NAC
Direct EMM/MDM
Connection

IaaS
Security Group

DMZ

Figure 9: Primary Elements of an Enterprise Security Architecture

This example of enterprise security architecture is comprised

of on-premises and cloud-based resources (IaaS and SaaS/
PaaS), with a standard accompanying set of security, IT, and
compliance components. How these standard components
integrate with SDP is explored in more detail in the following
pages.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

27

Security Information and Event Management (SIEM)

SIEM systems14 provide analysis of log information and SIEM systems. Compare this to how SIEMs are currently being
security alerts generated by applications and network used for logging: security analysts have to piece together
components. SIEMs centralize the storage and interpretation information from multiple logs to even identify unauthorized
of logs and allow near-real-time analysis, which enables users (the “who”). Identifying unauthorized connections made
security personnel to take defensive actions quickly. SIEM from “what” to “where” is even more challenging. If an SDP
systems also provide the automated centralized reporting client is on a user’s device, however, specific information from
usually required for regulatory compliance. the device can also be collected. All dropped packets from the
SIEM systems, whether hosted on-premises or in the SDP gateway can be stored for further analysis into potential
cloud, are a well-established and mainstream part of IT hack attempts or for evaluating attrition.
and security management systems. While commercial SDP This level of recording is superior to the lists of IP
solutions typically provide an internal logging capability, their addresses and ports generated by traditional firewalls. SDPs
value is magnified when SDP logs are directed to an enterprise also enhance the SIEM’s ability to associate user activity
SIEM system that aggregates information from multiple occurring across multiple devices. Associating user activity in
sources. An enterprise system might receive feeds directly this way is often difficult to achieve without SDP, especially
from distributed SDP components, or it may deploy multiple with the advent of BYOD and mobile devices.
collection agents in a hierarchical manner. The SIEM performs Integrating SIEMs with SDP deployments helps
inspections and flags anomalies by forwarding predefined and accomplish the goal of moving security operations from a
customized events to a centralized management console or by reactive to a proactive endeavor. In order to control risk,
sending alerts to designated individuals via email. an existing SIEM should also be considered an important
source of information, in addition to being a sink for SDP log
information.The SIEM can help control risk by disconnecting
SIEM and SDP users, disallowing connections from unvalidated devices or
Traditional security and IT from certain hosts, and dropping suspicious connections.
SIEM systems feed log data into
SIEM For example, if an SIEM indicates a higher-than-normal risk
level indicating unauthorized user activity, the SDP will then
A B C SDP systems can interact
with SIEM in multiple ways: drop all connections from the user until further analysis can
A. Feed enriched log data be performed. SDP complements SIEM by addressing and
SDP controller or into SIEM controlling connections in seconds.
gateway B. Make calls into SIEM to
obtain security or user Like all systems that generate log information, SDP logs
content represent a potential data privacy concern for an enterprise.
C. Receive calls from SIEM
to adjust security or user Because network connections (and their metadata) may be
content
associated with specific users in the logs, organizations need
to take precautions during deployment of SDPs in order to
Figure 10: SIEM with an SDP address this concern.
SDP augments and improves the ability of SIEM systems to
Because they control access in a manner that vets identities prevent, detect, and respond to different types of attacks. The
and devices, SDPs provide SIEMs with richer information following page shows some examples of the types of attacks
than typical network and application monitoring tools. SDPs that can be mitigated. (A more exhaustive list of attacks that
provide, in real time, the “who, what, where” information may be prevented by integrating SDP with SIEMs is slated for a
about every connection made, thereby increasing the value of future CSA publication.)

14 https://en.wikipedia.org/wiki/Security_information_and_event_management

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

28

TYPE OF SECURITY
MITIGATION HOW SDP INTEGRATES WITH SIEM
ATTACK

Port scan / Network SDP blocks all unauthorized network activity, and can log all
Block and Notify
reconnaissance connection requests for use within the SIEM.

Because the SDP is protected by SPA, DoS attacks are

DoS attack Block and Notify largely ineffective. SPA drops bad packets, which can be
logged to the SIEM.

Authorized user access to authorized resources is

Malicious use of permitted by SDP, but the SIEM can analyze user activity
Detect and Address for anomalous behavior, and the SDP can then disallow
authorized resources access by the authorized user until further analysis can be
performed.

SDP requires multiple factors prior to connection, rendering

Use of stolen credentials Block and Notify
stolen passwords insufficient for attackers to obtain access.

Traditional Firewalls

Traditional firewalls monitor and control network traffic with SDP. Rather than attempting to model identity-centric
according to a set of rules based on the seven-layered access controls within the constraints of the 5-tuple, SDP
Open Systems Interconnection (OSI) model, in which layers allows more accurate representation and enforcement via
2, 3 and 4 of OSI are applied: data-link layer (2), network SDP access controls. In addition to reducing the effort required
layer (3), and transport layer (4). They adhere to the 5-tuple 14
to write, test, debug, and deploy firewall rules in complex
method, which filters network packet data based on source environments, SDP also enables richer and more precise
and destination IPs and ports, and definitions of the network access control mechanisms.
protocol flowing over the connection. Firewalls may also
support other functions, including network address translation
(NAT) and port address translation (PAT).
Firewalls have been a mainstay of enterprise network
security for decades. They do, however, have many limitations
since they are only one piece of the security infrastructure and
operate only within the limited world of the 5-tuple. Typically,
traditional firewalls are only capable of expressing static rule
sets and cannot express or enforce rules based on identity
information.
SDPs, which use firewalls or implement the equivalent
network traffic enforcement capabilities, significantly
improve the way enterprises currently use firewalls. SDP will
take on much of the network access control enforcement
that organizations are attempting to control with firewalls.
Enterprises can reduce their firewall rulesets considerably

14 https://www.techopedia.com/definition/28190/5-tuple

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

29

Traditional Firewall Setup

Application A

Firewall

Database Hypervisor
Office LAN
Server B
192.168.0.0/18
Data Center
10.1.0.0/16

Figure 11: Traditional Firewall Setup

Figure 11, above, depicts the difficulties of attempting to the office LAN to access all IPs in the data center network.
secure access in a traditional office LAN environment, in Compare the traditional firewall setup with Figure 12, below,
which a single firewall controls access from the user subnet which depicts a simplified version of the SDP Client-to-Gateway
(192.168.100.0/18) to a local data center subnet. model (omitting the controller for clarity). Note that other SDP
The firewall cannot distinguish between users on the office deployment models similarly apply.
network because they appear only as IP addresses. In addition, In this example, the network firewall has been replaced
because many users are on laptops that regularly connect and by the SDP gateway, which performs the same functions.15
disconnect, users’ IP addresses frequently change. Because the SDP controls access based on specific identities
A typical data center network houses a variety of workloads, and the devices they use, it enables the organization to enforce
including both testing and production systems. While some fine-grained access control into the data center. The open, flat
applications are long-lived and have static IP addresses, others network—which represents a large attack surface—has been
are built on virtual machines, which are regularly created and minimized. Note that even more fine-grained access to specific
destroyed (and therefore have unpredictable IPs). While no services can be gained by adding more SDP gateways closer to
individual user requires access to all servers (and all ports on or on the servers in the data center. (See ”Client-to-Server” on
those servers) in the data center, this environment effectively page 15.)
forces the firewall to have a rule set that permits all IPs in 15 In a real-world deployment, the firewall may remain in place, but with a minimal rule set,
such as permitting office LAN traffic to reach only the SDP gateway, which then enforces
user connectivity from specific devices to specific services.

Improved Security via SDP Client-to-Gateway Model

C
Application A

C G

Database Hypervisor
Office LAN
Server B
192.168.0.0/18
Data Center
10.1.0.0/16

Figure 12: Improved Security via an SDP Client-to-Gateway Model

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

30

Intrusion Detection/Prevention Systems insider threats.

(IDS/IPS) SDP also can simplify and enhance the creation and
effectiveness of a “honeypot” system. Because protected
Intrusion Detection and Intrusion Prevention Systems systems are invisible to attackers, SDP increases the likelihood
(IDS/IPS)16—treated synonymously here—are security that a malicious actor will find and attack the honeypot,
components that monitor a network or system for because it represents a larger proportion of visible systems to
malicious activity or policy violations. They may be network- all users. An SDP-honeypot system can lead to faster detection
based (inspecting traffic) or host-based (inspecting activity and of malicious activity on the network.
potentially network traffic). SDP can bolster the deployment of
IDS/IPS systems, although it may require changes to network- Virtual Private Networks (VPNs)
based IDSs. In smaller operations (e.g. single network remote
offices), SDP may even eliminate the need for IDS/IPS, which VPNs establish secure private network connections across
can reduce costs. untrusted networks. VPNs are commonly used for secure
Additionally, because SDP uses mutual TLS encryption remote access (e.g. off-site employee to corporate site),
between the client and the gateway, network traffic becomes secure inter-site communications, and even between different
opaque to network-based IDSs. IDSs typically proxy the TLS companies (a site-to-site extranet). VPNs commonly use TLS
traffic by importing certificates, which has a side effect of or IPSec.19
increasing attack surface.17 It is generally not possible within While VPNs provide encapsulation and encryption of
SDP to increase the attack surface because it is based on network traffic, they also suffer from limitations that are better
mutual TLS (often with ephemeral certificates) and is therefore addressed by SDP. While licensing costs of VPNs may be low,
resilient to the MITM role played by the IDS. anecdotally they can require significant operational effort. VPNs
The mTLS segment of these logical connections (depicted generally provide broad, overly permissive network access.
in blue) are opaque to any outside system, because they are VPNs typically also provide only basic access control limits (e.g.
encrypted using the SDP’s credentialing and are, by design, based on subnet ranges). These limitations represent security
inaccessible to systems attempting to analyze this traffic. and compliance risks in many organizations. In distributed
This change will impact intermediary security and network environments, VPNs may require the unnecessary backhauling
monitoring systems in a manner similar to the shift from TLS 1.2 of user traffic through a corporate data center, adding latency
to 1.3, in which certain use cases are no longer possible. (For 18 and bandwidth costs. The VPN server itself also is exposed as a
a graphical representation for each type of SDP deployment, service on the Internet, rendering them potentially vulnerable
see “SDP Connection Security” on page 21.) to attackers.
In addition, SDPs support the ability to push unencrypted In addition, VPNs impose a considerable burden on users,
traffic (e.g. dropped packets) to a remote IDS. Alternatively, delivering an often-poor user experience. Users are required
a host-based IDS may enhance security operations more to remember which applications require use of the VPN (and
than a network-based IDS/IPS can. SDP is not the only trend which ones do not), and they are also required to manually
impacting network-based IDSs. The move to cloud-based connect and disconnect. For users who need to access multiple
applications has also increased the effectiveness and adoption remote locations, VPNs often prevent them from connecting to
of host-based IDSs. both locations simultaneously, requiring them to switch back
While deploying SDP may require some changes to IDS and forth between environments. Whenever cloud migration is
systems, it will bring the benefit of reducing noise in the system involved, VPN management balloons in complexity, forcing IT
by blocking all unauthorized network traffic. This shift allows administrators to configure and sync VPN and firewall policies
the IDS, and the team operating it, to focus on network traffic across multiple locations. This complexity makes it even more
to authorized applications, and to shift resources to detecting difficult to eliminate unwarranted access.
VPNs are a prime target for replacement by SDP. Similar to
16 https://en.wikipedia.org/wiki/Intrusion_detection_system
17 https://www.sans.org/reading-room/whitepapers/vpns/snort-ssl-tls-inspection-37735
18 https://tools.ietf.org/id/draft-camwinget-tls-use-cases-00.html 19 https://en.wikipedia.org/wiki/Virtual_private_network

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

31

VPNs, SDP requires a client to be installed on the user’s device. group attributes, but these can be complex to
By using SDP instead of VPN, organizations can have a single implement.
access control platform consistent for remote, on-premises
and mobile device users. And because SDPs, especially those SDP is a natural complement to NGFWs already deployed.
exposed to the Internet, provide zero visibility via SPA and Enterprises can use SDP to ensure user access policies, while
dynamic firewalls, they are considerably more resilient to also using their NGFWs for core firewall protection and IDS/IPS
attacks than typical VPN servers. for traffic inspection. The benefit of integrating SDP with your
NGFW is to enforce zero visibility as well as making the NGFW
Next-Generation Firewalls (NGFW) more dynamic (described in more detail later in this section).
User access policies can also be enforced by integrating NGFWs
In general, NGFWs20 have the attributes of traditional
with IAMs or AD, but SDP offers truly secure connections that
firewalls, plus additional capabilities—making them “next
can be controlled.
generation.” They monitor access and examine network
In some ways, NGFW architectures compete and overlap
packets according to predefined rules and filter data using
with SDP. In the past decade, NGFW vendors have been
the information in OSI layers 2 through 4. NGFWs also use the
successful and have innovated to solve some of the same
information in layers 5 through 7 (session layer, presentation
problems that SDP addresses. By combining NGFW and VPN
layer, and application layer) to perform additional functions.
capabilities with user and application awareness, enterprises
NGFWs provide the following capabilities, depending on
can, to some degree, accomplish many of the goals of SDP.
vendor:
However, there are architectural differences between doing
• Application Awareness: Recognizes applications to this and implementing SDP. NGFW systems are IP-based,
determine what types of attacks to seek whereas SDP is connection-based. NGFWs offer limited
• Intrusion Detection System (IDS): Monitors the identity and application-centric capabilities. Their access policy
security status of the network models are typically coarse-grained, providing users broader
network access than what is strictly necessary. NGFWs
• Intrusion Prevention System (IPS): Denies traffic in
also tend to be less dynamic than SDPs, which can include
order to prevent security breaches
external systems in access decisions. For example, an SDP
• Identity Awareness (User and Group Control): may only permit developer access to staging servers during
Manages which resources users can access an approved change management window. SDPs also are
• Virtual Private Network (VPN): NGFWs may capable of enforcing step-up authentication, which is typically
provide this capability for remote user access from not supported by NGFWs.
untrusted networks NGFWs are still firewalls, and they often mandate
traditional perimeter-centric network architectures with site-
While NGFWs represent significant improvements over to-site connections. SDP deployments usually support more
traditional firewalls, they also have limitations when compared distributed and flexible networks, thereby enabling a flexible
with SDP: network segmentation capability. SDP is fundamentally
based on a “need to know” (whitelist) security model, which
• Latency: Like any IDS/IPS, they impose additional
hides unauthorized services from unauthorized users and
latency on network traffic, especially when
unauthorized devices. SDP leverages SPA and dynamic
performing file inspection.
firewalls to protect and hide authorized connections. NGFWs
• Scalability: They may require substantial hardware
typically operate in more highly visible environments.
in order to scale up.

• Rule complexity: Some NGFW vendors include

capabilities related to identity, such as user and

20 https://en.wikipedia.org/wiki/Next-generation_firewall

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

32

Identity and Access Management (IAM) IAM is used within SDP to authenticate users, to provide
information that SDP uses to make authorization decisions,
IAM systems provide mechanisms for users and devices to and to enable enriched audit logs for all access granted to
validate their identities (via authentication), and to store users from registered devices. Tying application access (not
managed attributes and group memberships about those network access) to users (not IP addresses) yields useful
identities. The SDP architecture is designed to integrate connection information for logging and significantly reduces
with existing enterprise IAM providers, such as LDAP, Active IT overhead when it is necessary to audit historical access for
Directory, and SAML. security or compliance reasons.
SDPs control access are typically based on factors IAM tools typically focus on the business processes that
including IAM attributes and group memberships, along with maintain the identity lifecycle and standardize how identity
attributes of the devices being used to make connections. information is used to control access to resources. For
The combination of user and device authorization criteria example, the mechanism for “provisioning” users for access
help create granular access rules that grant or restrict access, is usually a combination of manual and automated processes.
ensuring only authorized access from authorized users on SDP supports these IAM processes because it relies on the
authorized devices to authorized applications. identity attributes and group memberships managed by IAM
SDP integration with IAM is not only used for initial user tools. As user attributes or group memberships change, SDP
authentication, but also for step-up authentication, such as automatically detects these changes and alters user access
prompting for an OTP in order to access sensitive systems, or without altering the IAM processes.
under certain circumstances (such as remote access versus SDP integrates with SAML.21 Within an SDP deployment,
on-premises). IAM systems can also communicate with SDP a SAML provider may act as an identity provider for user
via API calls in response to identity lifecycle actions, such as attributes and/or as an authentication provider (e.g. for MFA).
disabling an account, changing group membership, dropping In addition to SAML, there are many open authentication
connections from users, or changing user roles. protocols, such as OAuth,22 OpenID Connect,23 W3C Web
Authentication (WebAuthn),24 and the FIDO Alliance Client-
to-Authenticator Protocol (CTAP).25 (These protocols will be
explored in future SDP-related research.)

Network Access Control (NAC) Solutions

NAC solutions26 typically control which devices can

connect to a network and which network subjects can be
accessed. These solutions most commonly use standards-
based hardware (802.1X) and software to validate devices
prior to granting them access to the network, and they operate
at Layer 2 of the OSI model.
At the time the device first appears on the network, NACs
perform device validation and then assign devices to a network
segment (VLAN). In practice, NACs are used to assign devices
coarsely to a small number of networks. Most organizations
have only a few networks, such as “Guest,” “Employee,” and

21 https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
22 https://en.wikipedia.org/wiki/OAuth and https://oauth.net/
23 https://en.wikipedia.org/wiki/OpenID_Connect
24 https://www.w3.org/TR/webauthn/
25 https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-proto-
col-v2.0-id-20180227.html and https://fidoalliance.org/fido2/
26 https://en.wikipedia.org/wiki/Network_Access_Control

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

33

“Production.” Because NACs operate at Layer 2 of the network, users and applications in a manner similar to IDS/IPS. WAFs
they often require specific network gear, do not operate in primarily examine HTTP(S) protocol traffic to detect and block
cloud environments, and cannot be used remotely. malicious content.
SDP is a modernized solution to NAC that integrates user WAFs are complementary to SDP. For example, in the
and device access. However, there are some environments Client-to-Gateway model, WAFs are deployed behind an SDP
in which it makes sense to use NAC—for example, hardware gateway, operating on the native web application traffic after it
devices like printers, copiers, landline phones, and security has been extracted from the SDP mTLS tunnel. In the Client-to-
cameras. These devices often have 802.1X support built-in and Server and Server-to-Server models, WAFs integrate with the
cannot typically support the installation of an SDP client. The SDP gateway on the servers for more distributed control of
SDP Gateway-to-Gateway model to protect these devices and HTTP(S) traffic inspection.
control user access to them is a better option and will be a
topic for future SDP research. Load Balancers
Load balancers are part of many network and application
Endpoint Management (EMM/MDM/UEM)
architectures. Load balancers include DNS and network-
Many enterprises utilize endpoint management systems, based solutions, and architects need to understand how their
often categorized as Enterprise Mobility Management organization uses them when planning SDP deployment.
(EMM), Mobile Device Management (MDM), or Unified For example, network-based load balancers are typically
Endpoint Management (UEM). These are important elements deployed inline on the network, between clients and servers,
of enterprise IT and security, and their value and importance is and similar to the WAF discussion above, may not be able to
augmented by an SDP deployment. inspect the mTLS connection between SDP components. The
Endpoint management systems can be used to automate specifics of the SDP deployment and load balancing approach
the distribution and installation of SDP clients across user need careful analysis to ensure that SDP can be deployed to
devices. Because these systems often use the same IAM maximum benefit.
systems as SDP, the rollouts can be closely coordinated to
simplify the user experience. These systems often also provide Cloud Access Security Brokers (CASB)
functionally rich capabilities around device introspection and
CASBs sit between cloud service users and cloud
profile evaluation. An SDP can make API calls into a device
applications and monitor all activity related to the
management platform to obtain information about a specific
enforcement of security policies. They offer a variety
device, and it can then make dynamic access decisions based
of services, including monitoring user activity, warning
on the information.
administrators about potentially hazardous actions, enforcing
Alternatively, organizations that do not have an endpoint
security policy compliance, and automatically preventing
management system, can take advantage of the management
malware.28 CASBs may sit in-line between users and cloud
and control of devices provided by SDP.
services, or they may use SaaS APIs to sit “inside” the SaaS
system, depending on the vendor and the level of API support
Web Application Firewalls (WAF)
within the SaaS platform.
Web Application Firewalls (WAFs) are designed to filter, CASB capabilities typically do not overlap with those of SDP
monitor, and block HTTP(S) web traffic to and from web because they generally operate at Layer 7 (application layer),
applications. WAFs introspect application protocol traffic examining application traffic. They typically do not provide
to block attacks from application security flaws, such as SQL network security or access control. However, their operations
injection, cross-site scripting (XSS), and file inclusion. 27
WAFs can be simplified by also using SDP for data protection and
are not a network access control or network security solution, user behavior analysis.
despite typically operating inline in the network between

28 https://en.wikipedia.org/wiki/Cloud_access_security_broker
27 https://en.wikipedia.org/wiki/Web_application_firewall

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

34

Infrastructure as a Service (IaaS) Platform as a Service (PaaS)

Security for IaaS platforms is built around an industry- Platform-as-a-Service32 offerings allow enterprises to build
standard “shared responsibility” model, 29
in which cloud and deploy custom applications with less overhead than
providers have certain responsibilities (security of the cloud), standard hardware or IaaS-based systems. Unlike IaaS and
while customers are responsible for securing their applications SaaS, network access control into PaaS systems (and thus the
(security within the cloud). IaaS customers use cloud network degree to which SDP is relevant) is dependent on the function
security groups 30
to control access to their cloud resources. provided and the ways in which the PaaS provider has enabled
These network security groups are configured and operate as external access controls.
simple firewalls. These security measures can be integrated However, the major PaaS providers support the same
with SDP to create a much more robust security environment.31 network security models for their PaaS platforms as for
IaaS. For example, the Microsoft Azure PaaS security model
Software as a Service (SaaS) 33
supports source IP address restrictions, via Azure network
security groups. So do the Google Cloud Platform App Engine34
SaaS applications such as Salesforce.com and Office
and AWS Elastic Beanstalk.35 The various SDP models can be
365 are multi-tenant and are publicly accessible on the
deployed depending on what the PaaS applications are and
Internet. Preventing network-level access by unauthorized
which connections need to be secured.
users is currently not a goal for these systems. Organizations
may wish to strengthen security when using SaaS applications
Governance, Risk Management, and
for the following reasons:
Compliance (GRC)
• Ensure only authorized users on authorized devices
The discipline of governance, risk management, and
can access the SaaS tenant for that particular
compliance,36 which is often part of an enterprise’s
organization
overall enterprise security framework, helps ensure
• Ensure managed corporate IAM credentials are used
organizations achieve security objectives and act
to authenticate to SaaS applications
with integrity. GRC systems, often implemented through
• Enforce multi-factor authentication for access to the purchased GRC software,37 define and enforce controls
SaaS application around many organizational systems, including IT, typically via

• Ensure all user visits to the SaaS application are standards and guidelines (e.g. SOX, PCI, etc.).

identified and logged SDPs can interact with and support GRC systems by
enforcing and documenting access controls required by GRC.

A growing number of SaaS providers recognize that For example, a GRC system may require that production

their enterprise customers want these benefits and have systems be isolated from non-production systems, and that

begun including “source IP address and device restriction” all user access to production systems be logged. An SDP can

capabilities. These features work equally well with SDP and enforce this network segmentation, and it can provide the GRC

traditional VPNs, and enable a SaaS customer to restrict user system with an audit log for validation.

access (logins and usage) for their domain (tenant) via specific
IP addresses. For SDP, that source IP is an element of the
system (the gateway) through which user traffic is routed and
authorized or denied. 32 https://en.wikipedia.org/wiki/Platform_as_a_service
33 https://docs.microsoft.com/en-us/azure/security/security-paas-deployments
34 https://cloud.google.com/vpc/docs/firewalls
35 https://aws.amazon.com/premiumsupport/knowledge-center/security-group-elas-
29 https://aws.amazon.com/compliance/shared-responsibility-model/ and https://blogs.
tic-beanstalk/ and https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.
msdn.microsoft.com/azuresecurity/2016/04/18/what-does-shared-responsibility-in-the-
managing.ec2.html
cloud-mean/
36 https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance
30 https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html and
37 https://searchcio.techtarget.com/definition/GRC-governance-risk-management-and-com-
https://docs.microsoft.com/en-us/azure/virtual-network/security-overview
pliance-software
31 https://downloads.cloudsecurityalliance.org/assets/research/sdp/sdp_for_iaas.pdf

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

35

Public Key Infrastructure (PKI) designed to be public. However, other services (or other cloud
providers) may choose to follow a different security model, in
Public Key Infrastructure (PKI)38 is “a set of roles, policies, which each customer has their own dedicated access point for
and procedures needed to create, manage, distribute, use, the “as a service” function. In this model, SDP can be applied to
store, and revoke digital certificates and manage private secure the private access point by an SDP gateway.
and public keys used for encryption, decryption, hashing
and signing.” SDPs may use PKI to generate TLS certificates Architectural Considerations
and secure connections. Even if no PKI infrastructure exists,
SDPs can provide TLS certificates to secure connections.39 While broad enough to cover a substantial set of network
Existing PKIs are a natural integration point for SDPs because access scenarios, SDP is not intended to solve all security
they can be used by the SDP certificate generation as well as issues. Some exclusions include the following areas:
optionally for user authentication. • Securing or controlling access to public network
services (such as a website that does not
Software-Defined Networking (SDN) require authentication)—SDP is better suited to
membership-based services
Software-Defined Networking is an API-driven
orchestration of the IT network infrastructure used to • Endpoint protection
enable orchestration of network routing within an IT • Certain computing models, such as serverless
network. SDN enables efficient network configuration in computing
order to improve performance and monitoring.40 The focus
• Certain network connection topologies, such as peer-
of SDN is traffic efficiency—not security and authorization. A
to-peer, depending on the SDP deployment model
well-run SDN system delivers reliable, efficient, and adaptive
(see “SDP Deployment Models and Corresponding
network bandwidth to an enterprise.
Scenarios” on page 19)
SDP provides orchestration of connections between
objects on the network regardless of the underlying network
infrastructure. SDP can be integrated to benefit from the
deployment of an SDN, but does not require one. For example,
SDP and SDN controllers can be integrated. An SDN can also
provide network Quality of Service (QoS) for the opaque,
encrypted mTLS connection.

Serverless Computing Models

As computing models evolve, security tools and

architectures must evolve along with them. One example
is the growth in “serverless” computing models,41 in which a
cloud provider offers the capacity to run either custom code
(in a “function as a service” model) or a pre-built set of code
(such as in a “serverless database”).
A “function as a service” model may expose a universal
public endpoint to the entire Internet and use an API key to
control authentication and authorization. In this case, the
SDP models would not apply because these interactions are

38 https://en.wikipedia.org/wiki/Public_key_infrastructure
39 https://cloudsecurityalliance.org/download/software-defined-perimeter-glossary/
40 https://en.wikipedia.org/wiki/Software-defined_networking
41 https://en.wikipedia.org/wiki/Serverless_computing

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

36

CONCLUSION
Information security presents such critical challenges to
today’s enterprises and governmental institutions that
we must all adopt more effective approaches to securing
our organizations’ data assets. The Software-Defined
Perimeter (SDP) approach can give security professionals
in organizations the tools they are seeking to provide a
strong, adaptable, and manageable foundation for robust
development, operations and security. We hope this document
provides security professionals with a better understanding of
how SDP architecture works and how it can be deployed into
their unique situations.
However, our job is not done. We have more topics to
cover in future research, including papers on each of the
discrete SDP deployment models and integrations presented
above, plus elaboration of the benefits of SDP for various
businesses, compliance controls mapping tools based on SDP
deployments, and many other publication goals.
Most importantly, we recognize that we do not have all
the answers! We invite you to join our SDP Working Group
to engage in the conversation and offer your contributions.
As security professionals who support a secure, open, and
available Internet, and as ethically motivated human beings,
we are working hard to secure a better future. We hope you’ll
join us on this journey. Learn more about participating at
https://cloudsecurityalliance.org/working-groups/software-
defined-perimeter/.

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

37

Appendix 1

ADDITIONAL RESOURCES
“Software-Defined Perimeter Working Group: SDP Specification 1.0,” by Brent Bilger, Alan Boehme, Bob Flores, Zvi Guterman,
Mark Hoover, Michaela Iorga, Junaid Islam, Marc Kolenko, Juanita Koilpilla, Gabor Lengyel, Gram Ludlow, Ted Schroeder, and Jeff
Schweitzer (CSA, April 2014).
SDP v1.0 Spec

“Software-Defined Perimeter for Infrastructure as a Service,” by Jason Garbis and Puneet Thapliyal (CSA, 2016).
SDP for IaaS

“Software-Defined Perimeter Working Group Glossary,” Cloud Security Alliance (CSA, 2018).
SDP Glossary

“Zero Trust Networks: Building Secure Systems in Untrusted Networks,” by Evan Gilman and Doug Barth (June 2017).
http://shop.oreilly.com/product/0636920052265.do

“fwknop: Single Packet Authorization > Port Knocking,” by Michael Rash (CipherDyne).
http://www.cipherdyne.org/fwknop/

“Open Source Software-Defined Perimeter,” Waverley Labs.

http://www.waverleylabs.com/open-source-sdp/

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

38

Appendix 2

SPA DETAILS
Below is the format of the SPA packet as defined in the SDP 1.0 specification.

Nonce Prevents servicing outdated SPA packets

Timestamp Most common: Service Access Request

Possibly deprecated: access request, NAT access request,

Message Type
gateway command message
CIPHERTEXT
Message String Source IP address to allow, service ID(s) to open

NOTE: Gateway knows which port to open as well as

Optional Fields
whether and where to forward the connection.

Digest NOTE: Might be used to request tunneling of service traffic.

Before encryption, this SHA256 hash is calculated over

the ciphertext portion of the message and then used by
CLEARTEXT HMAC
the server to verify message integrity after a successful
message decrypt.

A suggested improvement to this definition is to add a cleartext client ID, which would allow for more efficient handling of
incoming packets. An effort to design a binary SPA format is under way, as well as the creation of an RFC document to describe
the format.
SPA is most effective when sent as a single UDP packet. In some use cases, this is not practical as network environments may
block some or all outgoing UDP packets. In such cases, SPA packets can be sent over TCP connections. This technically violates the
“Single Packet” nature of SPA, but is sometimes necessary as a practical consideration.
A SPA packet can be sent by the connecting machine or another device. An example of this use is when a mobile device is used
to send a SPA packet on behalf of a desktop computer. In some scenarios, this also is a reasonable workaround for an environment
that blocks UDP packets.

© Copyright 2019, Cloud Security Alliance. All rights reserved.