Going Beyond Network Perimeter Security by Adopting Device Trust

This post is an excerpt of the recently published tech paper, Best Practices for Secure Infrastructure Access. For the full paper, download Best Practices for Secure Infrastructure Access.

It’s a familiar nightmare you’ve heard of and might even face as a developer or security engineer: alerts firing in all directions warning that your company’s VPN and firewall — that supposedly “safe” defensive perimeter around your infrastructure — has been breached. And the scariest part is that you find out after the fact — after access credentials and customer assets have been stolen.

Preventing this scenario from happening requires understanding the weaknesses of the network perimeter security model and replacing it with an alternative that’s more responsive to today’s heightened cyber threat environment.

The inherent weaknesses of perimeter security

So why do VPN’s, which are widely used and adopted, and both simple and effective — pose a security risk? In the perimeter security model, engineers log in to an office VPN to access target cloud infrastructure that is also part of the VPN network. Infrastructure’s firewalls would only accept connections from VPN IPs address ranges, and connection travels over the internet through VPN tunnel. While this model significantly reduces attack surface and limits who can attempt to breach the perimeter, it has several major drawbacks.

First, if hackers breach your VPN, they may find themselves in a welcoming environment of interconnected networks with full access to Postgres DBs with no authentication and unpatched Jenkins servers holding keys to your kingdom.

Here’s how it usually plays out in the wild — as it did in this instance where Uber’s VPN account was compromised, and the attacker was able to social-engineer his way into an employee's VPN account before pivoting deeper into the network:

While no official explanation has been provided yet, [apparently] the intruder was able to connect to the corporate VPN to gain access to the wider Uber network, and then seems to have stumbled on gold in the form of admin credentials stored in plain text on a network share," Ian McShane, vice president of strategy at Arctic Wolf [a cybersecurity company], said in a statement.

Second, it’s very challenging to keep VPNs and firewall rules up to date across global hybrid infrastructure, with multiple clouds, availability zones and offices.

In fact, almost a decade ago, Google came to the conclusion that VPNs are not enough. Instead of setting up a perimeter, they built an identity-aware access proxy authenticating every device and user to each target all the time regardless of their location and network. They called this initiative BeyondCorp.

In the BeyondCorp model, the proxy verifies that only trusted users and devices can connect to it, otherwise anyone in the internet can try their hacking skills on your public endpoints. Users then establish an end-to-end encrypted TLS tunnel to the target resource — a single database or a service. There is no blanket access to infrastructure any more.

Note that in the first case scenario, the attack surface is the firewall, Alice’s computer and the corporate network. Unless we verify the client devices, the attack surface on the right is any computer in the entire internet, which is a bit harder to protect from.

Before even accepting a connection, an identity-aware proxy will verify that the client device has proven its identity using cryptographically strong enrollment and verification protocol.

We also need to make sure that the client’s device is what it claims to be and it’s not an impersonator trying to breach the system.

We should avoid certs lying on disk in the open, passwords, and everything else that lets hackers steal the device’s identity from a hacked computer.

But how can a device prove its identity in a safe and secure way? Let’s explore this in the next section.

What do we replace IPs with?

Establishing and verifying a device identity is hard. IP addresses, a typical component of VPN systems, aren't unique or trustworthy.

Hardware fingerprinting is another option: plenty of systems would look at MAC addresses, or a combination of various hardware identifiers. Fingerprinting comes with its own characteristics, such as detecting hardware changes, which may be desirable.

Ultimately, whether IPs, fingerprinting, or something else, it all boils down to the same issue: whatever the device tells you can be faked. A maliciously modified application can be indistinguishable from a real one, leaving servers unable to verify the information received. Something better must be used, something that can't be faked or stolen: enter the Secure Enclave.

A Secure Enclave is a dedicated hardware subsystem used to hold sensitive information, such as private keys. Data cannot be exfiltrated from the Enclave, and can only be accessed by signed applications. A signed application can access only its own keys, having no information about the keys of other apps; the same is true for distinct OS users in the same device.

An enclave-guarded private key can't be faked, exfiltrated or accessed by maliciously modified apps, making it the superior choice to IPs or fingerprinting.

The solution

Armed with Secure Enclave private keys, we now have the means to verify device identity. Let's see how Teleport leverages that to put together a device trust system, starting with the next component: the device inventory.

The device inventory is the list of devices allowed to access sensitive resources. It contains information about known devices, along with their current standing and useful metadata. A device present in the inventory is registered in the system, known but not yet trusted.

Lastly, a trusted device must prove its identity to the servers when requesting access to sensitive resources. This is done via device challenges, which can only be answered by using the private key the device holds in its Secure Enclave.

Secure tunnel that uses identity

Here is an example of how device-aware authentication works in Teleport:

Device authentication

First, Alice authenticates herself, acquiring a TLS certificate with information about her identity. A typical authentication flow could have Alice enter her password and tap a YubiKey, or perhaps use passwordless authentication with her Touch ID sensor.

Using her personal TLS certificate, Alice establishes a new connection and undergoes a device challenge. Because Alice is using a genuine, signed app, her client is able to complete the challenge using the Secure Enclave private key. This nets her a new device-aware certificate, which is only possible because Alice is using a trusted device.

Note how everything is identity-based: first Alice establishes her identity through a login process, then her device establishes its identity by proving it can access the secret private key. There is no perimeter defense, no IPs and no VPNs: only identities and secure TLS connections.

Enrollment process

We talked about how a device in the device inventory is initially registered, but not trusted, and how a trusted device establishes its identity through device challenges, but did not explain how a device goes from registered to trusted.

The process that takes a device from registered to trusted is called enrollment. Enrollment is when the device sends its public key to the proxy, which then stores it for future device challenges. It is a sensitive process, because if done naively, enrollment can bless the wrong device as trusted.

To avoid erroneous or malicious enrollment, we have to implement safeguards: our system should identify the user, check if the user can do enrollments and if they hold a valid enrollment token.

The first safeguard establishes the user's identity, so unknown users can't attempt to enroll devices. The second safeguard raises the bar and requires users to have permission to enroll devices.

Our final safeguard is the device enrollment token, tying the observed device to an inventory device; both must match, otherwise enrollment fails. During enrollment, Teleport collects unique device data, such as the Mac serial number, which the proxy matches against the corresponding inventory entry.

Here is an example of enrollment using Teleport:

Device enrollment

The enrollment token lets Alice enroll her device. Note how, in the diagram above, the IT admin creates the token and sends it to Alice out-of-band, adding extra security layers to the process. Alice can make her device trusted by Teleport because she has the enrollment token and can authenticate against the proxy.

The enrollment process explained above is not perfect, but it is difficult to crack. As with many security tools, a careful human process created around it can greatly increase the effectiveness of the system. After enrollment is complete, due to the guarantees of Secure Enclave, Teleport can make strong assurances about the ongoing identity of the device.

Wrapping up

We can replace network perimeters and IP restrictions, if we give each device a unique identity that can not be easily forged. We can use Secure Enclaves and TPM devices.

We also have to verify that users and applications can verify themselves as well.

Users can authenticate themselves using single sign-on, and applications can use verified signatures.

Once we stitch all pieces together, we can finally get a reliable device trust mechanism to reduce possible attacks on our infrastructure.

If you got this far, you may as well try out Device Trust in action. Give it a go and let us know what you think.