Google GCP: zero trust, kill chains, resilience, risk forecasting.

This week, we are taking a look at the Google Cloud Platform (GCP) through a first principle lens. We have already done the same for Microsoft Azure and Amazon AWS. The links to those essays and podcasts are listed below. Google didn't roll out GCP until 2012, a good six years after Amazon released AWS and two years after Microsoft released Azure. And it shows. Where Azure and AWS are similar in how their customers use those Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) cloud offerings, it’s clear that Google studied the other two competitors and made some design changes. The most obvious have come in the form of how Google views their virtual private clouds (VPCs) and how they have placed zero trust as a cornerstone to the entire experience.

GCP networking 101.

Google has abstracted some of the tactical networking components that are the meat and potatoes of Azure and AWS into a hierarchical construct. When you buy GCP services, your organization can create multiple folders, let’s say for the finance team, the IT team, and the security team. Each owner of the folder can create subfolders for various and distinct tasks, like an employee salary folder and an employee vacation folder, under the finance team folder. 

Each folder owner can also create one or more projects, and this is key. The GCP project is the fundamental organizing service entity and contains all of the access permissions and settings as well as resources like compute, storage, and networking. A project can’t access another project’s resources unless the owner manually shares them or establishes some sort of VPC peering. With VPC peering though, GCP customers can design their environments so that individual project owners don’t have to worry about networking and security stacks. The IT teams and the security teams can share their projects with the Finance team, and the finance team can get busy doing finance things.

For resiliency considerations, the IT team can create subnets in various regions similar to the capability in Azure and AWS. With Google though, the routing is implicit and handled under the covers by the GCP infrastructure. 

With a nod toward zero trust, GCP also has the notion of host projects versus service projects. Service projects can’t create infrastructure. They share the infrastructure from the host project. In our example, the IT team and the security team work on host projects, subnetting and firewalls, let’s say, and share that infrastructure with the employee salary service project. Much to their joy, the owners of the employee salary service project don’t have to worry about all the stuff that generally slows them down anyway. They can just focus on making a better employee salary service.

You can build this kind of model inside AWS and Azure, but that’s the thing. You have to build it. Within GCP, it’s the way the infrastructure works.

GCP offers three layers of security controls and services: within the VPC, between VPCs, and internet-facing VPCs. Within VPC projects, you have microsegmentation capability in the form of identity management, third-party tools, key management, and hardened virtual images. Between VPC projects, designers have ways to connect things securely with VPC firewalls and service controls, VPN connections back to data centers, network address translation for internet-facing workloads, and packet mirroring for network management and incident response.

For internet-facing VPCs and employee access to VPCs, this is where Google is fundamentally different from Azure and AWS, and they call it BeyondCorp.

Before BeyondCorp – the Google zero trust journey.

BeyondCorp is Google's implementation of the zero trust model. But before they could get there, three things had to happen: a transition to devops, a famous zero trust white paper, and a massive chinese cyber espionage attack.

In S1E10 of CSO Perspectives, I did a deep dive on how the Google leadership team transitioned to a DevOps philosophy. As far back as 2004, instead of the traditional IT teams performing the standard network management tasks, the Google leadership team gave that set of jobs to the development team roughly five years before the IT community even came up with the DevOps label to classify the work. That was step one. Google couldn’t have implemented their version of zero trust unless they had a way to deploy infrastructure at scale. In 2004, they weren't thinking about zero trust yet, because it hadn’t been invented yet, but Google site reliability engineers had started to master the day-to-day practice of devops operations. 

I also did a mini-history lesson of how we got the zero trust philosophy back in S1E7. Although the idea had been kicking around various places during the 2000s, it wasn’t until John Kindervag published his famous paper on the concept in 2010 that it started to get legs. You can even make an argument that zero trust as a legitimate cybersecurity best practice didn't really gain traction from the majority of network defenders until the last five years or so. But the paper was step two from a Google perspective. I'm not saying that Kindervag’s paper influenced the Google decision. I'm saying that it generally influenced the community about the goodness of zero trust, and I expect that general sentiment rubbed off on Google engineers in some way.

But the real catalyst was step three. Multiple Chinese cyber espionage groups broke into the Google networks, as well as many other silicon valley companies, in 2009, in a campaign called Operation Aurora. At one point, there were at least three different Chinese government organizations conducting espionage operations within the Google networks: the Chinese equivalents of the FBI, the Department of Defense, and the CIA. None of them knew the other two were in there until Google went public with the intelligence in 2010. And you thought the American government didn't like to share information.

But that’s what did it. Google leadership decided they needed a redesign for their own network security. Shortly after, they rolled out BeyondCorp, and the ideas and infrastructure Google engineers created eventually found their way into GCP.

GCP and Zero Trust.

The aha moment for the Google engineers came when they realized that we really shouldn’t authenticate and authorize users and API calls on the actual workloads we are trying to protect. Instead, we should be doing those operations before any user or machine actually gets into the network at all. In that way, we have a chance to keep bad guys out of our networks before they can get in the front door and snoop around. Brilliant! Why didn't I think of that?

This is similar to what Jerry Archer, the Sallie Mae CSO, talked about in our last episode about AWS security. He said he deployed a third-party tool in his AWS instance that provides a software-defined perimeter (SDP) that did a similar thing. The basic concept of SDP came out of the U.S. government, the Defense Information Systems Agency (DISA) to be precise, and was eventually codified by the Cloud Security Alliance as a general best practice for cloud deployments. 

