Introduction to a Software Defined Perimeter
Typically, to gain remote access to internal applications, users connect with a Virtual Private Network (VPN) through an appliance that is deployed in a central data center, through which they gain wide access to the enterprise/internal network. However, the WAN/VPN architecture is not the ideal basis for network security. It was originally designed for connectivity, not for isolation.
Security appliances can be added to the WAN to reduce the risk of remote access. Unfortunately, these do not overcome disadvantages such as isolation limitations, policy synchronization, operational issues, and poor user experience.
We need to move away from the site-centric topology approach that VPNs apply, to a model where the perimeter moves with the users. The combination of factors including mobile working, outsourcing, cloud adoption, and mergers require a shift from old architectures to the software-defined perimeter (SDP) model.
Introducing Proofpoint Meta NaaS
The software-defined perimeter is a technology that provides confidential and secure remote access to enterprise applications. Proofpoint Meta offers a Zero-Trust NaaS, a cloud-native SDP solution built on a global network of software-based PoPs.
The architecture provides a zero-trust alternative to VPN for secure remote access to any application located anywhere. It acts as a broker between the user and the application. Before, the emphasis was on connecting everything to the data center; however, now it has shifted to the model of connecting users only to the applications and resources they need.
Instead of positioning the data center in the middle, the user is now the center of the network, enabling a software-defined perimeter that follows the user’s device regardless of the location. When connecting, the users do not need to be concerned about where the resources are located. To the user, it’s a "flat" network.
Proofpoint Metas’ approach employs zero-trust principles, using identity-based access, dynamic segmentation, a whitelist policy and central access policy management, all delivered from a cloud-native service.
Zero-Trust Principles
First and foremost, the zero-trust movement promotes the idea that just because you are an employee does not mean you should have access to everything, or should automatically be trusted. Users must be consistently authenticated and verified.
Once authenticated and verified, they are exposed only to the resources they are allowed access to - the ones they truly need. Essentially, all the users are on a ‘need to know’ basis - not necessarily because they should not be trusted, but because their devices should not be trusted.
Identity-Based Access
All access is based on the identity that is embedded into the traffic. Every packet that goes through the system is tied to an explicit identity and each identity is backed by a certificate. The certificate carries information about the device, users and organization.
All the information is then cross-referenced with other forms of information, for example, what location did the user connect from? The system then checks if the user is allowed access based on the given identity and device posture.
'Authenticate then Access'
The 'authenticate then access' approach demands that several factors need to be passed before connection is established. The first is the certificate that the user needs to provide. Then there are additional factors such as username/password, SMS or a mobile authenticating application for a one-time password (OTP).
The benefit of this approach is that the network is hidden from view until the authentication is completed. This significantly reduces the opportunity for attackers to identify a target.
The Dynamic Segment of 1
When a user connects to Meta NaaS, upon successful authentication, he or she is granted a dynamic segment of 1 that provides policy-defined access to specific resources. There is a one-to-one network connection between each user and the resources accessed.
There can be multiple segments of 1 granted to a user or device. Instead of having access to everything on a VLAN, the user can only access devices and services that they are allowed to. Everything else is isolated and hidden in a secure enclave. By barricading the enterprise’s topology, SDP solutions dramatically improve security compared to VPNs.
Lockdown on DDoS and Lateral Movements
As all other resources outside the policy are isolated, the user literally cannot see anything they are not entitled to. As a result, the attack surface is dramatically reduced and lateral movements inside the enterprise network are prevented, along with DDoS attacks on external-facing apps.
Blacklist & Whitelist
Traditionally, once a user is connected to the network, by definition, they are connected to everything that is connected to that segment. The blacklist approach to security starts whereby, for example, VLANs and ACL’s are added to restrict access to certain segments.
The blacklist approach is manual and therefore error-prone. Every device needs to be known and the policies must be synchronized across various data center, cloud and branch locations. This adds additional risks and even more when dealing with different vendors and technologies (like clouds, data center, etc.).
However, the whitelist approach works the other way round. Whitelist starts with a default 'deny all' approach. Nothing is trusted. Whitelist rules are then created to allow the users, devices, services, and applications to talk to one another. Whitelist rules explicitly allow access.
Cloud-Delivered Remote Access
If you need to support remote access all over the world, it makes sense to cloud-deliver the service rather than attempting to install a VPN concentrator in a cloud or data center close to the user. Proofpoint Meta has built an intelligent and globally distributed cloud-native network that allows users to connect and consume access as a service.
It consists of software-based PoPs strategically located around the world. It’s an agile software-based solution as opposed to the traditional hardware-based technology, therefore it's easy to scale and spin-up additional PoPs in response to new customer requirements.
The data plane consists of a mesh of IPSec tunnels hosted in a variety of providers around the world. Since PoPs are not dependent on any one provider, it gives Meta’s NaaS both geographic flexibility and better availability and resilience.
The control plane consists of a smart mathematical way for encoding the identity and policy into the network traffic in a scalable and efficient way. The management plane governs, monitors and collects information about the control and data plane. It provides a centralized location for API and UI based administration and orchestration.
Cloud-Delivered Network Security
Meta NaaS operates at layer 3 and layer 4 without opening up any traffic or compromising the customer’s privacy (e.g. SSL packets or examining URLs). If customers require deeper security, user traffic can simply be routed to an additional security stack, for example, a next-generation firewall or secure web gateways for further screening.
Routing traffic to an additional security service is performed in the cloud, which requires no changes, installation or integration on the endpoints. This ensures that remote users' Internet-bound traffic is not left unprotected and the end-user devices are not vulnerable to compromise.
Simple Central Policy Management
Users, devices, data center, clouds, and SaaS applications can all be connected to the Meta NaaS. Administrators set policy rules to the connected resource and the enforcement of policy is done in the cloud. As a result, there are no smarts needed on the endpoints, it's just like connecting cables to a global cloud router.
With Meta NaaS, there is one single location to set up the rules, thereby enabling simple central policy management. And there is one single location to collect and analyze the logs coming from all network activity (data plane and management plane).
Ways to Connect
There are multiple options to connect to the Meta NaaS, and the provisioning is easy and quick. One way is to install an agent on each of the services, then each application establishes a VPN tunnel direct to the Meta NaaS.
Alternatively, an on-premise gateway can be installed, creating the tunnel on behalf of the private services or networks.
The third way to access can be done directly in the browser that connects to a dedicated portal. Then no agent is required on the device. This is perfect for unmanaged personal devices, and contractors.
All the three methods enforce the same system-wide policies and preserve the device identity for access as well as for logging purposes.
Learn More
Want to learn more about Proofpoint Meta or get a demo, click here. See for yourself how quick and easy it is to deploy and manage, even in complex, hybrid environments.
Subscribe to the Proofpoint Blog