BeyondCorp and Zero Trust

Zero trust has been one of the most over used buzz words (or buzz terms, I suppose?) in cyber security for several years, however I think it’s important to understand what it actually is, and what it means, because it’s really important once you see through all of the marketing smoke and mirrors that are out there.

Where did Zero Trust come from?

For many years, Cyber Security primarily focused on perimeter defense. You would force all of your secure assets, applications, data, etc. on to one fairly monolithic network, and then have a firewall in place to act like a gatekeeper to that network. Only secure company resources should be allowed on this network, and when you’re on the network you can access the sensitive or secure data that you need.

This methodology lasted a long time, and over time slowly matured to include things like network segmentation, where you could have sections of less secure devices but still keep the “crown jewels” locked down more tightly. People also started introducing several “layers” of security, so hopefully if someone were able to get past one layer of defense, there would be something else in place (i.e. extra authentication) to prevent you from being able to get all the way in to whatever you were trying to access.

As threats evolved, however, this became somewhat outdated. Several things were changing. Attacks were becoming far more sophisticated, and our legitimate needs to use networks were rapidly expanding and evolving, and with more access requirements, we were opening more and more attack surfaces. Attackers could also just compromise a legitimate user, and then use that User’s access to move laterally through the network to get whatever they were looking for.

In 2011, Lockheed Martin published a paper about a new kind of framework, with a similar methodology based on military strategy, and called it the Cyber Kill Chain.

The Cyber Kill Chain introduced ideas such as an advanced persistent threat, where someone could establish a foothold at one point, then just wait to execute a payload until later. It also defined several different types of threats. This methodology modernized the approach to cyber security in many ways, and informs how we look at many modern threats to this day. One of the key ideas is to try to assume that you are already compromised, and then design defenses to limit the material damage that can be done given that fact.

The idea of the kill chain is that for a successful attack to take place, they often need to chain together several exploit methods to gain access or attack your infrastructure, and rather than a perimeter defense acting only as a gatekeeper, you would have multiple methods of defense looking for all types of exploits, lateral movement within a secure network, or evidence of advanced persistent threats, and you try to head off the chain of attack, rather than strictly preventing entry to your network.

Cyber Kill Chain is primarily a new methodology to approach Cyber Security, but in 2014 Google published their now famous BeyondCorp papers, which laid out a new kind of architecture methodology. A way to design your network and applications in a far more resilient way. BeyondCorp really started the concept of Zero Trust.

What is Zero Trust really?

Zero Trust is difficult to define for a few reasons. First, I see it more as a philosophy of how to design architecture, rather than a specific thing that you can directly “implement”. There’s no such thing as a perfect Zero Trust deployment, but it’s a goal that continues to evolve as technology becomes available to help implement it, and as we evolve our systems to be made in ways that support Zero Trust.

So again, what is Zero Trust really? Well the broad idea is first, the traditional perimeter based network is essentially completely gone. Access should be limited to only what you need, and verification that you are who you say you are, and that you are safe to access something is a continual process including several parts.

• User trust - Determining that a user is who they say they are. This is where identity verification comes in. Realistically you need an identity provider to provide this part well. A good identity provider is looking at all sorts of data to determine that you are who you say you are. Username, password, multi-factor authentication, possibly biometric authentication, and several other factors go in to determining the likelihood of you being who you claim to be. Ideally, this is not just a one time verification, but something that is continuously checked during any session to help prevent session hijacking.
• Device trust - Next, it is important to learn about the device that you are using to connect from. Typically organizations will want to check the device to see if it is a corporate owned device, so verifying that it is in inventory would be one part of device posture. There are several other things that you can check, such as an up to date endpoint security tool (sometimes you may just want to check that they have any endpoint security, other times you may want to only allow access with your corporate controlled endpoint security, allowing you to enforce other policies as well), or you may even want to check that a certificate is installed on that device. There are many things that can be checked on the device posture to ensure that the device is safe and authorized to access whatever resource is being accessed.
• Application Policy - Each Application itself (Application can be a little loose here, this could be an actual application or any other type of network resource really) can have a granular policy with a different fine-grained set of requirements in order to access the resource. Depending on what the application policy is set to, it can react differently based on the User and Device trust. For instance, an Application could even present more challenges to a User if the confidence isn’t high enough that a User is who they say they are. Or maybe in some cases, if they meet a more relaxed set of policies, maybe they can have read only access, but a more strict set of policies are required in order to actually write to the data. This can be extremely flexible based on the org and the Applications that they use.

A key part of the application policy that is not something companies have been very good at is that application access should only be granted to people who actually need it. Do not give any access that is not needed.

Sounds great! I’ll have one of those!

Zero Trust as an idea is great, but like I said earlier, it is more of a philosophy. It all sounds great, but actually implementing it is extremely difficult, and arguably, you probably can never actually “achieve” it. Even Google, who has spent an enormous amount of time, effort, and boatloads of cash implementing this is definitely not 100% there. In fact, from the BeyondCorp papers themselves -

Despite all the best efforts to define, roll out, measure, and enforce controls, you may inevitably face the harsh reality that 100% uniform control deployment is a mythical state where unicorns frolic unconcerned about malware and state-sponsored attackers.

If Google, who custom builds their entire platform from the hardware that runs in their data centers (even the fiber running between them) to the cloud software and applications, to even the browser where almost all of their internal work takes place, can’t 100% implement BeyondCorp or Zero Trust implementations, what chance do we have?

Well, it doesn’t take long on the internet to find a bunch of people on both sides of this argument. People love to write how it’s impossible to achieve and that everyone saying otherwise is lying. They aren’t completely wrong, because on the other side, there are thousands of companies out there claiming that if you “buy their product, they can just plug and play Zero Trust”, which is absolutely not true. I don’t think it’s hard to see that 100% compliance with this idea is possible, but I’m also pretty optimistic about Zero Trust the concept, and think it’s extremely worthy of pursuing.

Conclusion

There are many pieces to Zero Trust, and each piece will require specific tools, and sometimes multiple tools. Some of these are far more mature than others. Identity management has come a long way in the last few years. Azure AD, Okta, Google Identity, and others are all tackling this problem, and more and more SaaS applications are fully supporting these authentication methods (although many charge more for it, which I think is a problem. You can help shame these companies by looking at https://sso.tax).

Device posture is making a lot of progress more recently, but still has a long way to go. This is a very segmented part of the market and most tools do not talk to each other. Additionally, many legacy Applications are still in use out there, and for many of these, solutions to help plug those in to a Zero Trust environment are still being made, or are in the very early stages of even working.

Another thing to be mindful of is that this is not entirely exclusive to “users” to “applications”, but also should apply when applications need to talk to each other, or if an application needs to talk to a database, etc.

Still, I think the technology is further along than many people might think, and you can do some really great things in this space. In fact, I would argue that if you take the time to design these correctly, you not only have a more secure environment, but a more flexible one (more important now than ever with our changing work environments), and I think even a better user experience. I see a world where a correctly configured device just has access to everything it needs, keeps itself automatically up do date with device posture policies, and people are able to more easily access network resources without the need for clunky and unreliable VPN’s.