Security operations teams are facing a “perfect storm” of challenges from nation-state actors turning their attention to financial crime, to rising uncertainty and potential complexities because of rapidly advancing cloud migration and IoT adoption, to the long-lamented skills shortage. 

Now imagine having to face this trifecta without visibility into your IT and security infrastructure because scale and cost concerns have impeded your ability to ingest and monitor critical telemetry. To help organizations rethink threat detection and broader security team efforts, we showcased at this month’s Google Cloud Security Talks a keynote on why DEI is a cybersecurity imperative, Mandiant’s review of lessons for organizations two years after SolarWinds, how Google Chrome already helps protect your business (and what more you can make do with it,) how best to encourage your organization to pursue Zero Trust, and three key ways in which Chronicle Security Operations can help your organization scale threat detection and actionable outcomes. These include:

1. Operationalizing threat intelligence

Harnessing the power of threat intelligence to acquire context, prioritize risk, and act on detections requires more than just ingesting a set of indicator of compromise (IOC) feeds. Threat intelligence must have breadth and depth of coverage to provide custom details on the tools, tactics, and procedures of threat actors. Explore why part of the “magic” behind Google Cloud’s security is the sheer scale of threat intelligence we can share with our customers. 

2. Driving detection as code

We want to enable organizations that are more advanced in their cybersecurity maturity to build their own custom detections and rules, which means offering our customers a powerful detection-authoring platform. Chronicle Security Operations can help analysts build specific detections around, for example, known bad files or a specific registry key change. We also demonstrated how to create more complex detections, such as flagging process execution patterns or crafting a suspicious-behavior trigger from a specific activity sequence.

3. Leveraging curated detections

With curated detections, which we announced in August, we are putting the power of Google Cloud’s intelligence in the hands of security operations teams everywhere. Our detections offer actionable, ready-to-use threat detection content curated, built, and maintained by Google Cloud Threat Intelligence (GCTI) researchers. These detection sets cover a wide variety of threats for your network and beyond, including attacks such as ransomware, remote-access tools (RAT), infostealers, data exfiltration, and suspicious activity.

You can watch all nine of our Security Talks recorded sessions here, and keep an eye out for our next Security Talks, coming in March 2023.

This blog includes content from Episode One “Confidentially Speaking” of our Cloud Security Podcast, hosted by Anton Chuvakin (Head of Solutions Strategy) and Timothy Peacock (Product Manager). You should listen to the whole conversation for more insights and deeper context.LEARN MORECloud Security Podcast – Confidentially SpeakingListen to the Cloud Security Podcast with guest Nelly Porter, Group Product Manager @ Google.

We all deal with a lot of sensitive data and today, enterprises must entrust all of this sensitive data to their cloud providers. With on-premises systems, companies used to have a very clear idea about who could access data and who was responsible for protecting that data. Now, data lives in many different places—on-premises, at the edge, or in the cloud. 

You may already know that Google Cloud provides encryption for data when it is in transit or at rest by default, but did you also know we also allow you to encrypt data in use—while it’s being processed? 

In this podcast episode, Product Manager Nelly Porter gave us a peek under the hood of  confidential computing at Google Cloud. 

What is confidential computing? 

Google Cloud’s Confidential Computing started with a dream to find a way to protect data when it’s being used. We developed breakthrough technology to encrypt data when it is in use, leveraging Confidential VMs and GKE Nodes to keep code and other data encrypted when it’s being processed in memory. The idea is to ensure encrypted data stays private while being processed, reducing exposure.

During the episode, Nelly Porter explained that Google Cloud’s approach is based on hardware and CPU capability. Confidential Computing is built on the newest generation of AMD CPU processors, which have a Secure Encrypted Virtualization extension that enables the hardware to generate encryption keys that are ephemeral and associated with a single VM.  Basically, they are never stored anywhere else and are not extractable—the software will never have access to those keys. 

“You can do whatever you need to do, but you will be in a cryptographically isolated space that no other strangers passing by can see.”

Memory controllers use the keys to quickly decrypt cache lines when you need to execute an instruction and then immediately encrypts them again. In the CPU itself, data is decrypted but it remains encrypted in memory. 