GCP does this with something called the Identity Aware Proxy (IAP) paired with the Google Cloud Identity Access Management (IAM) system. Google’s take on SDP adds a little GCP sweetener by also monitoring the endpoints used by customers and employees trying to connect to various workloads. They are looking for things like current operating system versions, patch levels, and whether or not they have ever seen the device before. 

Once the system authenticates the user or API call and checks if they have permission to access the workload, GCP then facilitates the connection to the desired resource and nothing else. Just because the requestor has permission to access a workload that doesn’t give them permission to access all workloads. When you hear Google say that the perimeter is dead, this is what they’re talking about. With the BeyondCorp model, you no longer require VPNs to tunnel into a perimeter. You authenticate at an access point, the IAP/IAM combo; the system checks if you have permission to access the resources you want to connect to; and then the system provides a direct connection to the resource.

This is how you do zero trust. SDP is not just a good idea. It’s probably the idea on how to deploy zero trust in the cloud. GCP’s version is light years ahead of the other two cloud providers we’ve looked at in this series.

GCP resilience, intrusion kill chain prevention, and risk assessment.

I have lumped all of these first principle strategies into one section because GCP has the same general capabilities as Azure and AWS. They are really good at providing the ability to design and deploy resilient systems in the cloud but are not nearly as good at helping network defenders deploy intrusion kill chain prevention and risk assessment. Comparing the three cloud providers on these strategies, it’s a wash. All of them do resilience well but have not spent much time on risk assessment and the intrusion kill chain.

Final thoughts on GCP.

Next week, I’ll be talking to a couple of GCP experts on everything we have covered here. We will see what I got wrong. In the meantime, in terms of first principle thinking, all three cloud providers we have talked about in this series are about the same in terms of offered capability. If all things were created equal, Google would probably get the nod for its rethinking of SDP and how they could provide this zero trust service to their customers. Having said that, I realize that I haven’t considered operational issues (how easy is each to deploy?) or financial issues (how much money does it cost to run your operation?), and probably an entire list of other issues that might contribute to the decision of which cloud provider to use. That was not my purpose here. Before I make any decision to adopt one cloud provider or another, I would want to understand if they could meet my security needs. Here is the score card:

• Resilience – good across the board.
• Zero Trust – good for Azure and AWS, excellent for GCP.
• Intrusion Kill Chain Prevention – poor across the board, requires third-party tools.
• Risk Assessment – poor across the board but lots of telemetry to build your own risk models.

That said, your own on-prem deployments are probably no better than any of the three cloud options. 

Reading list.

S1E6: 11 MAY: Cybersecurity First Principles

S1E7: 18 MAY: Cybersecurity first principles: zero trust

S1E8: 26 MAY: Cybersecurity first principles: intrusion kill chains.

S1E9: 01 JUN: Cybersecurity first principles - resilience

S1E11: 15 JUN: Cybersecurity first principles - risk

S4E3: 25 JAN: Microsoft Azure via first principles

S4E4: 01 FEB: Microsoft Azure via first principles Hashtable Interviews

S4E5: 08 FEB: AWS via First Principles

S4E6: 15 FEB: AWS security via first principles Hashtable Interviews with

“About: History,” Cloud Security Alliance.

“BeyondCorp 6: Building a Healthy Fleet.” by Janosko, Michael, Hunter King, Betsy Adrienne, and Max Saltonstall, Google Research, 2018. 

“BeyondCorp | Run Zero Trust Security like Google.” BeyondCorp, 2021. 

‌“BeyondProd: A New Approach to Cloud-Native Security | Documentation.” Google Cloud, 2021.

“BeyondProd: The Origin of Cloud-Native Security at Google.” by Baker, Brandon, Usenix.org, 2020.

“Cloud OnAir: Google Cloud Networking 101.” by Google Cloud Platform, YouTube Video, 9 July 2018. 

“Day 13 - How to Set up BeyondCorp Zero Trust Security Model Google Cloud #13DaysOfGCP.” by Priyanka Vergadia, YouTube Video, 3 May 2020. 

‌“GCP Networking 101.” by netJoints, YouTube Video. 19 June 19 2020. 

“Getting Started with BeyondCorp: A Deeper Look into IAP.” Google Cloud Platform, YouTube Video, 15 September 15, 2020. 

“New Chinese Intelligence Unit Linked to Massive Cyber Spying Program.” by Bill Gertz, Washington Free Beacon, 31 October 2014. 

"No More Chewy Centers: Introducing The Zero Trust Model Of Information Security,” by John Kindervag, Forrester, 14 September 2010, Last Visited 30 April 2020, 

“Preventing Data Exfiltration on GCP (Cloud next ’19).” Google Cloud, YouTube Video, 12 April 2019. 

“Site Reliability Engineering.” by Betsy Beyer (Editor), Chris Jones (Editor), Jennifer Petoff (Editor), Niall Richard Murphy (Editor), Goodreads.com, 2016. 

“The Cybersecurity Canon: Site Reliability Engineering: How Google Runs Production Systems,” Book Review by Rick Howard, Palo Alto Networks, 26 September 2017.

What’s New in Network Security on Google Cloud.” Google Cloud Platform, YouTube Video, 15 September 2020.