Imagine no VPN, it isn’t hard if you try! (Part 1)

A transformation is brewing within IT, requiring the strong need to remove all privileges granted to devices for having “corporate network addresses” and demand end-to-end encryption between apps & services.

However, both of these lead to the question: Do we still need firewalls & VPNs?

There are many factors behind this transformation, including:

1. An exploding mobile workforce, with a very large # of devices connecting to corporate services from anywhere (on par with devices accessing services from “inside” the firewall).

1. Services no longer solely managed/run from behind corporate firewalls. Instead, many services are hosted & operated by 3^rd party SaaS-providers.

1. Increasing attacks on laptops/desktops & mobile devices. A result of the inherent weaknesses of perimeter-driven networks in dealing with such attacks, partially due to the complexities in this new mobile world. Setting up VPNs is a headache, especially dealing with an ever-growing matrix of laptop/smart-phone/tablet/phablet/OS makes/models and networks.

A research published by the NJIT showed that close to 45% of employees work virtually/from home. According to Gartner, 40% of the 50m+ free-lancers in the US use their personal devices for work, while at the comfort of their homes, to access corporate services.

(Source: NJIT’s Age of the Telecommuter infographic)

In short, IT departments have to deal with users accessing corporate services from devices a) that IT doesn’t own, b) runs on networks IT has no control over, and c) accessing services not hosted or managed by IT.

Other than that, everything else is the same as 1995!

So, IT needs to transform its thinking regarding providing “access” to users.

As an example, Google published BeyondCorp. Essentially, Google discusses their internal IT efforts to re-architect how corporate services are delivered to their 50k+ workers, specifically by removing any privileged access that would have been granted solely based on device network address.

To get there, the proposal leans on stopping the bleed at the edge, i.e.: on devices used to access corporate services.

A big driver for this approach stems from the bulls-eye that hackers have placed on our devices. They seek the weakest link for gaining access to corporate data: they target devices. Case in point, the very recent IOS 9 application hacks. Why? Because these devices tend to be less secure than servers, and devices are where users enter their credentials, where the bulk of user interactions occur.

As an IT decision maker, if you can “trust” devices, and users using the devices, you can provide roles-based access that depends on device status, instead of the vulnerable device IP address.

Key advantages of device-centric approach over traditional perimeter controlled access are:

Improved Usability: For perimeter-based access, remote/mobile users need to install/configure VPN clients & remote-access apps on their devices. They have to know when to connect using VPN & when not to. In the device-trust centric model, users don’t have to install separate apps or make location-based decisions for access. Access works the same way, everywhere.

Stronger trust across a wider geography: Perimeter-based access relies on IP addresses to determine “device location”; the new model uses device status & unique identification information. The result: A far reaching access-plane, no longer defined by “internal” vs. “external” networks, instead, trusted devices can access services from anywhere.

Not surprisingly, at the heart of it, this new approach relies on Device Identity, Device & User Authentication, & Device-Inventory-aware authorization.

For this transformation to succeed, IT teams need to establish a clean device inventory. Such devices need to uniquely identify themselves, eliminating chances of impersonation & spoofing. Unlocking the “secure device-service communication” relies on user input/user credentials, highlighting the need for strong on-device user authentication.

What about the server side?  In this new model, if the back-end services only trust encrypted communication from devices, and there aren’t VPNs/firewalls in between, what is controlling access to the services?

In this trusted-user/device model, the gatekeeper role is played by the Identity & Access Management (IAM) infrastructure. The same infrastructure that helps determine “who has access to what services” becomes the main filter for devices. A key element within IAM for this approach is the Reverse Proxy.

Reverse Proxies (RPs) provide advantages for controlling access to applications over VPNs. RPs are much easier to setup, and don’t require users to configure anything on devices. From a users perspective: All they do is access the services from trusted devices; the RPs secures the connection (encryption), and enforces the authorization & authentication policies. The end result is lowered headaches for IT when dealing with remote/mobile users for setup, configuration and support of their devices and applications.

Additionally: RPs hide the location/identity of the actual target servers being accessed, by routing encrypted traffic to the target service. Client applications only know about the RP. Everything else is managed by IAM.

IT gains centralized control over access policies: With this new design, IT can decide whether or not to grant access, based in part on: installed device software & configuration, using the same IAM solution. In this design, IT gains a centralized view of who has access to what, from which device, using what authentication policy; a capability that is explicitly part of the application level authorization decision-making process within IAM.

It’s not entirely a rosy picture yet, and, yes, there are challenges. I’ll go over some of the changes in Part 2 of this blog series.

The post Imagine no VPN, it isn’t hard if you try! (Part 1) appeared first on Speaking of Security - The RSA Blog and Podcast.