Confidential computing aims to mitigate gaps in data security

Nelly also shed some light on why confidential computing will continue to play a central role in the future of cloud computing. She pointed out that one of the biggest gaps companies are looking to cover is securing data when it is in use. 

Data that is encrypted on-premises or in cloud storage, but the biggest risk for companies is when they start working with that data. For instance, imagine you encrypted your data on-premises and only you hold the keys. You upload that data into Cloud Storage buckets—simple, safe, and secure. 

But now, you want to train machine learning models based on that data. When you upload it into your environment, it’s no longer protected. Specifically, data in reserved memory is not encrypted.We’re trying to ensure that your data is always protected in whatever state it exists, so fewer people have the opportunity to make mistakes or maliciously expose your data.

Top takeaways about confidential computing 

Throughout the conversation, Nelly also shared interesting points about the development and direction of confidential computing at Google Cloud. 

Here were our favorite takeaways from the podcast: 

We worked hard to make Google Cloud’s approach simple.
We’ve invested a lot of time and effort into investigating the possibilities (and limitations) of confidential computing to avoid introducing residual risks to our approach. For instance, the early introduction of hardware capable of confidential computing in the industry required IT teams to have the resources to rewrite or refactor their app, severely limiting their ability to adopt it within their organizations. 

With Confidential Computing, teams can encrypt data in use without making any code changes in their applications.  All Google Cloud workloads can run as Confidential VMs, enabled with a single checkbox, making the transition to confidential computing completely simple and seamless. 

“A lot of customers understand the values of confidential computing, but simply cannot support re-writing the entire application. It’s why Google Cloud, in particular, decided to take a different approach and use models that were incredibly easy to implement, ensuring that our customers would not have those barriers to cross.”

Confidential computing is for more than just fintech. 
There is, of course, a compelling use case for confidential computing at highly-regulated companies in financial, government, life sciences, and public sectors. However, Nelly shared that her team didn’t anticipate that even verticals without significant regulation or compliance requirements would be so interested in this technology, mostly to pre-empt privacy concerns. 

Many companies see confidential computing as a way to create cryptographic isolation in the public cloud, allowing them to further ease any user or client concerns about what they are doing to protect sensitive data. For instance, during COVID-19, there was an increase in small research organizations that wanted to collaborate across large datasets of sensitive data. 

“Prior to confidential computing, it wasn’t possible to collaborate because you needed the ability to share very sensitive data sets among multiple parties while ensuring none of them will have access to this data, but the results will benefit all of them—and us.”

An open community, working together will be key for the future. 
Nelly also shared that there are plans to extend memory protections beyond just CPUs to cover GPUs, TPUs, and FPGAs. Google Cloud is working with multiple industry vendors and companies to develop confidential computing solutions that will cover specific requirements and use cases.

Confidential computing will not be achieved by a single organization – it will require many people to come together. We are a member of the Confidential Computing Consortium, which aims to solve security for data in use and includes other vendors like Red Hat, Intel, IBM, and Microsoft. 

“Google alone would not be able to accomplish confidential computing. We need to ensure that all vendors, GPU, CPU, and all of them follow suit. Part of that trust model is that it’s third parties’ keys and hardware that we’re exposing to a customer.”

There are no magic bullets when it comes to security. 
Confidential computing is still an emerging, very new technology and unsurprisingly, there are a lot of questions about what it does and how it works. It’s important to remember that there is no such thing as the one-tool-fits-all-threats security solution. Instead, Nelly notes that confidential computing is yet another tool that can be added to your security arsenal. 

“No solution will ever be the magic bullet that will make everyone happy and secure, guaranteed. But confidential computing is an addition to our toolbox of defense against gaps we have to take super seriously and invest in solving.” 

Did you enjoy this blog post? To listen to the full conversation, head over to Episode One “Confidentially Speaking” of our Cloud Security Podcast, hosted by Anton Chuvakin (Head of Solutions Strategy) and Timothy Peacock (Product Manager). 

We also recommend checking out other episodes of the Cloud Security Podcast by Google for more interesting stories and insights about security in the cloud, from the cloud, and of course, what we’re doing at Google Cloud.

