defined perimeter

Safe-T SDP- Why Rip and Replace your VPN?

by Blog

 

 

SDP VPN

Although organizations realize the need to upgrade their approach to user access control, deploying existing technologies is holding back the introduction of Software Defined Perimeter (SDP). A recent Cloud Security Alliance (CSA) report on the “State of Software-Defined Perimeter” states that existing in-place security technologies are the main barrier to adopting SDP. One can understand the reluctance to leap. After all, VPNs have been a cornerstone of secure networking for over two decades.

They do provide what they say; secure remote access. However, they have not evolved to secure our developing environment appropriately. The digital environment has changed considerably in recent times. A big push for the cloud, BYOD, and remote workers puts pressure on existing VPN architectures. As our environment evolves, the existing security tools and architectures must evolve, also to an era of SDP VPN. And to include other zero trust features such as Remote Brower Isolation.

Undoubtedly, there is a common understanding of the benefits of adopting the zero-trust principles that software-defined perimeter provides over traditional VPNs. But the truth that organizations want even safer, less disruptive, and less costly deployment models cannot be ignored. VPNs aren’t a solution that works for every situation. It is not enough to offer solutions that involve ripping the existing architectures completely or even putting software-defined perimeter on certain use cases. The barrier to adopting a software-defined perimeter involves finding a middle ground.

 

Before you proceed, you may find the following posts helpful:

  1. Zero Trust SASE
  2. SDP Network
  3. Safe-T approach to SDP
  4. Brownfield Network Automation

 



SDP VPN

Key Safe-T SDP Solution points:


  • The need for zero trust and software defined perimter.

  • The different software defined perimter solutions.

  • The challenges of the legacy VPN.

  • SDP vs VPN.

  • Safe-T SDP deployment models.

 

SDP VPN: Safe-T; Providing the middle ground.

Safe-T is aware of this need for a middle ground. Therefore, in addition to the standard software-defined perimeter offering, Safe-T offers this middle-ground to help the customer on the “journey from VPN to SDP,” resulting in a safe path to SDP VPN.

Now organizations do not need to rip and replace the VPN. Sofware-defined perimeter and VPNs ( SDP VPN ) can work together, yielding a more robust security infrastructure. Having network security that can bounce you between IP address locations can make it very difficult for hackers to break in. Besides, if you already have a VPN solution you are comfortable with, you can continue using it and pair it with Safe-T’s innovative software-defined perimeter approach. By adopting this new technology, you get equipped with a middle-ground that improves your security posture and maintains the advantages of existing VPNs.

Recently, Safe-T has released a new SDP solution called ZoneZero that enhances VPN security by adding SDP capabilities. Adding SDP capabilities allows exposure and access to applications and services. The access is granted only after assessing the trust, based on policies for an authorized user, location, and application. In addition, access is granted to the specific application or service rather than the network, as you would provide with a VPN.

Deploying SDP and single packet authorization on the existing VPN offers a customized and scalable zero-trust solution. It provides all the benefits of SDP while lowering the risks involved in adopting the new technology. Currently, Safe-T’s ZoneZero is the only SDP VPN solution in the market, focusing on enhancing VPN security by adding zero trust capabilities rather than replacing it.

 

The challenges of just using a traditional VPN

VPNOverview

While VPNs have stood the test of time, today, we know that the proper security architecture is based on zero trust access. VPNs operating by themselves are unable to offer optimum security. Now, let’s examine some of the expected shortfalls.

The VPN lacks because they cannot grant access on a granular, case-by-case level. This is a significant problem that SDP addresses. According to the traditional security setup, you had to connect a user to a network to get access to an application. Whereas, for the users not on the network, for example, remote workers, we needed to create a virtual network to place the user on the same network as the application.

To enable external access, organizations started to implement remote access solutions (RAS) to restrict user access and create secure connectivity. An inbound port is exposed to the public internet to provide application access. However, this open port is visible to anyone online, not just remote workers.

