Security & Analytics

Why a Software-Defined Perimeter?

The Enterprise Perimeter No Longer Exists

20 years ago, applications sat on servers in one room. Access control was a perimeter set by a simple firewall existing between IP addresses and servers. Effective, if everything stayed in one place. 

Today, applications reside in globally-distributed public clouds, on third-party managed hosting platforms, in corporate data centers as well as collocated data centers. Users are mobile and distributed. 

The perimeter has dissolved. We need to re-establish the security perimeter back where it belongs, with the user.

60% of enterprises will phase out network VPNs in favor of software-defined perimeters by 2021.

Gartner, It’s Time to Isolate Your Services from the Internet Cesspool.

Anyone attempting to access a resource must authenticate first. All unauthorized resources are invisible. This applies the principle of least privilege (or zero trust) to the network. This also completely reduces the attack surface. 


Why a Software-Defined Perimeter?

A Software-Defined Perimeter overcomes the constraints of traditional tools by creating an individualized perimeter for each user. A segment of one, based on the user’s identity, device profile, location and authentication method. 

Users obtain the access needed to be productive, controlled by a simple set of polices, thereby reducing the workload on security and network teams.

CSA at RSA 2017 - The Software-Defined Perimeter

Watch the Cloud Security Alliance Summit keynote on the Software-Defined Perimeter and why it’s important. It covers the following reasons why enterprises are moving to a Software-Defined Perimeter:

  • IT is becoming Hybrid and Diversified
  • Hybrid IT Spans Platforms, Tenancy, Locations
  • Embracing Trends Including Identity-Centric Security
  • TCP/IP is a Weak Security Foundation
  • The Brilliance of a Software-Defined Perimeter

How a Software-Defined Perimeter Works


A Software-Defined Perimeter (SDP) architecture is made up of three main components:

  • A Client – runs on each user’s device
  • A Controller – where users authenticate, policy is applied and users are evaluated. The controller issues tokens granting each user their individualized network entitlements
  • A Set of Gateways – brokers access to protected resources

Users and their devices are validated with multi-factor authentication. User and device context are included in the controller’s evaluation. Once a user obtains their entitlements from a controller, network traffic to the protected resources is encrypted and tunneled between the device and the corresponding SDP Gateway.

Access to protected resources remain transparent to the user. However, access is logged for compliance and auditing purposes. Access policies determine which users can access which services on which servers.