How to Start Applying Google’s ‘Zero Trust’ Model

There are an increasing number of conversation about Google’s adoption of a “Zero Trust” network architecture for security, and while it isn’t new, it’s just now gaining mindshare even as more organizations are concluding that perimeter defense alone can’t protect their digital assets.

As a philosophy, Zero Trust simply asks that the internal network be trusted on the same level as the internet–in other words, not at all. Adopting this philosophy pushes the locus of security responsibility away from the perimeter and toward the application. This shifts the focus toward applications and their data and how they’re being accessed, not on building bigger castle walls to protect the internal network.

Google has covered a lot of ground implementing the first corporate-wide Zero Trust network, and shared its learning under the umbrella of BeyondCorp for others to adopt. Reference architecture shows core functions that must be delivered by any Zero Trust implementation include an identity provider, access proxy and the access policy provider, as well as a comprehensive asset database.

The perfect starting point is a team meeting where all stakeholders agree on a definition of what their Zero Trust looks like, then define goals in terms of policy. Then, lay out a roadmap to get to these goals. That does not mean throwing away the currently deployed technologies that protect the perimeter. Rather, it begs an organizational change in approach, and how we think about protecting core assets.

Technology decisions come last, which makes sense. You can’t go out and “buy” a Zero Trust anything. It’s a combination of cross-cutting concerns to make it work — and that’s why it won’t be easy. A real commitment and understanding by the senior leadership will be key. It is also important to note that Google’s path to Zero Trust was a four-year journey that began in 2013. So this is not a project that happens overnight.

The key is to understand the context of who wants access, what device the request originated from, and then mapping that to access policies per application. This amounts to a whitelist-only method for granting access.

To fully implement an application built in line with Zero Trust, each and every access to an application must be authenticated, authorized and encrypted. Each service must ensure these checks have occurred for every call. This goes beyond a simple API key that acts as both authentication and authorization; it requires a real understanding of the context of the service requester combined with access policy.

This is a tall order which has prompted enough startups to promise a fully realized Zero Trust network solution–but that’s not possible. It’s important to remember that Zero Trust isn’t just an architectural guide; it’s a thought process and approach that pushes businesses to rethink how they create their organizations’ cybersecurity posture. In reality, the hard part of making Zero Trust successful is the boring, less glamorous work of creating and maintaining data policies, and authorizing access to the applications that read and write that data. Keeping that swathe of policy and access control updated and proving compliance will be essential for the long-term usefulness of a Zero Trust approach.

There is no silver bullet, and challenges will be unique to each security team. For many organizations, defining data access policy takes considerable time and is a complex challenge. For others, it’s Identifying all applications that access critical data, or implementing and managing a unified authorization and access control system. The heavy lift will fall on internal teams, since they intimately understand the business’ drivers and core assets.

In short, will SecOps go away with a Zero Trust network? No, since it doesn’t solve the huge lack of skilled security analysts. But it does is redefine what is monitored, triaged and responded to — and for now, that’s a step ahead.