From a security standpoint, the idea of network connectivity to access an application will likely bring many challenges. We then moved to the initial layer of zero trust to isolate different layers of security within the network. This provided a way to quarantine the applications not meant to be seen as dark. But this leads to a sprawl of network and security devices.

For example, you could use inspection path control with a hardware stack. This enabled the users to only access what they could, based on the blacklist security approach. Security policies provided broad-level and overly permissive access. The attack surface was too wide. Also, the VPN displays static configurations that have no meaning. For example, a configuration may state that this particular source can reach this destination using this port number and policy.

However, with this configuration, the contextual configuration is not considered. There are just ports and IP addresses, and the configuration offers no visibility into the network to see who, what, when, and how they connect with the device.

More often than, access policy models are coarse-grained, which provides users with more access than is required. This model does not follow the least privilege model. The VPN device provides only the network information, and the static policy does not dynamically change based on the levels of trust.

For example, the user’s anti-virus software is accidentally turned off or by malicious malware. Or maybe you want to re-authenticate when certain user actions are performed. In such cases, a static policy cannot dynamically detect this and change configuration on the fly. They should be able to express and enforce the policy configuration based on the identity, which considers both the user and the device.

 

SDN VPN

The new technology adoption rate can be slow initially. The primary reason could be the lack of understanding that what you have in place today is not the best for your organization in the future. Maybe now is the time to stand back and ask if this is the future that we want.

All the money and time you have spent on the existing technologies are not evolving at pace with today’s digital environment. This indicates the necessity for new capabilities to be added. These get translated into different meanings based on an organization’s CIO and CTO roles. The CTOs are passionate about embracing new technologies and investing in the future. They are always looking to take advantage of new and exciting technological opportunities. However, the CIO looks at things differently. Usually, the CIO wants to stay with the known and is reluctant to change even in case of loss of service. Their sole aim is to keep the lights on.

This shines the torch on the need to find the middle ground. And that middle-ground is to adopt a new technology that has endless benefits for your organization. The technology should be able to satisfy the CTO group while also taking every single precaution and not disrupting the day-to-day operations.

 

  • The push by the marketers

There is a clash between what is needed and what the market is pushing. The SDP industry standard encourages customers to rip and replace their VPN to deploy their Software Defined Perimeter Solutions. But the customers have invested in a comprehensive VPN and are reluctant to replace it.

The SDP market initially pushed for a rip-and-replace model, which would eliminate the use of traditional security tools and technologies. This should not be the recommended case since the SDP functionality can overlap with the VPNs. Although the existing VPN solutions have their drawbacks, there should be an option to use the SDP in parallel. Thereby offering the best of both worlds.

 

Software-defined perimeter: How does Safe-T address this?

Safe-T understands there is a need to go down the SDP VPN path, but you may be reluctant to do a full or partial VPN replacement. So let’s take your existing VPN architecture and add the SDP capability.

The solution is placed after your VPN. The existing VPN communicates with Safe-T ZoneZero, which will do the SDP functions after your VPN device. From an end user’s perspective, they will continue to use their existing VPN client. In both cases, the users operate as usual. There are no behavior changes, and the users can continue using their VPN client.

For example, they authenticate with the existing VPN as before. But the VPN communicates with SDP for the actual authentication process instead of communicating with, for example, the Active Directory (AD).

What do you get from this? From an end user’s perspective, their day-to-day process does not change. Also, instead of placing the users on your network as you would with a VPN, they are switched to application-based access. Even though they use a traditional VPN to connect, they are still getting the full benefits of SDP.

This is a perfect stepping stone on the path toward SDP. Significantly, it provides a solid bridge to an SDP deployment. It will lower the risk and cost of the new technology adoption with minimal infrastructure changes. It removes the pain caused by deployment.

 

The ZoneZero™ deployment models

Safe-T offers two deployment models; ZoneZero Single-Node and Dual-Node.

