Product & Engineering

February 8, 2017 Wendy Nather

BeyondCorp For The Rest Of Us

Rumor has it that the enterprise security perimeter is going to make a guest cameo on The Walking Dead. People have certainly been promoting the perimeter’s demise for years now: the Jericho Forum was created to tackle “de-perimeterisation” as early as 2003.

The idea really picked up steam as the cloud became more accepted as a common place to store and process data. Now that Google has come out and described in detail how they’ve made it happen, and dubbed it “BeyondCorp,” it’s within practical reach for many more organizations, with a concrete example to consider implementing.

The idea of getting rid of the perimeter is generally too scary for enterprises to contemplate, especially if they’ve only recently solidified one. So let’s not think of it as getting rid of the perimeter, but rather as tightening security on the inside so that the perimeter isn’t the only thing keeping the attacker at bay.

Here at Duo, we believe in the democratization of security. It’s all very well to talk about restructuring your IT when you have armies of technical talent and revenue that let you buy or build one of everything; but what about the rest of us? This is why Duo has come out with the first major commercial implementation of BeyondCorp, called Duo Beyond (read more about it here).

What’s BeyondCorp About?

Google’s vision is similar to John Kindervag’s “zero-trust model” of information security: to assume that no traffic within an enterprise’s network is any more trustworthy by default than traffic coming in from the outside. Of course, enterprises can’t operate without any kind of trust; the trick is to set the conditions under which they will decide to trust something.

Google’s implementation rests on the combination of validated users using validated endpoint devices, locked down with least-privilege segregation and end-to-end encryption. As long as the user is authenticated with the right number of factors, and is using an endpoint that has been enrolled and inspected for security vulnerabilities, they can access exactly those resources that they’re allowed to by a centralized proxy.

As Google illustrates above (click to view larger), they rely on a device inventory database, a user/group database, and client-side certificates for strong identification and control. Obviously, this didn’t happen overnight. In order to migrate a huge and complex infrastructure to this model, they had to map and simulate workflows, using transition measures such as split DNS to make sure nothing broke while it was being gradually moved out of the “soft and chewy center.”

What Risks Does This Address?

The biggest one, of course, is that an attacker breaks through the perimeter and then has free rein within the trusted internal network. Google specifically referred to the “Aurora” attacks as an example of what prompted BeyondCorp. The counterpart to this risk is that you don’t have to start by breaking through the perimeter: if you’re an insider planning malfeasance, you’re already there. The traditional way to deal with this risk is to segment the network, but creating segmentation after the fact can be a major project, disrupting traffic and application tiers, and in many organizations, it never gets done. And let’s face it: a sufficiently successful outsider looks exactly like an insider.

Another risk is that the attacker exploits the gaps between different policies or enforcement that apply to the same asset. For example, if the same confidential data is available in two different systems using different types of authentication, the attacker will go after the one that’s easier to reach -- either because it trusts something else, or because that one authentication method has a flaw in it. You can prevent arbitrage by trusting nothing by default and making everyone pass the same tests each time.

A common risk that every organization faces is the vulnerable endpoint. At the very least, endpoints should be up to date on the operating system and plugins that they need to use. This isn’t always practical due to legacy software, but users who simply don’t get around to upgrading -- especially on their personal devices -- are a security headache for the enterprise.

With a centralized access proxy, you can have one set of policies for each application, regardless of where the system or user is located. A third-party SaaS could have the same trust requirements for access as an internal web application. This is important because attackers try to come from the “most trusted” location, whether that’s a known IP address, an “internal” system, or a favored geographic area. With the BeyondCorp model, it’s the combination of user and endpoint that earns the trust, not the network.

Note: you can have different requirements based on whether it’s an internal or external app, but once you start making that distinction, you’re back on the road to destroying that security model you just tried to implement. Make sure your policies are based on business criticality and confidentiality, not on “inside” versus “outside.”

What Should Organizations Think About?

If you’re already in the hybrid environment -- with some of your infrastructure on-premises and some in the cloud -- it’s time to think about how you could potentially use the BeyondCorp model to re-balance your security policies, because you already have assets that aren’t within your perimeter. For those with a large network who haven’t been able to segment it as much as they’d like, or for tighter control, the BeyondCorp model may offer a chance to focus on combining user and endpoint verification with encryption.

The good news is that you don’t have to do this all at once. While Google’s description of a comprehensive migration sounds daunting, moving to this different concept of security also works when you do it incrementally. Remember, you’re not actually getting rid of the perimeter controls; you’re raising the level of security on the inside so that it looks more like the outside. Any progress is a significant improvement.

Here are some of the high-level steps to plan for:

1. Enroll your users and their endpoints. This may require a discovery process, since users might not always be using the corporate assets you assigned them. By routing those users to a popular application through an authentication gateway such as the ones that Duo provides, you can get an inventory on the fly.

2. Deploy certificates to the user endpoints that you want to mark as “managed” or “trusted.” The level of trust is up to you, but for some organizations, it means that they’re officially supported and maintained by the enterprise; for others who embrace BYOD, it means that they’ve done the initial hygiene check during enrollment and validated that the user really is using that device. In the case of Duo Beyond, the certificates and PKI (public key infrastructure) are created as part of the service, but they can also work with an existing PKI.

3. Create access policies based on the requirements for each application or system you want to protect. These policies can include how often you want users to re-authenticate; whether they can use personal devices; and which level of hygiene you want to enforce. These policies can be adjusted dynamically based on security events. For example, if a new vulnerability is being actively exploited in a particular endpoint OS or plugin, you can block affected users until they update it. This drives users to update on their own rather than waiting for IT to organize a scheduled maintenance window (no more Terror Tuesday!).

4. Profit! Well, maybe not profit, but benefit from better visibility and a tighter set of controls over what your users and endpoints are accessing, regardless of where they are. By adapting to the new reality -- that applications, users and devices can change locations at the drop of a hat -- you’ll be able to maintain a more consistent level of security and user experience.

Since BeyondCorp is a concept, not a specific product, you’ll see a growing number of variations on the theme as companies large and small implement it. Look for more blog entries on this topic as Duo supports this movement Beyond the traditional security limits.

Read the next blog in this series, BeyondCorp: Enrolling Users and Endpoints.