The traditional enterprise approach to security relies on a network perimeter. Employees outside the company access the network via a VPN. Once authenticated and inside the network, the trust level tends to increase.

But the BeyondCorp approach, pioneered by Google, offers a bold new approach to enterprise web app security. All apps require authentication, with different levels of verification required for each user, app, device, and/or account. (For background details, see: BeyondCorp: Borderless security for today’s mobile workforce)

In February 2017, Duo Security announced the first commercial availability of Duo Beyond, a BeyondCorp-style security-as-a-service offering. Prior to the launch, around 100 customers from the technology, retail, e-commerce, and other sectors had participated in a private beta test of the service.

Ruoting Sun, the product marketing manager who is leading the Duo Beyond launch, spoke with TechRepublic contributor Andy Wolber about the service and approach.

TechRepublic: How would you describe Duo Beyond and the BeyondCorp approach?

Ruoting Sun: Google was obviously a pioneer in saying that it is not effective to build access security policies with this inherent level of trust that our corporate network–or anything within our firewalls–is any safer than the public internet.

The challenge, obviously, is that Google is a multi-billion dollar corporation with hundreds of people in security. So, how do you take what they’ve done and make it a reality for organizations as small as 50-100 users, as well as to other organizations with thousands or hundreds of thousands of users?

We developed Duo Beyond to make it commercially feasible for organizations of any size to be able to get to a Beyond-Corp style security model.

TechRepublic: How does the login experience work for an employee?

Ruoting Sun: Part of the BeyondCorp model is around making sure that there is good multi-factor authentication, and that there is a consistent user experience with a single sign-on portal.

We will check all the usual things: Multi-factor authentication to verify the user identity, as well as all sorts of device hygiene checks–whether the device is up-to-date, whether it has malicious applications installed on it, or whether it is lacking security configurations, as well as the ability to detect whether or not that device has a certificate on it. And we’ll enforce those policies, which can be created by an administrator at the application level, specific to a role or particular group.

All of the things that we’re talking about here are pretty much transparent to the end user. If all of these checks work out, they log into their application like any normal single sign-on process. Only in the event that one of these checks does not work out, or their device triggers a certain policy violation, do we then show warnings to the end user or take an action to block them.

TechRepublic: How does this differ from the traditional VPN access model?

Ruoting Sun: We see this as a better model for access security. It removes the friction of having to do traditional network segmentation, which gets really ugly with different policies for different VLANs, firewall routing, etc. All of that is taken care of with this approach. We’re getting rid of this concept of the network perimeter. You access the application through Duo and you’re able to create these policies at an application level, rather than at the network level.

What is new in the Duo Beyond edition is really two capabilities: The ability to detect if a device is managed or not through the availability of a Duo certificate on that device, and the ability to treat internal applications the same way that you would treat a cloud application.

TechRepublic: And what changes with Duo Beyond for an administrator?

Ruoting Sun: We saw a lot of organizations putting together a hodge-podge of four or five different combinations of technologies in place to address this use case. People were deploying complicated NAC solutions to protect their corporate network, CASB products to cover their cloud apps, and client certificates to mark the endpoints; and so it was really an ugly deployment. You’re talking about having to manage four or five different interfaces, deploy four or five different things, pay for four or five different products, and it just wasn’t scalable.

First, we wanted to solve the problem of putting certificates on devices. Most customers had to deploy their own key infrastructure in order to roll-out certs to endpoints. We make this easier by hosting a public key infrastructure for our customers, so they can just use the Duo certificate infrastructure. Then, they can deploy the Duo certificates via whatever enterprise asset management tool they have.

Then, on the enforcement side, all of those policies are configurable within the admin panel for Duo. So you don’t need to buy a network access control solution, or a separate solution for your cloud applications. All of those policies are configured right from your Duo interface, regardless of whether that application lives on premises, or on someone else’s cloud.

TechRepublic: From a technical perspective, exactly what does an administrator need to do to make Duo Beyond work for an internal web app?

Ruoting Sun: Basically, a customer would publish an internal web application to be accessible externally. There are some DNS changes, obviously, that need to be made in order for that application to be available from the internet. For example, you would go to your internal wiki, like Confluence, and make it to be accessible outside of your corporate network and VPN. And then you would put the Duo Network Gateway in front of that, so that any access requests hitting those applications are automatically redirected and forced to authenticate via the Duo Network Gateway.

TechRepublic: Does Duo Beyond also authenticate access to traditionally installed apps, such as a database app installed on an on-premise server?

Ruoting Sun: At this time, we’re able to support any web based application. Right now, the certificates are browser-based certificates and are tied in at the user level. As long as our authentication prompt can load, we can detect the presence of the cert, no matter if it is a cloud app or an internally hosted application. We are looking into supporting non-web based applications as well.

TechRepublic: Are there any other risks or benefits customers see?

Ruoting Sun: Our customers are able to significantly reduce their attack surface. In the past, if you had an organization of 5,000 people and you were paying VPN licenses for everybody, you had basically a remote access attack surface of 5,000 endpoints that are out there. All the attacker would have to do would be to steal the credentials of any one of them and be able to remotely access your VPN and network. Your attack surface is effectively every single VPN client running out there.

In this model, it’s completely different, because you’re getting rid of this concept of having a bunch of free floating VPN clients in the wild, and you’re limiting the access to each individual application, and enforcing policies for each individual application. You’re removing 75-80% of your attack surface and VPN license count.

A lot of customers have told us that the logging and reporting that we provide is beneficial both from an internal audit perspective and also from a compliance perspective. We have customers that are using our authentication logs and endpoint data to fulfill ISO 27002 requirements around organizational asset management or to fulfill PCI DSS requirements.

How do you handle trusted access to internal and external web apps at your organization? Let us know in the comments or on Twitter.