With the single-node deployment, a ZoneZero virtual machine is located between the external firewall/VPN and the internal firewall. All VPN is routed to the ZoneZero virtual machine, which controls which traffic continues to flow into the organization.

In the dual-node deployment model, the ZoneZero virtual machine is between the external firewall/VPN and the internal firewall. And an access controller is in one of the LAN segments behind the internal firewall.

In both cases, the user opens the IPSEC or SSL VPN client and enters the credentials. The credentials are then retrieved by the existing VPN device and passed over RADIUS or API to ZoneZero for authentication.

SDP is charting the course to a new network and security architecture. But now, a middle ground can reduce the risks associated with the deployment. The only viable option is running the existing VPN architectures parallel with SDP. This way, you get all the benefits of SDP with minimal disruption.

 

SDP VPN

 

Zero Trust Access

Safe-T; A Progressive Approach to Zero Trust Access

by Blog

 

 

Zero Trust SDP

The foundations that support our systems are built with connectivity, not security, as an essential feature. TCP connects before it authenticates. Security policy and user access based on IP lack context and allow architectures with overly permissive access. This will likely result in a brittle security posture enabling the need for Zero Trust SDP and SDP VPN.

Our environment has changed considerably, leaving traditional network and security architectures vulnerable to attack. The threat landscape is unpredictable. We are getting hit by external threats from all over the world. However, the environment is not just limited to external threats. There are insider threats within a user group and insider threats across user group boundaries.

Therefore, we must find ways to decouple security from the physical network and decouple application access from the network. We must change our mindset and invert the security model to a Zero Trust Security Strategy to do this. Software Defined Perimeter (SDP) is an extension of Zero Trust Network ZTN, which presents a revolutionary development. It provides an updated approach that current security architectures fail to address.

SDP is often referred to as Zero Trust Access (ZTA). Safe-T’s package of the access control software is called: Safe-T Zero+. Safe-T offers a phased deployment model, enabling you to progressively migrate to zero-trust network architecture while lowering the risk of technology adoption. Safe-T’s Zero+ model is flexible to meet today’s diverse hybrid IT requirements. It satisfies the zero-trust principles used to combat today’s network security challenges.

 

Before you proceed, you may find the following posts helpful:

  1. Zero Trust SASE
  2. Zero Trust Networking
  3. SDP Network

 



Zero Trust SDP

Key Safe-T Zero Trust Strategy Discussion points:


  • Network challenges.

  • The issues with legacy VPN.

  • Introduction to Zero Trust Access.

  • Safe-T SDP solution.

  • Safe-T SDP and Zero Trust capabilities.

 

Network Challenges

  • Connect First and Then Authenticate

TCP has a weak security foundation. When clients want to communicate and have access to an application: they first set up a connection. Only after the connect stage has been carried out can the authentication stage be accomplished. Unfortunately, with this model, we have no idea who the client is until they have completed the connect phase. There is a possibility that the requesting client is not trustworthy.

 

  • The Network Perimeter

We began with static domains, whereby a fixed perimeter separates internal and external segments. Public IP addresses are assigned to the external host, and private addresses are to the internal. If a host is assigned a private IP, it is thought to be more trustworthy than if it has a public IP address. Therefore, trusted hosts operate internally, while untrusted operate externally to the perimeter. The significant factor that needs to be considered is that IP addresses lack user knowledge to assign and validate trust.

Today, IT has become more diverse since it supports hybrid architectures with various user types, humans, applications, and the proliferation of connected devices. Cloud adoption has become the norm since many remote workers access the corporate network from various devices and places.

The perimeter approach no longer accurately reflects the typical topology of users and servers. It was built for a different era where everything was inside the organization’s walls. However, today, organizations are increasingly deploying applications in public clouds located in geographical locations. These locations are remote from an organization’s trusted firewalls and the perimeter network. This certainly stretches the network perimeter.

We have a fluid network perimeter where data and users are located everywhere. Hence, now we operate in a completely new environment. But the security policy controlling user access is built for static corporate-owned devices within the supposed trusted LAN.

 

  • Lateral Movements

