Google Cloud

• Google Cloud Infra: Google applies zero- trust principles whereby there is no trust between services and multiple mechanisms are applied to establish trust. As a Google Cloud user you have the option to use the Google-operated - owned and -managed end-to-end private encrypted network. Google enforces Transport Layer Security (TLS) for its externally exposed Application Programming Interfaces (APIs) across its network and any data stored on Google Cloud is encrypted by default.
• Servers: In order to further strengthen its security posture Google has end-to-end provenance. Google servers are custom-built for the sole purpose of running Google services and don’t include unnecessary components such as video cards that can introduce vulnerabilities.
• Titan Chip: The same applies to software including the operating system (OS) which is a stripped-down hardened version of Linux. Google has also built Titan a custom security chip that offers first-nanosecond boot integrity and allows for both server and peripherals to establish a hardware root of trust. Titan uses cryptographic signatures to validate low-level components such as the BIOS bootloader kernel and base OS image during each boot or update cycle. Titan is embedded across Google’s hardware infrastructure servers storage arrays and even Pixelbooks and the latest Pixel phones.
• Access Transparency: This service allows customers to gain visibility if and when Google engineers try to access a customer environment. A typical use case would be when a customer contacts Google Cloud support and an engineer is assigned to work to resolve the case and requires access to customer cloud components. In this case Google can provide full transparency logs to the customer. All these cloud privacy commitments are backed by contractual agreements and commitments including third-party independent assessments.
• Data Privacy: The data privacy commitments include the fact that as a customer you own and control your data; Google does not access your data or move it to another location. As a customer you are responsible for securing and controlling access to your data. Google does not sell or use your data for advertising. There is no backdoor access to Google services for government or law enforcement. Google encrypts all communications across physical boundaries and encrypts data at rest automatically without customer intervention adding a further layer of security by default.
• Shared security responsibility: Security of the cloud refers to what the cloud service provider is responsible for and security in the cloud is about the customer having the responsibility to use security products and services offered natively in the cloud or third-party products. If the customer is using IaaS to host their workload then the customer is responsible for protecting the virtual infrastructure data users and monitoring. The responsibility shifts based on the type of service being used.
• Addressing compliance on Google Cloud: As part of Google’s compliance commitments all of Google’s products undergo various third-party independent assessments against compliance controls in order to achieve certifications for standards such as PCI-DSS ISO SOC 2 and so on. In order to be compliant Google implements hundreds of security controls to meet those compliance objectives. As a customer when you move to Google Cloud whether you host a single virtual machine or hundreds you end up inheriting all of these security controls. This not only makes your security posture better but also takes the cost and complexity out of your project scope making things much simpler from a compliance perspective.
• Shared Compliance: Let’s take a look at PCI-DSS as an example of how shared responsibility for compliance works. As a customer if you have the requirement to be PCI-DSS compliant you can use Google Cloud to run your compliant workloads by consuming Google Cloud services that are PCI compliant. From an infrastructure perspective Google Cloud is compliant with PCI- DSS. Your responsibility as a customer includes securing and making your applications and services compliant. These applications and services are not part of Google’s core infrastructure so they fall under the customer’s set of responsibilities.
• Security by design: Google’s approach to security by design is to ensure that multiple technology stacks are deployed to secure the infrastructure identities services and users.
• Operational security: Through BeyondCorp Enterprise Google ensures that appropriate users have timely access to designated applications. This approach involves continuous monitoring of devices and users regular patching and updates enforcement of strong authentication measures and utilization of two-factor authentication (2FA) at Google. Additionally application-level access controls restrict access to internal applications solely for authorized users accessing the service from managed devices and from network addresses or geolocations that align with the established policy.
• Google Customer Traffic: Once customers’ traffic is on Google’s network it no longer transits the public internet making it less likely to be attacked intercepted or manipulated in transit.
• Google Front Ends (GFEs): Google also secures its Google Front Ends (GFEs). When a service wants to make itself available on the internet it can register itself with the GFE. The GFE performs a number of functions such as ensuring that the correct certificates are used for terminating TLS and applying best practices such as perfect forward secrecy. GFEs also provide protection against DDoS attacks. Google has multi-tier and multi-layer protection for DDoS to ensure that the services behind GFEs are protected from such volumetric attacks. There are multiple layers of hardware- and software-based load balancers that are both network- and application-aware.
• Authentication: Google further enforces user authentication before it allows any access to its network. The user authentication goes beyond a simple username and password and also intelligently challenges users for additional information based on risk factors. These risk factors include information about the device the user is logging in from such as the IP address and geographical location of the device. Once past these controls the user is then prompted for a second factor before access is granted.
• Data security: In addition to the default encryption of data at rest as a Google Cloud user you also get the option to select a variety of different options for how you can encrypt data. You can choose to use the default encryption or use Cloud Key Management Service which can perform the entire key lifecycle management. Alternatively you can use Cloud Key Management Service and import your own key material or you can go the Bring Your Own Key (BYOK) route or use multi-tenant Cloud HSM which provides FIPS 140-2 Level 3 protection for your keys.
• Key and Data Security: If you operate in a highly regulated environment and need to retain full control of the keys and the infrastructure you do have the option to use a Google-partner- provided external HSM that is integrated with an external key management service and is accessed via Google’s Cloud Key Management Service.
• Data Wiping/Deletion: When you want to delete data on Google Cloud it’s not immediately deleted but is marked as scheduled for deletion; so if you have accidentally deleted your data you have the option to recover it. After the data is scheduled for deletion it is deleted in accordance with service-specific policies.
• Services and identity: For human-to-system interaction or for calls between systems (such as inter-service access) Google applies cryptographic authentication and authorization at the application layer before any access is granted. Although there are network-perimeter- based controls and network segmentation and firewall rules Google does not rely solely on that and applies zero-trust principles.
• Services and identity: Each service that’s running also has an associated service account including the cryptographic credentials that are used for authenticating and authorizing when a remote procedure call is initiated to access other services. Besides this there are a number of techniques used such as isolating and sandboxing in order to protect services that might be running on the same machine. Some of the techniques used are language- and kernel-based sandboxing hardware virtualization and Linux user separation.
• Services and identity: All protocols for applications such as HTTP are encapsulated inside the remote procedure call infrastructure. To provide greater control every service owner has the ability to configure the crypto-based protection level required for remote procedure calls; for example service owners can enable integrity-level protection for data that is of low sensitivity inside data centers.
• Services and identity: As part of Google’s encryption capability all data is automatically encrypted including the data that goes between the wide area network (WAN) and data centers. There is no additional configuration required to enable this and it is configured as default.
• Physical and hardware security: In terms of physical security Google has implemented multiple layers of protection across its global data center facilities. These measures include the use of Closed-Circuit Television (CCTV) vehicle barricades biometric identification systems access restrictions for authorized personnel thorough background checks for employees with facility access as well as the deployment of laser-based intrusion detection and metal detectors.
• Physical and hardware security: At some sites Google operates some of its servers inside a third- party data center. In those situations Google ensures that all additional physical security controls mandated by Google are deployed on top of what the data center already has in place. These physical security controls also form part of many compliance programs. Therefore it’s important for Google in order to stay compliant to adhere to consistent physical security controls for each of its facilities.
• Physical and hardware security: In order to eliminate supply chain risks Google has a process in place to vet every component vendor and audit and validate the security of the components.
• Physical and hardware security: Secure boot stack controls are becoming increasingly common and more and more customers are expecting their cloud service providers to have them in place. Google is leading the space in securing the boot stack and machine identity. A secure boot chain is built into servers to ensure that the right software is running. In order to ensure this Google applies techniques such as cryptographic signatures in its low-level components including the kernel BIOS bootloader and base operating system. Every time the server boots or updates these signatures are validated.
• Physical and hardware security In order to establish a hardware root of trust every server in the Google data center has an identity bound to the root of trust and the software. When using an API the same authentication credentials are used for all calls made in order to manage the underlying systems and perform administrative tasks. To manage a large fleet of servers and to ensure they are updated and patched in a timely manner Google has created automation systems to detect and diagnose both hardware- and software-related issues where if required machines are removed from the respective service.
• Threat and vulnerability management: Google actively scans for security- related threats and has manual and automated penetration testing security assurance programs and a very mature software security system that includes automated source code scanning and manual reviews. Each identified vulnerability is assigned a priority based on its severity and the respective team and owners are assigned to mitigate and fix the vulnerability.
• Threat and vulnerability management: Google has automated scanners that look for websites that host malware and flag them in its search for potential malicious websites used for malware and phishing. The Google Safe Browsing solution scans billions of URLs every day in order to find unsafe websites and then flag them to warn users.
• Threat and vulnerability management: Besides Google Safe Browsing another of Google’s products is VirusTotal which is a repository for viruses Trojans backdoors worms and other malicious software. Many adversaries modify their virus signatures to avoid detection by anti-virus tools; therefore Google uses multiple anti-virus engines in products such as Google Drive and Gmail to effectively identify malware that may be missed by a single engine.
• Threat and vulnerability management: Google’s Threat Analysis Group and its security research arm Project Zero work by identifying security threats and making organizations aware of them such as by placing alerts on public data repositories. For unknown threats Google conducts automated analysis of the network and further investigation is conducted to understand how it operates and whether a flag is a false positive or not.