TECHNICAL BRIEF

From VPN to SDP

Implementation Guide

A Software Defined Perimeter (SDP) offers a compelling alternative to traditional VPNs. An SDP allows you
to deploy and secure remote access for all users, scale rapidly and economically and reduce the potential
risk of attacks.

In Gartner’s words, “Enterprise access requirements are growing ever more complex due to application
dynamics, cloud adoption and mergers. To cut through this complexity, technical professionals should
explore Software Defined Perimeters (SDP)—a new technology whose strength lies in facilitating access
to enterprise apps.”

In other words, it’s time to upgrade from legacy VPN to SDP. But how do you do this from a practical perspective?

This paper walks you through five steps for implementing an SDP solution.

WHY SDP AND NOT VPN? DDoS Attacks

Traditional VPNs were invented more than 20 years ago, at a time
when all enterprise apps were hosted in local data centers and
most employees were working on premises.
But it’s a different world today. The network perimeter that VPNs
were designed to protect has dissolved. A typical enterprise has
dozens and often hundreds, of applications hosted on public
clouds like Amazon Web Services (AWS).
VPNs have several shortcomings that make them poorly suited for
today’s needs and ripe for replacement.
Zero Trust
VPNs provide broad access to the enterprise network. Once a
remote user is authenticated, they are considered trusted. As a
result, VPN access is overly permissive. It grants remote workers
access to more of the network than is required to complete their
tasks. In this setup, network resources are unnecessarily visible,
overly vulnerable and open to attack.
An SDP, on the other hand, takes an identity-based, zero-trust
approach that enforces a custom policy for each user device.
Each connection is treated as untrusted and is, therefore,
verified continuously.
Traditional VPN gateways can be discovered with reconnaissance
methods and fall victim to distributed denial-of-service (DDoS)
attacks. A cloud-based SDP solution essentially cripples
reconnaissance attacks.
User Experience
When you have to backhaul traffic to a centralized data center
for VPN termination or for security purposes, there is latency
that degrades the application’s performance. In addition,
your users often face unreliable client applications and
complex configurations.
Concurrent Access to Multiple Apps and Clouds
VPNs were never designed for hybrid clouds or distributed cloud
computing. It’s not uncommon for a salesperson working remotely
to require access to a manufacturing system in the data center,
a supply chain app hosted on AWS and a customer resource
management (CRM) system hosted on Azure. From your users’
point of view , this translates either to an annoying stream of
connecting to and disconnecting from different resources or to the
latency associated with backhauling through a VPN concentrator.
 FROM VPN TO SDP | TECHNICAL BRIEF

1 2 3 4 5

In contrast, SDP architecture inherently supports multi-app, multi- For example, if up to this point you have opened IP 192.168.0.0/16
cloud connectivity. This enables clients to establish and maintain for remote users, you would now split the subnet into three
concurrent access between many applications and services. separate entities. Then you would specify for each:
• Service name (an easily identifiable application/service name)
Management • IP or FQDN
VPN management increases in complex as you move more • Port
enterprise applications to the cloud. SDP offers a dramatically
simpler administration of any number of data centers and cloud
SERVICE IP DNS PORT
deployments, with a single pane of glass for defining policy and
tracking events. With SDP, you onboard each network resource JIRA 192.168.20.10 jira.acme.corp 443
once. You manage all policies centrally and avoid the need to Jenkins 192.168.10.25 jenkins.acme.corp 8080
configure and sync across different locations. CRM 192.168.1.33 dynamics.acme.corp 443
Back-End 10.0.0.25 10.0.0.25.ec2.internal 22
FIVE STEPS FOR SDP IMPLEMENTATION Server
To set up an SDP to replace an existing remote access VPN, you Front-End 10.0.1.100 10.0.1.100.ec2.internal 22,443
need to follow five key steps. You begin with analyzing the access Server
requirements of your organization (steps 1–2). You then proceed
with implementing these policies within the SDP administration
console and onboarding users and resources (steps 3–5). By the end of this stage, you should have a complete, detailed list
of all enterprise services/applications (cloud and on premises) that
require access by employees, contractors, partners and customers.
1 DESIGNATE TARGET APPLICATIONS
While using VPNs, your practice was to provide network access to
a VLAN or to a range of IPs. With SDP, your goal is to provide fine-
grained access based on user needs. The first step you need to take
is to create a list of the specific enterprise applications and services
that you want to make selectively available to each use group.
You can begin by identifying the list of applications to expose using
a fully qualified domain name (FQDN), a local domain name or IP
address and port.

2
 FROM VPN TO SDP | TECHNICAL BRIEF

Full tunneling routes all enterprise and internet traffic through a