A significant concern with the perimeter approach is that it assumes a trusted internal network. However, 80% of threats are from internal malware or malicious employee that will often go undetected.

Besides, with the rise of phishing emails, an unintentional click will give a bad actor broad-level access. And once on the LAN, the bad actors can move laterally from one segment to another. They are likely to navigate undetected between or within the segments.

Eventually, the bad actor can steal the credentials and use them to capture and exfiltrate valuable assets. Even social media accounts can be targeted for data exfiltration since the firewall does not often inspect them as a file transfer mechanism.

 

  • Issues with the Virtual Private Network (VPN)

What happens with traditional VPN access is that the tunnel creates an extension between the client’s device and the application’s location. The VPN rules are static and do not dynamically change with the changing levels of trust on a given device. They provide only network information, which is a significant limitation.

Therefore, from a security standpoint, the traditional method of VPN access enables the clients to have broad network-level access. This makes the network susceptible to undetected lateral movements. Also, the remote users are authenticated and authorized but once permitted to the LAN. They have coarse-grained access. This creates a high level of risk as undetected malware on a user’s device can spread to an internal network.

Another significant challenge is that VPNs generate administrative complexity and cannot easily handle cloud or multiple network environments. They require the installation of end-user VPN software clients and knowing where the application they are accessing is located. Users would have to change their VPN client software to access the applications at different locations. In a nutshell, traditional VPNs are complex for administrators to manage and for users to operate.

With public concern over surveillance, privacy, and identity theft growing, many people are turning to VPNs to help keep them safer online. But where should you start when choosing the best VPN for your needs?

Also, poor user experience will likely occur as you need to backhaul the user traffic to a regional data center. This adds latency and bandwidth costs.

In recent years, torrenting has become increasingly popular among computer users who wish to download movies, books, and songs. Without having a VPN, you could risk your privacy and security. It is also important to note that you should be very careful when downloading files to your computer as they could cause more harm than good. 

 

Can Zero Trust Access be the Solution?

The main principle that Zero Trust Network Design follows is that nothing should be trusted. This is regardless of whether the connection originates inside or outside the network perimeter. Reasonably, today, we have no reason to trust any user, device, or application; some companies may try and decrease accessibility by using programs like office 365 distribution group to allow and disallow users’ and devices’ specific network permissions. You know that you cannot protect what you cannot see, but you also cannot attack what you cannot see also holds. ZTA makes the application and the infrastructure utterly undetectable to unauthorized clients, creating an invisible network.

Preferably, application access should be based on contextual parameters, such as who/where the user is located and the judgment of the security stance of the device. Then a continuous assessment of the session should be performed. This moves us from network-centric to user-centric, providing a connection-based approach to security. Security enforcement should be based on user context and include policies that matter to the business. It should be unlike a policy based on subnets that have no meaning. The authentication workflows should include context-aware data, such as device ID, geographic location, and the time and day when the user requests access.

It’s not good enough to provide network access. We must provide granular application access with a dynamic segment of 1. Here, an application microsegment gets created for every request that comes in. Micro-segmentation creates the ability to control access by subdividing the larger network into small secure application micro perimeter internal to the network. This abstraction layer puts a lockdown on lateral movements. In addition, zero trust access also implements a policy of least privilege by enforcing controls that enable the users to have access only to the resources they need to perform their tasks.

 

Characteristics of Safe-T

Safe-T has three main pillars to provide a secure application and file access solution:

1) An architecture that implements zero trust access,

2) A proprietary secure channel that enables users to access/share sensitive files remotely and

3) User behavior analytics.

Safe-T’s SDP architecture is designed to substantially implement the essential capabilities delineated by the Cloud Security Alliance (CSA) architecture. Safe-T’s Zero+ is built using these main components:

The Safe-T Access Controller is the centralized control and policy enforcement engine that enforces end-user authentication and access. It acts as the control layer, governing the flow between end-users and backend services.

