Scaling Security with Google Cloud Platform

Learn about the security benefits of moving to the cloud with Google Cloud Platform.

Speaker

Tiffany Lewis, Google Cloud Security and Compliance Specialist, Google

[Tiffany Lewis]

Hey folks, thank you so much for having me. My name is Tiffany Lewis, I am a security and compliance specialist at Google Cloud. 

Prior to working at Google, I worked at a consultancy where my job was to advise customers on the pros and cons of moving to cloud versus staying on prem, as well as reviewing cloud native companies and giving ways to improve their overall security and compliance posture. 

That said, today’s discussion is going to be around scaling security with Google Cloud platform, otherwise known as GCP. The objectives of today’s discussion is really to enable and empower those joining the session when it comes to things within GCP. So understanding the security fundamentals, how they apply to your security infrastructure, and specifically, the idea of shared responsibility model and how that applies to all customers. 

That said, now, usually when I have these conversations, I like to start with what I called the legal or the disclaimer slide. There’s a lot of, I feel like misnomers when it comes to cloud, and Google Cloud platform specifically. As a result, we have very clear contractual commitments that we make to our customers for GCP that’s within the DPST, otherwise known as the data processing and security terms. 

These are publicly available terms that apply for all of our customers using GCP. GCP is our enterprise public cloud offering that we have available for consumers to use. This enterprise offering is distinctly different from some of our consumer offerings, let’s say on the ad sides, map or some of our free Gmail. With our enterprise services, we have very explicit contractual agreements, and these are some of the things that we have explicitly for those, first of which is, we tell you that you own your data, not Google, Google will never sell customer data to any type of third party, will never scrape it to use for customer advertising or resell to an advertising agency. 

Within the DPST, we use the terms of a data processor and data controller. Ultimately, you are the data controller for all of your data. You decide what information goes up to the cloud, you decide the security controls and parameters that are instituted around that data. Google Cloud will only do what you tell us to do around processing that data, for instance, if you want to spend at the end, the command to spin that up, we will spin that up on your behalf. We do have some technical commitments that we make to customers within the DPST, such as all of your data will be encrypted at both rest and in-transit, we’ll talk a little bit more about the technical implementation details a few slides later. 

We also guard against insider access to your data. So, insider access could be a Googler trying to maliciously access customer’s data, or inadvertently accessing that data. We discuss those more within the DPST as well as our Google Cloud security white papers, but we have both technical controls against those as well as a data incident notification policy, that is, a contractual commitment within the DPST. The technical controls that we have to provide protection against insider access have been validated by third party auditors. 

Also, we never get any type of government entity backdoor access to your environment. If a government entity is trying to gain access to data that’s being hosted on Google Cloud platform, we will, in the majority of cases, contact our customers to let them know that this is something that is being requested, versus just handing over the data. We also have a public facing white paper that, I think it goes into a decent amount of detail describing the process that happens when a government entity ask or request access to customer data, it’s our government access white paper, you can also do a Google search of Google Cloud transparency reports, which will then show you the amount of government requests we get, further information about the divisions, things along those lines, if that’s your interest, right? 

And the final thing that I will mention here is that our security practices, our data centers are essentially audited against international standards. when I say international standards, I’m referring to ISO 27001, 17, 18, SOC 123, PCI DSS, AOC. These are commitments that we make explicit within our DPST to maintain at least an annual audit for those various certifications to ensure that our data centers are operating in line with best practice, and that you don’t just trust us when we say it, but we also have this verified, right? We also have this validated by third party industry respected members. That said, all of the fun legal kind of disclaimer I think are done, so we get to jump into what I really love, the technical stuff. 

So the thing, if I’m being really honest and frank, that drew me to Google was the security narrative, right? So in my prior job, I worked with a variety of different public clouds, I worked variety of different on-prem service providers, all these different things, and the encryption narrative is really what drew my attention to GCP. So, a lot of times what I see in industry is people saying that they do encryption at rest or encryption at transit by default. And when they talk about encryption at rest, they’re talking about something similar to BitLocker, where you simply have encryption at the hard drive level of a singular key, which helps you if you’re concerned if a hard drive walking out of your data center. But outside of that, it doesn’t provide really additional layers of protection or encryption. 

What GCP does by default when we talk about encryption at rest is it implements encryption at rest to all of our GCP services because we implement this via our distributed file system. So the way that this happens is displayed in this diagram, and we’ll do a walkthrough example. But essentially, any time that data is uploaded to the cloud, whether it’s a picture, a video, what have you, right? And you’re storing it in something like, let’s say GCS or Google Cloud Storage, the data is uploaded to GCP, once it is uploaded, that file is then divided into chunks. So the amount of chunks that it’s subdivided in depends on the overall format and file size. So it could be tens of chunks, hundreds of chunks, thousands of chunks. it just depends, right? So it’s chunked up, each little chunk is then wrapped with a data encryption key, otherwise known as a DEK. 