Content production is increasingly happening in the cloud. While moving a creative process that spans three centuries into the modern era brings challenges and risks, MovieLabs is one organization that takes digital transformation seriously.

A nonprofit research and development group founded by a consortium of the major Hollywood studios, MovieLabs describes their mission as “exploring innovative solutions to industry challenges shared by both our member studios and the broader production, post-production and distribution ecosystem.”

In more than 50 pages of densely-packed ideas and principles, MovieLab’s The Evolution of Media Production lays out an ambitious and revelatory vision for streamlining media production in the cloud. The key themes are summarized in 10 declarative statements, which envision a new modality for media production by the year 2030:

1. All assets are created or ingested straight into the cloud and do not need to be moved.
2. Applications come to the media.
3. Propagation and distribution of assets is a “publish” function.
4. Archives are deep libraries with access policies matching speed, availability and security to the economics of the cloud.
5. Preservation of digital assets includes the future means to access them and edit them.
6. Every individual on a project is identified and verified, and their access permissions are efficiently and consistently managed.
7. All media creation happens in a highly secure environment that adapts rapidly to changing threats.
8. Individual media elements are referenced, accessed, tracked and interrelated using a universal linking system.
9. Media workflows are non-destructive and dynamically created using common interfaces, underlying data formats and metadata.
10. Workflows are designed around real-time iteration and feedback.

The four bolded statements above are further explored in a follow-up whitepaper from MovieLabs, The Evolution of Production Security, which likewise offers six statements about what secure production in the cloud should look like:

1. Security is Intrinsic and does not Inhibit Creative Processes
2. The Security Architecture Addresses Challenges Specific to Cloud Workflows
3. Production Workflows, Processes, and Assets are Secure, even on Untrusted Infrastructure
4. The Content Owner Controls Security and Workflow Integrity
5. The Security Can Be Scaled to Appropriate Levels and Can Integrate
6. The Security Architecture Limits the Spread of any Breach and is Adaptable

The key to understanding these two papers is repeated in their titles: Evolution. Neither document is meant to outline solely what’s possible today; rather they are beacons guiding us toward a future in which the movie business is truly transformed by the cloud operating model. That means a future where media productions run much more like software supply chains: with speed, agility, and scale, and without sacrificing availability or security.

The good news is that it is possible to deploy secure production workloads in the cloud today. Using some of the built-in security features of Google Cloud, content producers can achieve Common Security Architecture for Production (CSAP) “Level 100” security for their assets (using the CSAP scale L100-L300). 

However, we think that “evolution” word is important. As many companies have learned, operating an infrastructure cloud can be costly and often presents new threat vectors for attackers. Our mission at Google Cloud is to provide scalable, reliable services for traditional IT functions and to accelerate the abilities of every organization to digitally transform its business. 

We believe the era of the transformation cloud is dawning, and companies who have been successfully operating in the cloud for years are now looking for ways to reduce costs while maintaining the cloud-scale advantages of agility and global reach. This aligns perfectly with the evolutionary vision of the MovieLabs papers, which envision media workflows changing radically to embrace cloud dynamism without all the unnecessary asset movement and complexity.

An important part of that vision from Google Cloud is that cloud service providers should remain open and interoperable with other clouds and infrastructures.

Here is a quickstart guide to mapping the L100 CSAP requirements to Google Cloud:

As you can see in the diagram, external identity providers (IdPs) such as Okta or Active Directory can serve as core security components of a CSAP L100 architecture. Alternatively, Google Cloud services such as Cloud Identity or Managed AD could be substituted.

Next, Google Cloud’s Identity-Aware Proxy (IAP) can be used in combination with Access Context Manager (ACM) to act as the first Policy Enforcement Point. This is an optional step, since it is somewhat redundant with the routing and authorization function performed by the native HP/Teradici Connection Brokers. However, IAP and ACM are core components of Google Cloud’s BeyondCorp architecture, on which CSAP is based. Additionally, adopting IAP with ACM offers productions the ability to swap out the Teradici PCoIP protocol for an alternative, such as Unity’s Parsec, without sacrificing security.