Secondly, the Access Gateway is a front-end for all the backend services published to an untrusted network. The Authentication Gateway presents to the end-user in a clientless web browser. Hence, a pre-configured authentication workflow is provided by the Access Controller. The authentication workflow is a customizable set of authentication steps, such as 3rd party IDPs (Okta, Microsoft, DUO Security, etc.). In addition, it has built-in options, such as a captcha, username/password, No-Post, and OTP.

 

Safe-T Zero+ Capabilities

The Safe-T Zero+ capabilities are in line with zero trust principles. With Safe-T Zero+, clients requesting access must go through authentication and authorization stages before accessing the resource. Any network resource that has not passed these steps is blackened. Here, URL rewriting is used to hide the backend services.

This reduces the attack surface to an absolute minimum and follows Safe-T’s axiom: If you can’t be seen, you can’t be hacked. In a normal operating environment, for the users to access services behind a firewall, they have to open ports on the firewall. This presents security risks as a bad actor could directly access that service via the open port and exploit any vulnerabilities.

Another paramount capability of Safe-T Zero+ is implementing a patented technology called reverse access to eliminate the need to open incoming ports in the internal firewall. This also eliminates the need to store sensitive data in the demilitarized zone (DMZ). It can extend to on-premise, public, and hybrid cloud, supporting the most diverse hybrid and meeting the IT requirements. Zero+ can be deployed on-premises, as part of Safe-T’s SDP services, or on AWS, Azure, and other cloud infrastructures, thereby protecting both cloud and on-premise resources.

Zero+ provides the capability of user behavior analytics that monitors the actions of protected web applications. This allows the administrator to inspect the details of anomalous behavior. Forensic assessment is more accessible by offering a single source for logging.

Finally, Zero+ provides a unique, native HTTPS-based file access solution for the NTFS file system, replacing the vulnerable SMB protocol. Besides, users can create a standard mapped network drive in their Windows explorer. This provides a secure, encrypted, access-controlled channel to shared backend resources.

 

Zero Trust Access: Deployment Strategy

Safe-T customers can exclusively select an architecture that meets their on-premise or cloud-based requirements.

 

There are three options:

i) The customer deploys three VMs: 1) Access Controller, 2) Access Gateway, and 3) Authentication Gateway. The VMs can be deployed on-premises in an organization’s LAN, on Amazon Web Services (AWS) public cloud, or on Microsoft’s Azure public cloud.

ii) The customer deploys the 1) Access Controller VM and 2) Access Gateway VM on-premises in their LAN. The customer deploys the Authentication Gateway VM on a public cloud like AWS or Azure.

iii) The customer deploys the Access Controller VM on-premise in the LAN, and Safe-T deploys and maintains two VMs, 1) Access Gateway and 2) Authentication Gateway, both hosted on Safe-T’s global SDP cloud service.

 

ZTA Migration Path

Today, organizations recognize the need to move to zero-trust architecture. However, there is a difference between recognition and deployment. Also, new technology brings with it considerable risks. Chiefly, traditional Network Access Control (NAC) and VPN solutions fall short in many ways, but a rip-and-replace model is a very aggressive approach.

To transition from legacy to ZTA and single packet authorization, you should look for a migration path you feel comfortable with. Maybe you want to run a traditional VPN in parallel or in conjunction with your SDP solution and only for a group of users for a set period. A probable example could be: choosing a server used primarily by experienced users, such as DevOps or QA personnel. This ensures minimal risk if any problem occurs during your organization’s phased deployment of SDP access.

A recent survey by the CSA indicates that SDP awareness and adoption are still in an early stage. However, when you go down the path of ZTA, vendor selection that provides an architecture that matches your requirements is the key to successful adoption. For example, look for SDP vendors who allow you to continue using your existing VPN deployment while adding.

SDP/ZTA capabilities on top of your VPN. This could sidestep the risks if you switch to an entirely new technology.