Now it’s important to note here is that, even though it’s starting with the same sort of origin file, each of these DEKs is unique from one another. So what this means is that each one is not the same, right? So that said, the DEKs are then wrapped in KEK or key encryption key, so we leveraged envelope encryption here, and those encrypted chunks are then wrapped and distributed across Google Cloud global storage infrastructure. So all of this is happening behind the scenes, it doesn’t introduce any additional latency into the process itself. If you’re wondering, this is also what we have kind of running behind the scenes for other things like, let’s say, Google Sheets, anytime that there’s a keystroke and you can kind of see it say, save at the top. This process is happening on the backend because encryption was built as something core and central to Google itself, versus kind of like an ad hoc thing that was added to kind of meet a check mark, right? Or a check box. That’s why you have truly no significant impacts on the overall performance when you talk about this default encryption narrative. 

We also provide encryption at transit by default. There’s lots of ways to customize these things, but essentially, we use TLS protocol or quick protocol to do the encryption as far as which version it uses, it’ll essentially do a negotiation between Google Cloud and the client’s browser to support the highest supported one on the client side. So let’s walk through this example. So let’s say that I am uploading a montage of Basset Hounds, Basset Hound videos. Love Basset Hounds, by the way. So if you hear other references, there they’re. 

But, we have our Basset Hound montage that has been uploaded to the cloud. Once it’s uploaded to the cloud, the Basset Hound montage is broken up size of the video, let’s say into hundreds of chunks that are then, each chunk is essentially wrapped in its own DEK, the DEK is then wraps in KEK from the service being provided on GCP, and that’s then distributed across Google’s global infrastructure. Now, one of the common questions that we get aside from latency is does Google also encrypt the backups. The answer is yes. 

So the other thing I wanna say before we move on to the next slide is this is what we do kind of table stakes, right? This is done, you know, for essentially all of our services on GCP. With that said, we do use our crypto module for our encryption at rest narrative is FIPs 140-2 verified, so it’s good for a lot of different workloads. But for those folks who have really high regulatory internal security requirements or compliance requirements, we do have customizable if we can use that term here, or choose your own adventure, key management options that’ll support things like HSM. If you need to have more controls over the keys themselves, such as the creation, deletion, and rotation, I need to be able to control Apples on those specific keys, we also support that as well via our cloud KMS, okay? 

Networking. So, this is another fun one. So Google Cloud, one of the unique things is that Google has one of the largest backbone networks in the world. We have over 130 points of presence spanning 35 plus countries, and we’re continuing to add zones and regions, which are just like logical areas of segmentation with data centers and all the other services needed to run GCP, right? To meet customers essentially preference and policy requirements. Now folks then asks, that’s great, love me some networking, but, why are you talking about networking during a session about security? That’s because I think our networking narrative really compliments and strengthens the overall security narrative when it comes to understanding the benefits of utilizing GCP. So sure, network delivers low latency because it’s so big, it spans the globe, but it improves our security posture because once a customer’s traffic is in our network, it’s no longer transiting the public internet, making it less likely to be attacked, intercepted, or manipulated. 

The other benefit of using GCP is we’ve essentially been cloud native if you will, for 15 plus years, which means that we’ve had a lot of learnings. Part of the reason why we’ve invested so much in a lot of these proprietary networks, hardware, software that Google Cloud has, it’s simply because things like nation state attacks are things that we’ve had to think about and past, right? The idea of future-proofing not for just tomorrow, but years ahead is something that we’ve been thinking about for awhile, and I think we felt a lot of these things into our overall ecosystem. 

Okay. Talk a little bit about a vendor in the middle. So, Google was thinking about vendor in the middle, I think before it really became a central point within industry to talk about this. So when I talk about a vendor in the middle and Google thinking about it, they were working towards this over a decade ago. So when you use cloud and I’m sure everyone here is familiar, but just to kind of reiterate, when you use cloud if we were to simplify it down and boil it down, at the end of the day, you’re essentially renting and using servers, networking peripheral devices from a cloud service provider, The narrative gets more complex depending on the service that you use, but that is core, that’s what it is. Google, if you were to look by the amount of servers that we have in the manufacturing assemble, would be the third largest server manufacturer in the world, Which is mind-boggling. 

So it’s extraordinarily important to make sure that the servers, the network and the peripheral devices that we have within our data centers haven’t been altered maliciously in any way, or have any type of third party hardware or software that could potentially introduce like a net new risk factor that we don’t tapped, see, right? So traditionally, when we look at vendor in the middle, the thing that we’re concerned about is firmware, some type of hardware software that is ultimately trying to alter the firmware that we have on our existing devices. Titan is pretty neat because they exist to check the firmware for any type of irregularities that may exist. It provides a hardware-based root of trust to establish a strong identity as a machine, and it also has tamper-proof immutable logs tied to it as well so we can do additional troubleshooting and view that. 

If you were to simplify Titan, really think about it as a TKM that we have on all of our servers within our data centers, all of our peripherals, all of our networking devices, it’s something that we have implanted in them by default so that we were able to detect if a vendor in the middle attack were ever to happen. And to also mitigate the risk. Other things mentioned in the slide that we have within our data centers, we’ve got the purpose-built chips, purpose-built servers, purpose-built storage, we have the network that we talked about as well as purpose-built data centers. 

