Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10/9/2019
10:00 AM
Gilad Steinberg
Gilad Steinberg
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

How the Software-Defined Perimeter Is Redefining Access Control

In a world where traditional network boundaries no longer exist, VPNs are showing their age.

Virtual private networks (VPNs) have been around for over two decades, providing secure, encrypted tunnels for communications and data. While there are multiple types of VPNs — including SSL-VPNs and IPSec, to name two — the basic idea is the same regardless of the implementation. With a VPN, a secure IP transport tunnel is created that is intended to provide assurance that the data is safe because access is encrypted.

The concept of the software-defined perimeter (SDP) is somewhat newer, originally coming onto the scene in 2013, under the initial direction of the Cloud Security Alliance (CSA). With the SDP model, rather than just trusting an encrypted tunnel to be safe because it uses Transport Layer Security (TLS), there is no assumption of trust — hence the use of the term "zero trust" by many vendors in connection with SDP.

In a typical SDP architecture, there are multiple points where any and every connection is validated and inspected to help prove authenticity and limit risk. Typically, in the SDP model there is a controller that defines the policies by which clients can connect and get access to different resources. The gateway component helps to direct traffic to the right data center or cloud resources. Finally, devices and services make use of an SDP client which connects and requests access from the controller to resources. Some SDP implementations are agentless.

SDP vs. VPN
The basic premise under which VPNs were originally built and deployed is that there is an enterprise perimeter, protected ostensibly with perimeter security devices such as IDS/IPS and firewalls. A VPN enables a remote user or business partner to tunnel through the perimeter to get access to what's inside of an enterprise, providing local access privileges, even when remote.

The reality of the modern IT enterprise is that the perimeter no longer exists, with staff, contractors and partners working on campus locations, remotely and in the cloud and all over the world. That's the world that SDP was born into and is aimed to solve.

VPNs today are still widely used and remain useful for certain types of remote access and mobile worker needs, but they involve a certain amount of implicit or granted trust. The enterprise network trusts that someone that has the right VPN credentials should have those credentials and is allowed access. Now if that VPN user happens to turn out to be a malicious user or the credentials were stolen by an unauthorized person that now has access to a local network — that's kind of a problem, and a problem that VPNs by design don't really solve all that well, if at all.

An SDP or zero-trust model can be used within the modern perimeter-less enterprise to help secure remote, mobile, and cloud users as well as workloads. SDP isn't just about having a secure tunnel — it's about validation and authorization. Instead of just trusting that a tunnel is secure, there are checks to validate posture, robust policies that grant access, segmentation policies to restrict access and multiple control points.

The increasing adoption of zero-trust security technologies by organizations of all sizes is an evolving trend. As organizations look to reduce risk and minimize their potential attack surface, having more points of control is often a key goal. Security professionals also typically recommend that organizations minimize the number of privileged users and grant access based on the principle of least privilege. Rather than just simply giving a VPN user full local access, system admins should restrict access based on policy and device authorization, which is a core attribute of the zero-trust model.

A well-architected zero-trust solution can also offer the potential benefit of less overhead, without the need for physical appliance or client-side agents.

Use Cases
For business users, VPNs are a familiar concept for remote access and that is not something that is likely to change in the near term. For access to a local file share within a company, or even something as simple as accessing a corporate printer, a VPN will remain a reasonable option for the next two to three years. However, as more businesses move to SDP, even the simple access of a printer will be covered.

Within companies, internal threats in the perimeter-less enterprise are as likely as external ones, a zero-trust model is a useful model to limit insider risks.

For developers and those involved in DevOps, zero trust is a more elegant and controlled approach to granting access as well as providing access to on-premises, cloud, and remote resources. Development is distributed and simply tunneling into a network is not as powerful as what zero trust can enable.

VPNs are no longer the be-all and end-all solution for securing access that they were once promised to be.

The reality of the modern Internet is that threats come from anywhere, with the potential for any device or compromised user credential to be used as a pivot point to breach a network. A zero-trust approach can go beyond just relying on encryption and credential to minimize risk and improve security. SDP moves beyond just pretending that the fiction of a hard perimeter still exists.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Can the Girl Scouts Save the Moon from Cyberattack?"

Gilad Steinberg is CTO and Co-Founder of Odo Security, a provider of remote access technology. He was previously the Security R&D Team Leader for the Israel Prime Minister's Office. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19698
PUBLISHED: 2019-12-10
marc-q libwav through 2017-04-20 has a NULL pointer dereference in wav_content_read() at libwav.c.
CVE-2019-4428
PUBLISHED: 2019-12-09
IBM Watson Assistant for IBM Cloud Pak for Data 1.0.0 through 1.3.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session....
CVE-2019-4611
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 168519.
CVE-2019-4612
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to malicious file upload in the My Account Portal. Attackers can make use of this weakness and upload malicious executable files into the system and it can be sent to victim for performing further attacks. IBM X-Force ID: 168523.
CVE-2019-4621
PUBLISHED: 2019-12-09
IBM DataPower Gateway 7.6.0.0-7 throug 6.0.14 and 2018.4.1.0 through 2018.4.1.5 have a default administrator account that is enabled if the IPMI LAN channel is enabled. A remote attacker could use this account to gain unauthorised access to the BMC. IBM X-Force ID: 168883.