Safe-T SDP- Why Rip and Replace your VPN?
Although organizations realize the need to upgrade their approach to user access control. The deployment of existing technologies is holding back the introduction of Software Defined Perimeter (SDP). A recent report carried out by the Cloud Security Alliance (CSA) on the “State of Software Defined Perimeter” states that the main barrier to adopting SDP is the existing in-place security technologies.
One can understand the reluctance to take the leap. After all, VPNs have been a cornerstone of secure networking for over two decades, see these VPN Statistics for more VPN information. They do provide what they say; secure remote access. However, they have not evolved to appropriately secure our developing environment. In fact, the digital environment has changed considerably in recent times. There is a big push to the cloud, BYOD and remote workers, thereby putting pressure on existing VPN architectures. As our environment evolves, the existing security tools and architectures must evolve also.
Undoubtedly, there is a common understanding of the benefits of adopting the zero-trust principles that SDP provides over traditional VPNs. But the truth that organizations want even safer, less disruptive and less costly deployment models cannot be ignored. It is not enough to offer solutions that would involve ripping the existing architectures completely or even putting SDP on certain use cases. The barrier to adopting SDP involves finding a middle-ground.
Safe-T; Providing the middle ground
Safe-T is aware of this need for a middle ground. Therefore, in addition to the standard SDP offering, Safe-T also offers this middle-ground, to help the customer on the “journey from VPN to SDP”, resulting in a safe path to SDP.
Now organizations do not need to rip and replace the VPN. SDP and VPNs can work together, thereby yielding a more robust security infrastructure. Besides, if you already have a VPN solution that you are comfortable with, you can continue using it and pair it with Safe-T’s innovative SDP approach. By adopting this new technology you get equipped with a middle-ground that not only improves your security posture but also maintains the advantages of existing VPN.
Recently, Safe-T has released a new version of its SDP solution called ZoneZero that enhances VPN security by adding SDP capabilities. Adding SDP capabilities allows the 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 on top of 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 solution in the market with a primary focus on enhancing VPN security by adding zero trust capabilities, rather than replacing it.
The challenges of just using traditional VPN
While VPNs have stood the test of time, today, we know that the true security architecture is based upon the concept of zero trust access. VPNs operating by themselves are unable to offer optimum security. Now, let’s examine some of the common shortfalls.
The VPN lacks in the sense that they are not equipped to grant access on a granular, case-by-case level. This is a major problem that SDP addresses. According to the traditional security setup, in order to get access to an application, you had to connect a user to a network. Whereas, the users that were 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. Some organizations might have implemented RAS alongside document management software similar to FilecenterDMS to streamline their file organization to keep their external workforce productive and secure. To provide application access, an inbound port is exposed to the public internet. However, this open port is visible to anyone on the internet and not just to the remote workers.
From a security standpoint, the idea of network connectivity to access an application is likely to bring many challenges. We then moved to the initial layer of zero trust, which was to isolate different layers of security within the network. This provided a way to quarantine the applications that are 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 stack of hardware. This enabled the users to only access what they were allowed to, based on the blacklist security approach. Security policies provided a broad-level and overly permissive access. The attack surface was simply too wide. Also, the VPN just displays static configurations that have no meaning. For example, a configuration may state that this particular source can reach this destination by using this port number and policy.
However, with this configuration, contextual configuration is not taken into consideration. There are just ports and IP addresses and the configuration offers no visibility into the network to see who, what, when and how they are connecting with the device.
More than often, access policy models are coarse-grained, which provide 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.
Say, 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 actually be able to express and enforce the policy configuration based on the identity, which takes into consideration both the user and the device.
The SDP acceptance
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, by itself, 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 really want.
All the money and time you have spent on the existing technologies are not evolving in pace with today’s digital environment. This indicates the necessity for new capabilities to be added. These get translated into different meanings based on the CIO and CTO roles of an organization. The CTOs are passionate to embrace the new technologies and invest in the future. They are always on the lookout to take advantage of new and exciting opportunities in technology.
However, the CIO looks at things in a different manner. 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 is to encourage the customers to rip and replace their VPN in order to deploy their SDP solution. 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.
How Safe-T address this?
Safe-T understands that there is a need to go down the SDP 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 to it.
The solution is placed after your VPN. The existing VPN communicates with Safe-T ZoneZero that 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 normal. 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 as opposed to 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 over to the application-based access. Even though they are using a traditional VPN to connect, they are still getting the full benefits of SDP.
This is a perfect stepping stone on the path towards 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 and it controls which traffic continues to flow into the organization.
In the dual-node deployment model, the ZoneZero virtual machine is located 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 kind of network and security architecture. But at this time, a middle-ground can reduce the risks associated with the deployment. The only viable option is to run the existing VPN architectures in parallel with SDP. This way, you get all the benefits of SDP with minimal disruption.