Software-Defined Perimeters: An Architectural View of SDP

Daniel Conde

IEEE Softwarization, March 2017

 

Introduction

Software Defined Perimeters (SDP) is an emerging security architecture that restricts network access and connections between allowed elements. With origins in the defense IT infrastructure and spreading to enterprise use, it promises to help mitigate a broad set of security vulnerabilities that afflict IT infrastructure protected by conventional perimeter security. SDP serves to identify the source and destination of a network connection and assumes there is no trust between potential participants and a secure connection is only granted when explicitly permitted.

History

Software Defined Perimeters draws on the Defense Information Systems Agency (DISA)’s black cloud that restricts connections only to those with a need to know basis. It was then popularized by the Cloud Security Alliance’s SDP Working Group for creating highly secure and trusted end-to-end networks for broader enterprise use.

The term “Software Defined” has been popular but often lacks a clear definition.  It has been used in many contexts such as Software Defined Network (SDN), Software Defined Wide-Area Network (SD-WAN), or Software-Defined Data Center.   This column helps show where Software Defined Perimeters draws upon similar concepts, its history and where it innovates.

The concepts are not new, and there are predecessors such as network access control (NAC) that restricted client end-point devices to connect to networks. It uses concepts found in Software Defined networks, such as the separation of the data plane for communications from the control plane. The SDP concept is useful for servers and client endpoints, and may be used in clouds as well as in traditional data centers. SDP combines many of these elements to create a new architecture.

SDP is not a replacement for existing solutions, but an architecture that complements and builds upon existing solutions such as SDN.

Principles

From an IT infrastructure perspective, as opposed to a security viewpoint we can distill the SDP concepts into these principles. In this column the word “hosts” is used, although that includes client end-points.

  1. Separation of the control plane from the data planes. Ability to control access is managed separately from the transmission of data. This means that permission is separated from access, and makes data transport independent and enables each part to be managed and grow separately. Control plane is handled by an SDP controller.
  2. Separation of the logical and physical components. Related to (1), the connections between hosts are virtualized using overlay tunnels that represent logical connections that traverse a physical network.  This enables communications to be secure and not restricted to physical topologies.
  3. Authenticating the hosts. Only those elements that are authorized will be able to participate in communication.
  4. Validating the hosts against a set of policies that determines whether or not security constraints are met. This includes verifying the hosts for absence of malware, only allowed applications can connect, or other business policies such as time of day when connections are allowed, or other external signals such as threat-intelligence data.

How it differs from traditional security

Traditional perimeters security protects against external attacks and access.  This no longer works if intrusions compromise elements inside the external perimeter. Rather than using a default of not trusting external access and trusting access inside the security perimeter, SDP trusts no-one as a default, and admits access on a case-by-case basis.

SDP works across resources as varied as traditional end-points, data centers or clouds, since overlay tunnels can traverse different types of infrastructures. Hosts gaining access may include traditional PCs, mobile devices, or even Internet of Things (IoT).  Locations may include public clouds, data centers, traditional campus networks or remote offices. Resources may include cloud services (exposed via REST APIs) or traditional client-server data center apps accessing applications or data.

The Cloud Security Alliance (CSA) lists these deployment modes for SDP.

  • Client-Gateway – SDP uses a proxy that arbitrates connections between clients and a set of protected servers. A client connects to a gateway which in turn provides access to hosts that provide services.
  • Client-Server – there is no gateway proxy sitting between the client and server. The clients directly connect to the hosts.
  • Server to Server – used for servers offering services (via REST APIs) to applications.
  • Client to Server to Client – peer to peer connections between clients.

For hosts to initiate a connection the following workflow steps are necessary.  The CSA white paper lists 7 steps, but we use a simplified edition since we assume that the SDP infrastructure is already brought up:

  1. Authenticate hosts that initiate connections, and receiving connections to central controllers.
  2. Each host identifies only the hosts it can communicate with.
  3. Validate the hosts against security policies (host type, malware checks, time of day, etc.)
  4. Connect the hosts using a Virtual Private Network (VPN) tunnel to allowed accepting hosts.

These steps, while seemingly simple, accomplish many goals for security in an elegant way since they provide for these benefits:

  1. Partitioning of the network. This is like micro segmentation seen in software-defined networking today.
  2. Reducing the attack surface. If the resources are not exposed through conventional means (known host names, IP addresses, etc.) and access is arbitrated by a controller, then the potential security targets are not known, reducing the opportunity for attacks such as Distributed Denial-of-Service (DDOS), Man-in-the-Middle or Advanced Persistent Threats.
  3. Unify security between cloud and other non-cloud resources. Developing a uniform security model that extends from on-premises data centers to cloud resources is difficult using conventional network security methods. Abstracting the network transport via overlay tunnels creates a set of connections that spans different deployment models – whether cloud-hosts, on-premises data centers, or remote offices. This enables the use of uniform model for network connections that allows the use of network security controllers that enforces policies.

Potential Challenges

A complete SDP solution cannot be slipped into an existing infrastructure without some disruptions in the network and software infrastructure.  Applications and operating system configurations need to be aware of SDP to access SDP workflow and secure tunnels. The presence of a controller means there is another element for networks to rely on, and it needs to be secured and be made highly available.

These challenges can be overcome.  SDPs use conventional IP networks and does not change the fundamental architecture of layer 2 through 7 networking. Existing network and security management and monitoring tools and operational procedures may need to change if conventional security methods are replaced by SDP.