The Teradici Connection Broker is also a Policy Enforcement Point, since groups and role membership can be used to enforce access to specific workstations. 

Finally, the identity context for each user is passed through to the storage layer. For some productions, Google Cloud Storage (GCS) buckets may offer enough functionality; GCS offers an S3-compatible API which should make it easy to immediately adopt OSS tools built for S3. Other options for this include the managed NetApp Cloud Volumes and Dell PowerScale for Google Cloud services. Both of these are managed shared storage services which offer file-level access controls using standard SMB/NFS permissions. There are also a variety of third-party filers available in the Google Cloud Marketplace, such as Nasuni. You can read more about those here.

For added security, both NetApp and PowerScale should be configured to use the private services access model in Google Cloud. This effectively limits any external access to these resources by only allowing traffic from user-managed VPCs into the Google-managed and peered VPC.

Following this architecture, you can see how to achieve CSAP L100 compliance by using either only Google Cloud services or a mix of managed and cloud-first services. In either scenario, access is managed through a unified control plane and based on both user identity and role. Zero Trust principles such as context-aware access and dynamic rulesets could further be applied to the Authentication step using either Google Cloud IAP or the equivalent services from Okta, Active Directory, or others.

At this weekend’s National Association of Broadcasters conference, Google experts will be talking about the cloud and content production, and the intersection of AI and media. The journey to 2030 is only just beginning.

The National Institute of Standards and Technology (NIST) on Tuesday announced the completion of the third round of the Post-Quantum Cryptography (PQC) standardization process, and we are pleased to share that a submission (SPHINCS+) with Google’s involvement was selected for standardization. Two submissions (Classic McEliece, BIKE) are being considered for the next round. 

We want to congratulate the Googlers involved in the submissions (Stefan Kölbl, Rafael Misoczki, and Christiane Peters) and thank Sophie Schmieg for moving PQC efforts forward at Google. We would also like to congratulate all the participants and thank NIST for their dedication to advancing these important issues for the entire ecosystem.

This work is incredibly important as we continue to advance quantum computing. Large-scale quantum computers will be powerful enough to break most public-key cryptosystems currently in use and compromise digital communications on the Internet and elsewhere. The goal of PQC is to develop cryptographic systems that safeguard against these potential threats, and NIST’s announcement is a critical step toward that goal. Governments in particular are in a race to secure information because foreign adversaries can harvest sensitive information now and decrypt it later.  

At Google, our work on PQC is focused on four areas: 1) driving industry contributions to standards bodies;  2) moving the ecosystem beyond theory and into practice (primarily through testing PQC algorithms); 3) taking action to ensure that Google is PQC ready; and 4) helping customers manage the transition to PQC. 

Driving industry contributions to a range of standards bodies 

In addition to our work with NIST, we continue to drive industry contributions to international standards bodies to help advance PQC standards. This includes ISO 14888-4, where Googlers are the editors for a standard on stateful hash-based signatures. More recently, we also contributed to the IETF proposal on data formats, which will define JSON and CBOR serialization formats for PQC digital signature schemes. These standards, collectively, will enable large organizations to build PQC solutions that are compatible and ease the transition globally.

Moving the ecosystem beyond theory and into practice: Testing PQC algorithms

We’ve been working with the security community for over a decade to explore options for PQC algorithms beyond theoretical implementations. We announced in 2016 an experiment in Chrome where a small fraction of connections between desktop Chrome and Google’s servers used a post-quantum key-exchange algorithm, in addition to the elliptic-curve key-exchange algorithm that would typically be used. By adding a post-quantum algorithm in a hybrid mode with the existing key-exchange, we were able to test its implementation without affecting user security. 

We took this work further in 2019 and announced a wide-scale post-quantum experiment with Cloudflare. We worked together to implement two post-quantum key exchanges, integrated them into Cloudflare’s TLS stack, and deployed the implementation on edge servers and in Chrome Canary clients. Through this work, we learned more about the performance and feasibility of deployment in TLS of two post-quantum key agreements, and have continued to integrate these learnings into our technology roadmap.  