2 ONBOARD USERS AND DEFINE ACCESS NEEDS
The second step to switch from VPN to SDP requires you to define
the users that will access each of the applications and resources,
including the required connectivity and authentication methods.
You need to classify users into groups based on the access
requirements. (For example, you can specify that R&D and QA can
access Jira, but cannot access the sales and marketing file server.)
Groups
You need to define different user groups according to their roles or
the access that they require.
Users
Next, you need to define the list of individual users within each
group. You can do this by extracting data from existing systems
like Active Directory, Azure ID, Okta, OneLogin or any other identity
provider. If the identity provider (IdP) supports cross‑domain
identity management (SCIM), you will also benefit from
automatic synchronization.
Access Type
Now, you need to determine the required access type for each of
the services and applications.
• Agent-based access: Allows users seamless access (as if they
were in the office) to any application or network resources allowed
by their policy.
secure IPsec tunnel. This ensures that the device is secured at all
times. It is most often used for employees with managed devices
that need access to a variety of sensitive resources.
Split tunneling (ST) separates enterprise traffic from internet
traffic. It uses anIPsec tunnel to provide access to enterprise
resources. Other traffic (such as over a local network to the
printer or out to the internet) is not secured. This approach
offers a different standard of internet privacy. It is often applied
to non‑employees.
• Clientless, or no client (NC): Allows users to access the
resource via the browser, without any client installed. You can use
this, for instance, for external contractors. Clientless connectivity
is limited to applications that run inside a browser, such as web,
RDP and SSH.
Authentication Method
Here you define the authentication methods you would like to
enforce for user devices (for example, a username/password,
two-factor authentication [2FA] or single sign-on [SSO] using an
IdP). You can also apply posture checks to make sure a device is
compliant with an enterprise policy, such as running a predefined
anti-virus, or joined to an Active Directory Domain.

Users
SERVICE IP DNS PORT GROUP
JIRA 192.168.20.10 jira.acme.corp 443 Support, QA, RND, Ops
Jenkins 192.168.10.25 jenkins.acme.corp 8080 RND
CRM 192.168.1.33 dynamics.acme.corp 443 Sales
Back-End Server 10.0.0.25 10.0.0.25.ec2.internal 22 RND, Ops
Front-End Server 10.0.1.100 10.0.1.100.ec2.internal 22,443 RND, Ops

Access Type
SERVICE IP DNS PORT GROUP ACCESS
JIRA 192.168.20.10 jira.acme.corp 443 Support, QA, RND, Ops Clientless
Jenkins 192.168.10.25 jenkins.acme.corp 8080 RND Clientless
CRM 192.168.1.33 dynamics.acme.corp 443 Sales Clientless
Back-End Server 10.0.0.25 10.0.0.25.ec2.internal 22 RND, Ops Agent-based
Front-End Server 10.0.1.100 10.0.1.100.ec2.internal 22,443 RND, Ops Agent- based

3
 FROM VPN TO SDP | TECHNICAL BRIEF

Lightweight SDP connectors provide a secure interface between your existing servers and the
SDP cloud and facilitate microsegmented user access to applications. For example, the above
architecture shows the Proofpoint Meta cloud with three SDP connectors for AWS, Jira and Jenkins.

By using a connector, you can reduce the attack surface by hiding

3 CONFIGURE SDP CONNECTORS the services from the internet. This prevents DDoS and other
Lightweight connectors, typically provided by the SDP solution,
attacks. As a backup, you may leave your current access methods
provide you with secure authenticated interface between existing
in place.
servers and the SDP cloud. Once you configure the connectors,
users can access your applications via the SDP. For example, SDP connectors may be delivered as a virtual
machine (VM) image for deployment in enterprise data centers,
An important issue with SDP connectors is that they don’t require
local private cloud environments such as VMware or public cloud
any changes to your existing topology, such as changes to your
environments such as AWS EC2.
local demilitarized zone (DMZ) or AWS security groups.

4
 FROM VPN TO SDP | TECHNICAL BRIEF

The Proofpoint Meta console enables setting up identity-based, custom policies for groups and users.
These define access to specific applications and services. Administrators can also view a visual map
showing the access policies for any user or group.

groups and user identity rather than IPv4 MAC addresses. All access
4 SET SDP POLICIES is safelisted. This requires you to explicitly define a policy for an
During this stage, you implement the access policies you planned
enterprise resource, including the specific protocol.
in the previous steps using the SDP administrative console.
Below, you can see an example of the Proofpoint Meta administrative
console. This is where administrators define access policies using

5
 FROM VPN TO SDP | TECHNICAL BRIEF

The Proofpoint Meta SDP offers various monitoring and auditing capabilities.
It gives you the ability to view all users and devices connected to enterprise
resources, their geographic locations and connectivity method.

can examine and filter any type of event, as well as define alert
5 DEFINE ALERTS AND AUDIT PROCEDURES notifications to be sent to email, webhooks (integrating with SaaS
Finally, as a CISO, CIO or other IT/security manager, you want to be
apps), PagerDuty or Slack. For instance, you may define an alert to
able to easily track and audit remote user activities. An SDP provides
be sent when a specific user accesses a sensitive system via VPN.
you with a single pane of glass for tracking access and network
As another option, you may also configure a continuous export of
activity across systems.
logs from your SDP system to a third-party SIEM.
Built-in access logs and alerts let you monitor data, including
network traffic and activities taken within the SDP system, or various
security events like password resets and missing certificates. You

LEARN MORE
For more information, visit proofpoint.com.

ABOUT PROOFPOINT
Proofpoint, Inc. (NASDAQ: PFPT) is a leading cybersecurity and compliance company that protects organizations’ greatest assets and biggest risks: their people. With an integrated suite of cloud-based
solutions, Proofpoint helps companies around the world stop targeted threats, safeguard their data, and make their users more resilient against cyber attacks. Leading organizations of all sizes, including
more than half of the Fortune 1000, rely on Proofpoint for people-centric security and compliance solutions that mitigate their most critical risks across email, the cloud, social media, and the web. More
information is available at www.proofpoint.com.
©Proofpoint, Inc. Proofpoint is a trademark of Proofpoint, Inc. in the United States and other countries. All other trademarks contained herein are property of their respective owners. Proofpoint.com

1209-001-01-02 6/21