Commercial and open source solutions

Commercial and open source solutions provide SDP.  Products from Vidder and CryptZone market SDP solutions.  Existing products provide for key elements found in SDP, such as Cisco ACI (and a similar open source project, Group Based Policy), VMware NSX, Nuage VSP. Google has published its BeyondCorp efforts that shares these concepts. Cisco, HPE, Juniper offer NAC solutions that also offer SDP-like elements.  Service providers such as Verizon Enterprise have started to embrace these concepts.  The zero trust network concepts are adopted by many security or network gear vendors.

Conclusion

SDP promises to solve many security challenges. The architecture leverages existing technologies, such as VPN tunnels, combines it with modern concepts from SDN and micro segmentation to provide an architecture that shows promise for solving many security problems. It has demonstrated success in military security and may be extended for commercial and enterprise deployments.  It shows promise in cloud based applications that fundamentally exhibit distributed deployment models and do not fit into a traditional perimeter security model.

References

Department of Defense Global Information Grid Architectural Vision, http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA484389

Software Defined Perimeter Working Group, https://cloudsecurityalliance.org/group/software-defined-perimeter/

 


 

Neil DaviesDaniel Conde is an analyst covering distributed system technologies including cloud computing and enterprise networking. In this era of IT infrastructure transformation, Dan’s research focuses on the interactions of how and where workloads run, and how end-users and systems connect to each other. Cloud technologies are driving much of the changes in IT today. Dan’s coverage includes public cloud platforms, cloud and container orchestration systems, software-defined architectures and related management tools. Connectivity is important to link users and applications to new cloud based IT. Areas covered include data center, campus, wide-area and software-defined networking, network virtualization, storage networking, network security, internet/cloud networking and related monitoring & management tools. His experience in product management, marketing, professional services and software development provide a broad view into the needs of vendors and end-users.

 

Editor:

Francesco BenedettoFrancesco Benedetto was born in Rome, Italy, on August 4th, 1977. He received the Dr. Eng. degree in Electronic Engineering from the University of ROMA TRE, Rome, Italy, in May 2002, and the PhD degree in Telecommunication Engineering from the University of ROMA TRE, Rome, Italy, in April 2007.

In 2007, he was a research fellow of the Department of Applied Electronics of the Third University of Rome. Since 2008, he has been an Assistant Professor of Telecommunications at the Third University of Rome (2008-2012, Applied Electronics Dept.; 2013-Present, Economics Dept.), where he currently teaches the course of "Elements of Telecommunications" (formerly Signals and Telecommunications) in the Computer Engineering degree and the course of "Software Defined Radio" in the Laurea Magistralis in Information and Communication Technologies. Since the academic year 2013/2014, He is also in charge of the course of "Cognitive Communications" in the Ph.D. degree in Applied Electronics at the Department of Engineering, University of Roma Tre.

The research interests of Francesco Benedetto are in the field of software defined radio (SDR) and cognitive radio (CR) communications, signal processing for financial engineering, digital signal and image processing in telecommunications, code acquisition and synchronization for the 3G mobile communication systems and multimedia communication. In particular, he has published numerous research articles on SDR and CR communications, signal processing applied to financial engineering, multimedia communications and video coding, ground penetrating radar (GPR) signal processing, spread-spectrum code synchronization for 3G communication systems and satellite systems (GPS and GALILEO), correlation estimation and spectral analysis.

He is a Senior Member of the Institution of Electrical and Electronic Engineers (IEEE), and and a member of the following IEEE Societies: IEEE Standard Association, IEEE Young Professionals, IEEE Software Defined Networks, IEEE Communications, IEEE Signal Processing, IEEE Vehicular Technology. Finally, He is also a member of CNIT (Italian Inter-Universities Consortium for Telecommunications). He is the Chair of the IEEE 1900.1 WG on dynamic spectrum access, the Chair of the Int. Workshop on Signal Processing fo Secure Communciations (SP4SC), and the co-Chair of the WP 3.5 on signal processing for ground penetrating radar of the European Cost Action YU1208.

 


 

Subscribe to IEEE Softwarization

Join our free SDN Technical Community and receive IEEE Softwarization.

Subscribe Now

 


Article Contributions Welcomed

Download IEEE Softwarization Editorial Guidelines for Authors (PDF, 122 KB)

If you wish to have an article considered for publication, please contact the Managing Editor at sdn-editor@ieee.org.

 


Past Issues

November 2018

March 2018

January 2018

December 2017

September 2017

July 2017

May 2017

March 2017

January 2017

November 2016

September 2016

July 2016

May 2016

March 2016

January 2016

November 2015


IEEE Softwarization Editorial Board

Laurent Ciavaglia, Editor-in-Chief
Mohamed Faten Zhani, Managing Editor
TBD, Deputy Managing Editor
Syed Hassan Ahmed
Dr. J. Amudhavel
Francesco Benedetto
Korhan Cengiz
Noel Crespi
Neil Davies
Eliezer Dekel
Eileen Healy
Chris Hrivnak
Atta ur Rehman Khan
Marie-Paule Odini
Shashikant Patil
Kostas Pentikousis
Luca Prete
Muhammad Maaz Rehan
Mubashir Rehmani
Stefano Salsano
Elio Salvadori
Nadir Shah
Alexandros Stavdas
Jose Verger