In 2021, we tested broader deployment of post-quantum confidentiality in TLS and discovered a range of network products that were incompatible with post-quantum TLS. We were able to work with the vendor so that the issue was fixed in future firmware updates. By experimenting early, we resolved this issue for future deployments.

Taking action to ensure that Google is PQC ready

At Google, we’re well into a multi-year effort to migrate to post-quantum cryptography that is designed to address both immediate and long-term risks to protect sensitive information. We have one goal: ensure that Google is PQC ready. Internally, this effort has several key priorities, including securing asymmetric encryption, in particular encryption in transit. This means using ALTS, for which we are using a hybrid key-exchange, to secure internal traffic; and using TLS (consistent with NIST standards) for external traffic. A second priority is securing signatures in the case of hard-to-change public keys or keys with a long lifetime, in particular focusing on hardware, especially hardware deployed outside of Google’s control. 

We’re also focused on sharing the information we learn to help others address PQC challenges. For example, we recently published a paper that includes PQC transition timelines, leading strategies to protect systems against quantum attacks, and approaches for combining pre-quantum cryptography with PQC to minimize transition risks. The paper also suggests standards to start experimenting with now and provides a series of other recommendations to allow organizations to achieve a smooth and timely PQC transition.

Helping customers manage the transition to PQC

At Google Cloud, we are working with many large enterprises to ensure they are crypto-agile and to help them prepare for the PQC transition. We fully expect customers to turn to us for post-quantum cloud capabilities, and we will be ready. We are committed to supporting their PQC transition with a range of Google products, services, and infrastructure. As we make progress, we will continue to provide more PQC updates on Google core, cloud, and other services, and updates will also come from Android, Chrome and other teams. We will further support our customers with Google Cloud transformation partners like the Google Cybersecurity Action Team to help provide deep technical expertise on PQC topics. 

Additional References:

• Google Cloud Security Foundations Guide
• Google Cloud Architecture Framework 
• Google infrastructure security design overview

At Google Cloud, we believe that the protection of our customers’ sensitive data is paramount, and encryption is a powerful mechanism to help achieve this goal. For years, we have supported encryption in transit when our customers ingest their data to bring it to the cloud. We’ve also long supported encryption at rest, for all customer content stored in Google Cloud.

To complete the full data protection lifecycle, we can protect customer data when it’s processed through our Confidential Computing portfolio. Confidential Computing products from Google Cloud protect data in use by performing computation in a hardware isolated environment that is encrypted with keys managed by the processor and unavailable to the operator. These isolated environments help prevent unauthorized access or modification of applications and data while in use, thereby increasing the security assurances for organizations that manage sensitive and regulated data in public cloud infrastructure.

Secure isolation has always been a critical component of our cloud infrastructure; with Confidential Computing, this isolation is cryptographically reinforced. Google Cloud’s Confidential Computing products leverage security components in AMD EPYC™ processors including AMD Secure Encrypted Virtualization (SEV) technology.

Building trust in Confidential Computing through industry collaboration

Part of our mission to bring Confidential Computing technology to more cloud workloads and services is to make sure that the hardware and software used to build these technologies is continuously reviewed and tested. We evaluate different attack vectors to help ensure Google Cloud Confidential Computing environments are protected against a broad range of attacks. As part of this evaluation, we recognize that the secure use of our services and the Internet ecosystem as a whole depends on interactions with applications, hardware, software, and services that Google doesn’t own or operate.

The Google Cloud Security team, Google Project Zero, and the AMD firmware and product security teams collaborated for several months to conduct a detailed review of the technology and firmware that powers AMD Confidential Computing technology. This review covered both Secure Encrypted Virtualization (SEV) capable CPUs, and the next generation of Secure Nested Paging (SEV-SNP) capable CPUs which protect confidential VMs against the hypervisor itself. The goal of this review was to work together and analyze the firmware and technologies AMD uses to help build Google Cloud’s Confidential Computing services to further build trust in these technologies.

