Software Defined Perimeter architecture mandatory to ensure truly secure environments
TechTarget recently published a four-part E-Handbook: Can a zero trust approach fill the security perimeter void? The four article series outlines Forrester’s vision for Zero Trust describing it as “recreating the “ring” of security that vanished when the enterprise perimeter went poof a few years back. The difference is that now everyone is outside that ring unless explicitly permitted in.”
The articles lay out how Zero Trust requires creating detailed policies and devising certain “hoops” through which those wanting access to critical infrastructure must jump. It describes the need for policies that do not let anyone into your network, or access your assets, before they can prove who they are….before they can establish trust.”
The articles acknowledge that the Zero Trust approach involves using VPNs and firewalls allowing users to connect to services (e.g. a mail server). Firewalls can be set up to ban IPs and services can be set up to figure out which IP addresses are good or bad. VPNs can be set up to only let the users on the network who have the authorized VPN client and the appropriate keys.
One of the articles says of Zero Trust, “A more accurate — if clunkier — name would be highly granular and distributed trust. That is, the concept behind zero trust is actually highly granular control of distributed trust. A session of type X between devices Y and Z may be permitted, but not all sessions of type X or all sessions of any type between devices Y and Z should be trusted.”
“Those twin concepts – highly granular and distributed trust — form the twin lynchpins of zero-trust security. Zero trust relies on — and demands — a deep knowledge of systems and data so IT can put meaningful boundaries around systems, processes, applications and users everywhere.”
Lastly, the articles outline Zero Trust implementation via virtualization and micro-segmentation – a container-based software development paradigm. They talk about implementing Zero Trust at the computing and application layer starting with trying to provide granular, distributed security to these virtual machines (VMs), micro services and containers.
Waverley Labs believes that theoretically, Zero Trust makes sense and is admirable but there is one fundamental flaw – it is based on today’s current networking architectures.
In the Zero Trust strategy as outline by Forrester and in these articles, firewall and VPN and other vulnerabilities still exist that bad actors can and will exploit. Unauthorized users who clone the VPN client and steal the keys can also access the mail server and then guess other user names and passwords and perform malicious acts such as DDoS, credential theft, and more. A VPN may allow you to log into the network and not allow you use other services (e.g. SharePoint) that are not on the mail server network segment. But, because unauthorized users are already in the network, they can get to a SharePoint server by using hacking techniques. By allowing users to access a network and then access to services, and then letting the service to determine whether the user can access the service, is an issue. Access before authentication allows users (good and bad) to have access to all the services – not just login, but access.
The Zero Trust concept is right but the implementation is cobbled together at best and is akin to trying to put a square peg into a round hole.
What is missing is the “deny all, authenticate first” security architecture that is the signature of the Software Defined Perimeter (SDP). SDPs dynamically create one-to-one connections between every authorized device, user and the data they access. Anyone attempting to access a resource must “authenticate first.” This applies the principle of least privilege to the network and completely reduces the attack surface. By default, users are not allowed to connect to anything – the opposite of traditional corporate networks, where once a user is given an IP address, they typically have access to everything on the network. Instead, SDPs ensure that once proper access criteria are met, a dynamic one-to-one connection is generated from the user’s machine to the specific resource needed. Everything else is completely invisible.
The last article talks about Zero Trust implementation via micro segmentation. Yes, a micro segmented environment is a good start but it is still not secure just because it is containerized. However, micro segmentation utilizing an SDP architecture enables orchestration and dynamic control of policies regardless of the network (static or SDN) to ensure that applications using the micro segmented environment are truly secure
An analogy of a Zero Trust environment (without an underlying SDP architecture) is a house with doors and windows that all have locks on them. The people in that house are relying on those locks that are visible to bad actors who will attempt to pick them. When the same house is built upon a deny all, authenticate-first SDP architecture, the house is not behind a fence or a wall, it is not even visible to anyone except those that have been authenticated. This is the true essence of Zero Trust.
There has been much talk about the Zero Trust strategy. According to the Cloud Security Alliance, the industry needs to better understand Zero Trust’s relationship with SDP for Zero Trust to become a truly secure solution.
To learn more, check out this Zero Trust use case.
Also,register for the webinar to learn more about Utilizing a Zero Trust Model to Defend IoT Driven DDoS Cyber Attacks on September 27 where the CSA will present SDP as the most advanced solution implementation of the Zero Trust strategy.
###
