Mitigating Risk via the Software-Defined Perimeter
Since the 1990s the focus on network security has hinged on one very important thing. Protect internal services from external threats. This was first accomplished by building a protected perimeter around the network and using a DMZ. This traditional method, made up of hardware appliances, was used as a virtual drawbridge to the corporate castle, protecting internal network (LAN) from the untrusted internet.
The way users work has changed since 30 years ago. They now use the cloud to connect to any application, from any device and from anywhere. This change has highlighted the weaknesses of traditional network security, proving that DMZ is now obsolete. The DMZ was not built to protect against unmanaged user devices who have access to services inside the network, nor to provide secure remote access in a world where the perimeter has been extended beyond the datacenter, to the internet.
It’s time for enterprises to re-evaluate whether their traditional DMZ is sufficient enough to help reduce risk. And if not, move on to something better.
What is SDP and how does it provide network security?
First off, the term Software Defined Perimeter (SDP) is fairly new, so don’t be alarmed if this is the first time you’re hearing about it. Analysts, like Gartner, are beginning to cover it in more depth, and view this new method as the future of remote access.
So, what is SDP and why do you care?
SDP was first developed based on work that had been done by the Defense Information Systems Agency, that had a very simple goal. Provide access to mission-critical applications but only on a zero-trust, need to know basis. SDPs acts as a broker between users and internal applications, and only provide access to services if the correct criteria is met. This approach allows an enterprise to determine which users have access to which applications. By segmenting applications via SDP, enterprises can more easily protect sensitive information.
One key benefit of a SDP is its ability to isolate applications from the open internet. This is important because the majority of external attacks stem from the internet, as attackers are constantly look for vulnerabilities in internet-facing services. This isolation is made possible via software that front-ends an application. This software connector can only create an outbound connection out to the cloud where policy is stored, and does not listen for any inbound requests. Thus, DNS servers and IP addresses are further protected from internet-based attacks. This is unlike traditional approaches which often include a VPN concentrator, which does listen for inbound requests coming from remote users, and can easily fall victim to a DDoS attack.
Acting as a broker, IT can use SDPs to create specific policies for a specific user, user group, application or application group. Any user who is not authorized to access a specific application will not be able to view the service, let alone access it. They layer of abstraction makes applications completely invisible to the unauthorized user. Again, building off of the military concepts core to the SDP method, making mission-critical assets “dark.”
One of the biggest pitfalls of the traditional DMZ method is that remote users, and third-party users are placed on the internal network (LAN). SDPs can provide connectivity to apps, without ever placing a user on the network. This is important as it decreases the chance of an attack stemming from an unmanaged device. Any malware lurking on un-managed devices will not have access to the network, nor will it have the ability to spread laterally. This mitigates the risk of external attack, even as the number of unmanaged devices increases and enterprises adopt popular public and private cloud services.
At Zscaler we developed a cloud service called Zscaler Private Access (ZPA), which uses its software defined architecture to provide secure access to internal applications. We built the service based on four key SDP security tenets.