This in-depth review focused on the implementation of the AMD secure processor in the third generation AMD EPYC processor family delivering SEV-SNP. SNP further improves the posture of confidential computing using technology that removes the hypervisor from the trust boundary of the guest, allowing customers to treat the Cloud Service Provider as another untrusted party. The review covered several AMD secure processor components and evaluated multiple different attack vectors. The collective group reviewed the design and source code implementation of SEV, wrote custom test code, and ran hardware security tests, attempting to identify any potential vulnerabilities that could affect this environment.

Working on this review, the security teams identified and confirmed potential issues of varying severity. AMD was diligent in fixing all applicable issues and now offers updated firmware through its OEM channels. Google Cloud’s AMD-based Confidential Computing solutions now include all the mitigations implemented during the security review.

“At Google, we believe that investing in security research outside of our own platforms is a critical step in keeping organizations across the broader ecosystem safe,” said Royal Hansen, vice president of Security Engineering at Google. “At the end of the day, we all benefit from a secure ecosystem that organizations rely on for their technology needs and that is why we’re incredibly appreciative of our strong collaboration with AMD on these efforts.”

“Together, AMD and Google Cloud are continuing to advance Confidential Computing, helping enterprises to move sensitive workloads to the cloud with high levels of privacy and security, without compromising performance,” said Mark Papermaster, AMD’s executive vice president and chief technology officer. ”Continuously investing in the security of these technologies through collaboration with the industry is critical to providing customer transformation through Confidential Computing. We’re thankful to have partnered with Google Cloud and the Google Security teams to advance our security technology and help shape future Confidential Computing innovations to come.”

Reviewing trusted execution environments for security is difficult given the closed-source firmware and proprietary hardware components. This is why research and collaborations such as this are critical to improve the security of foundational components that support the broader Internet ecosystem. AMD and Google believe that transparency helps provide further assurance to customers adopting Confidential Computing, and to that end AMD is working toward a model of open source security firmware.

With the analysis now complete and the vulnerabilities addressed, the AMD and Google security teams agree that the AMD firmware which enables Confidential Computing solutions meets an elevated security bar for customers, as the firmware design updates mitigate several bug classes and offer a way to recover from vulnerabilities. More importantly, the review also found that Confidential VMs are protected against a broad range of attacks described in the review.

Google Cloud’s Confidential Computing portfolio

The Google Cloud Confidential VMs, Dataproc Confidential Compute, and Confidential GKE Nodes have enabled high levels of security and privacy to address our customers’ data protection needs without compromising usability, performance, and scale. Our mission is to make this technology ubiquitous across the cloud. Confidential VMs run on hosts with AMD EPYC processors which feature AMD Secure Encrypted Virtualization (SEV). Incorporating SEV into Confidential VMs provide benefits and features including:

Isolation: Memory encryption keys are generated by the AMD Secure Processor during VM creation and reside solely within the AMD Secure Processor. Other VM encryption keys such as for disk encryption can be generated and managed by an external key manager or in Google Cloud HSM. Both sets of these keys are not accessible by Google Cloud, offering strong isolation.

Attestation: Confidential VMs use Virtual Trusted Platform Module (vTPM) attestation. Every time a Confidential VM boots, a launch attestation report event is generated and posted to customer cloud logging, which gives administrators the opportunity to act as necessary.

Performance: Confidential Computing offers high performance for demanding computational tasks. Enabling Confidential VM has little or no impact on most workloads.

The future of Confidential Computing and secure platforms

While there are no absolutes in computer security, collaborative research efforts help uncover security vulnerabilities that can emerge in complex environments and help to prevent Confidential Computing solutions from threats today and into the future. Ultimately, this helps us increase levels of trust for customers.

We believe Confidential Computing is an industry-wide effort that is critical for securing sensitive workloads in the cloud and are grateful to AMD for their continued collaboration on this journey.

To read the full security review, visit this page.

Acknowledgments 

We thank the many Google security team members who contributed to this ongoing security collaboration and review, including James Forshaw, Jann Horn and Mark Brand.

We are grateful for the open collaboration with AMD engineers, and wish to thank David Kaplan, Richard Relph and Nathan Nadarajah for their commitment to product security. We would also like to thank AMD leadership: Ab Nacef, Prabhu Jayanna, Hugo Romero, Andrej Zdravkovic and Mark Papermaster for their support of this joint effort.