BeyondCorp: If You Liked It, You Should Have Put a Cert On It
In our first blog post introducing the BeyondCorp concept, we discussed what organizations should think about when trying it for themselves. The steps may not happen in sequential order, but they are generally:
- Enrolling your users and their endpoints
- Deploying certificates to identify trusted devices
- Setting up the access proxy and its policies
In this post, we’ll talk about marking trusted devices with certificates.
What Does “Trusted” Mean?
Only you can decide that. It used to be that if a user provided the correct login name and password, it proved that the right person was at the keyboard — and we all know how well that worked out. We ran into the same problem with devices: because it was on the corporate network, we assumed it was supposed to be there, and it got access to anything it asked for. Both of these “tests” failed for a number of reasons:
- Stolen passwords
- Spoofed network addresses
- Compromised endpoints
- The ability to spread out laterally to other vulnerable systems
Now, the path to trust needs more checkpoints, such as authentication factors and conditions placed on the device. One of these conditions can be whether it’s a managed, corporate-owned endpoint.
A managed endpoint is presumably owned by the enterprise, or at least known: it may be tracked as part of an inventory, enrolled in a configuration and patch management program, and monitored for security events. For this reason, you may choose to trust it more than you would trust an unmanaged, personal device.
Many organizations have the policy that only the endpoints they own and assign to staff can be used to access business data. However, this policy can be difficult to enforce, especially if there’s no way to check. There are a few different ways to try:
- Virtual private network (VPN) software - if the endpoint has the VPN client installed, it’s assumed to be an approved and managed asset, so whoever is using it will be allowed to access the internal network from the outside (say, at home, or from a hotel or coffee shop). SSL VPN software doesn’t require an installed client, so it provides more convenience for the user, but it also removes that implicit enforcement.
- Network access control (NAC) software - with common port-based NAC, if the endpoint has an 802.1x certificate installed, it’s assumed to be an approved and managed asset, so whoever is using it will be allowed to connect to the internal network from inside the building.
- Mobile device management (MDM) software - enrolling mobile devices into this system allows you to enforce configuration policies by installing an agent.
In each of these cases, you’ve marked the endpoint as trusted by installing something on it (or given it a second factor, “something it has”). However, many of these systems are complex and take months to set up. Digital certificates are lightweight and relatively easy to deploy, but they require a public key infrastructure (PKI) to be set up and maintained, which can end up being too onerous for some organizations. (Duo makes this part easier by creating the device certificates for you).
What else could this marking mean for a “trusted endpoint?” It could be used for endpoints that don’t belong to the organization, but that have been vetted (for example, a consultant’s laptop that has been scanned). The important point is that you’ve seen the device before and expect to grant it access, as opposed to endpoints that are trying to access your applications that you’ve never seen before that may be used by attackers. Either way, it can be used to control which devices can access your business data.
All the Single Endpoints
In Google’s BeyondCorp framework, certificates offer a way to identify the device as managed. In Duo Beyond, we take it a step further by including device and user data in the certificate, tying them together so that neither one’s credentials can be leveraged alone. You can set policies so that users must use known and approved endpoints to access the most critical data and applications (for example, privileged users must use a corporate-owned device). Likewise, even if a user loses credentials to an attacker, the attacker still needs to use a valid endpoint belonging to that user to get into an application.
What do you do now that you’ve marked your endpoints? Why, you manage the access of their users. We’ll discuss access policies in the next blog installment.