Okay. Live migration. So the idea of being to upgrade at scale with no disruptions is really one of the benefits of cloud, especially when we’re talking about IaaS. So one of the differentiators about GCP is essentially our ability to update our infrastructure without disrupting the customer experience using a technology called live migration. So, for instance, let’s say that you have updates that are adding functionality, and that you need to have some type of software, you need to have some type of software patch, live migration for our Google compute engine or GCE VMs allows us to do that on the backend without impacting negatively the overall customer experience. So a good example of case where I think live migration is real nifty, is if we look back at the Specter and Meltdown vulnerabilities a few years ago. 

So they were discovered by researchers from the Project Zero team, which is essentially like Google’s James Bond team, real exciting, real smart, real bright folks. Google essentially worked with the Project Zero team and other industry leaders to address these vulnerabilities, A lot of bright minds put together to fix them. And what customers then saw is whether in their cloud environment, or, a lot of times in their cloud environment was that they would see this red blaring sign that said that they had to restart their fleet of VMs in order to apply the patch to fix that, Which led to increased downtime it meant that the fleet had to go down and a clear disruption to their overall infrastructure. For GCP customers, they barely had to pay attention, because we were able to apply these updates in the backend via live migration. The reason that we were able to do this is because Google Cloud, is if you look at the infrastructure underlying GCP built on containers. So essentially, it gives us the ability to migrate our running VM from one host to another in essentially moving the complete instance states from the source to the destination in a way that’s completely transparent to the guest OS and anyone communicating with it, leading to that seamless experience. You wanna know more about it, just Google live migration, and GCP and you’ll find some pretty cool stuff. 

The final thing that I wanted to touch on here is really shared responsibility and how that impacts the overall security and compliance narrative. So, when we’re talking about cloud, whether that’s GCP, AWS, Azure, just cloud. We all have this common idea, the shared responsibility model or a customer responsibility model, SRM, CRM are our terms that you may hear or see very frequently. It’s the idea that the responsibility to secure, maintain and update the platform isn’t just on the cloud provider, and it’s not just on the customer, rather it’s a joint responsibility between the two. Now how much responsibility goes to the cloud service provider versus how much goes to the customer really depends on the service being used, from that cloud provider. 

So, when we talk about shared responsibility model and the cloud service provider’s responsibility, imagine like table stakes is that the cloud service provider, their responsibility is to essentially maintain the integrity and security of the infrastructure underlying the cloud platform that the customer is using. This is true for IaaS services, PaaS services, SaaS services. And if we were to add another CaaS services, which is a container as a service. 

Now, if you’ll notice here, the further sort of right that we go on this continuum or this sort of evolution of different as a service platforms that we have infrastructure as a service, platform as a service, software as a service, the further right that you go, the more responsibility that the cloud service provider agrees to maintain or takes control of, and the less responsibility that the customer has. There’s pros and cons and there’s reasons why different folks take different types of services for different reasons, but some of the things is, I’ve noticed that customers who feel confident in cloud security, who don’t necessarily have a lot of sensitive data, or who feel confident in their security controls, feel a lot of times more comfortable to go further right for the PaaS services, the SaaS services, or the containers as a service, whereas IaaS services, which certainly a great option as well, in general, folks who are moving from on-prem to the cloud may feel more comfortable making that transition because they have the most like to like mapping, especially if you are already virtualized on-prem. 

So the idea of you maintaining responsibility for, let’s say, managing guest OS on your VM, network security, access authentication, identity deployment, all of that would be customer responsibility. In the IaaS model, GCP retains responsibility for maintaining the underlying infrastructure, running GCP, but not too much outside of that. When you move to platform as a service, our customers really assume responsibility of application, application layer security, the deployment uses access policies, and the cloud service provider assumes responsibility for things like access and authentication, some of the guests OS, data and content management within the software as a service model, really your responsibility is towards the access policies and the content that you have running within those SaaS services and container as a service, which we don’t have listed here, but I think is one that we could say is its category if you will, that when your responsibility is essentially to, think about it similar to PaaS to some extent.So you’re responsible for implementing access and control policies for your containerized environments.

Final thing is compliance offering. GCP makes a very concerted effort, it’s definitely a guiding principle if you will, to be able to meet continuously more and more security regulations, certifications, and policy requirements that customers have, these are just a few of the ones that we currently meet, we meet many more than that and are always expanding. Like I mentioned earlier, we make contractual commitments to maintain to the best of our abilities, our ISO 27001, 17, 18, we also make commitments around SOC 2, SOC 3, SOC 2, SOC 3, as well as the PCI DSS, also have best practices papers for things like GDPR and GXP. 

Now, with that said, I did wanna thank everyone for y’all’s time, I hope you all have a great day, and that this was a useful session, and you learned a little bit more about security on the cloud. Have a good one. Bye.