Our quarterly Security Talks series brings together experts from Google Cloud Security teams and the industry to share information on our latest security products, innovations and best practices. Below is an introduction to Mandiant’s Security Talks presentation on Dec. 7, Mandiant Tales from the Front Lines: Activate Cyber Defenses Against Supply Chain Compromise.

The discovery in December 2020 of the SolarWinds supply chain compromise, a global computer intrusion campaign, caused organizations and security leaders to completely reassess their Cyber Threat Profiles, risk assessments, and defensive postures. It was a rare, watershed event that savvy security leaders and IT decision makers have been using to improve how security teams protect systems, networks, and data across industries and sectors, especially critical infrastructure. Two years later, we’re looking back at the security incident, what we’ve learned, and how it continues to drive change across security teams and organizations.

The SolarWinds compromise leveraged access to the software maker’s Orion business software in order to distribute a malicious update containing malware. Mandiant has since attributed this operation to APT29, a Russia-based espionage group assessed to be sponsored by the Russian Foreign Intelligence Service (SVR). This operation afforded APT29 with unparalleled access to an estimated 18,000 global organizations for follow-on targeting based on the attacker’s discretion and collection priorities.

While the security industry has yet to see anything that rivals the scale and scope of the SolarWinds compromise since it was discovered, a recent Google Cloud research report on software supply chain security found that there’s been a sharp increase in software supply chain attacks across nearly every sector.

Mandiant analysis identified supply chain compromise as the second-most prevalent initial infection vector in 2021. When the initial infection vector was identified, supply chain compromise accounted for 17% of intrusions in 2021 compared to less than 1% of intrusions in 2020. Further, 86% of supply chain compromise intrusions in 2021 were related to the SolarWinds breach.

Since 2020, Mandiant has also observed an increase in financially-motivated threat actors targeting the software supply chain. These actors compromised popular software packages and even mobile applications in order to deploy ransomware, cryptocurrency miners, and banking trojans. In one case, malicious code was inserted into a popular package, prompting the U.S. Cybersecurity and Infrastructure Agency (CISA) to issue an alert about the compromise.

Mitigation recommendations

The discovery of the SolarWinds incident resulted in increased global attention around supply chain compromise threats. Government authorities and technology organizations have responded with several initiatives, legislation, and studies seeking to reduce software supply chain and software dependency risk. Although these initiatives may make it more difficult for threat actors to conduct these operations, organizations should also take steps to mitigate supply chain threats.

Mandiant suggests that organizations contemplate applying multiple layers of security policies, plans, and solutions to maximize opportunities to provide early threat detection and prevent an anomaly or compromise stemming from the supply chain. This guidance is aligned with best practices Google Cloud has recommended for organizations to improve their software supply chain security.

Mandiant has also provided the following additional recommendations for organizations to consider more generally:

• Establish a vendor vetting process to evaluate vendor security practices before deploying hardware or software.
• Create a change control process and board for all enterprise hardware and software changes, which could include a centralized IT or IT security managed process for downloading, testing, and pushing updates to users.
• Use an advanced endpoint security solution, such as an endpoint detection and response (EDR), to detect malicious behavior when a tainted software package is downloaded and executed.
• Ensure proper logging and monitoring is in place between the software, hardware, and the internet.
• Implement the software and hardware using network segmentation with minimal access to the internet.
• Enact employee training programs and policies to encourage security best practices, including security audits of code in development.

Next steps

You can watch the Google Cloud Security Talks presentation on SolarWinds and the current state of supply chain threats here. You can learn more about Google Cloud’s solutions to help improve software supply chain security here, or for more general inquiries, please contact us or reach out to your sales representative to learn how we can assist.

Today, we are happy to announce that Confidential GKE Nodes are available on compute optimized C2D VMs.

Many companies have adopted Google Kubernetes Engine (GKE) as a key component in their application infrastructure. In some cases, the advantages of using containers and Kubernetes can surpass those of traditional architectures, but migrating to and operating apps in the cloud often requires strategic planning to reduce risk and prevent data breaches. This is where Confidential GKE Nodes can be utilized to enhance the security of your GKE clusters or node pools.

Confidential GKE Nodes leverage specialized hardware to encrypt data in-use and are ideal for organizations processing sensitive data in the cloud. To make it easier to start using Confidential GKE Nodes, GKE standard workloads you run today can run as confidential GKE workloads without code changes on your end.

Security underpinnings of Confidential GKE Nodes

As we expand the Confidential Computing product portfolio from Confidential VMs to Confidential GKE Nodes to Confidential Dataproc, ensuring high performance is key. Confidential GKE Nodes are built on the same technology foundation as Confidential VM and utilize the Secure Encrypted Virtualization (SEV) capability of AMD EPYC™ processors. This feature allows you to keep data encrypted in memory with node-specific, dedicated keys that are generated and managed by the processor. The keys are generated in hardware during node creation and reside solely within the processor, making them unavailable to Google Cloud or other nodes running on the host.

Combined with the high performance of C2D VMs

Previously, Confidential GKE Nodes were generally available only on general purpose N2D VMs, but now they’re also available on compute optimized C2D VMs. The C2D machine series provides VM sizes ranging from 2 vCPUs to 112 vCPUs, offers up to 896 GB of memory, and are suited for performance-intensive workloads. C2D standard and C2D high-CPU machines serve compute-bound workloads including high-performance web servers and media transcoding. C2D high-memory machines serve specialized workloads such as high-performance computing (HPC) and electronic design automation (EDA), which require more memory.

Confidential GKE Nodes on compute-optimized C2D VMs could be a fit for use cases that require high performance and security. You can achieve encryption in-use for data processed inside your GKE cluster or just on specific node pools, without significant performance degradation. This is relevant for industries such as financial services, healthcare, retail, blockchain, and telecommunications, which often have sensitive data or personally identifiable information (PII) that requires additional security measures.

How MATRIXX used Confidential GKE Nodes

MATRIXX Software chose Confidential GKE Nodes to provide transparent encryption for data in-use to supplement encryption for data at-rest to secure personal subscriber data as required by privacy regulations.

MATRIXX Digital Commerce Platform (DCP) is a real-time 5G monetization for the communications industry, serving many of the world’s largest operator groups, regional carriers, and emerging digital service providers. MATRIXX used Google Cloud Confidential GKE Nodes to deliver a cloud-first digital commerce solution that enables commercial and operational agility for current and new telco business models.

A whitepaper titled “Protecting Your 5G Revenue Stream in the Cloud,” described how when MATRIXX DCP is deployed with Confidential Computing on Google Cloud, “its subscriber data, account balances, network events and charges/revenue streams are encrypted in use without making any code changes to the application or compromising on performance.”

Confidential GKE Nodes are globally available

At Google Cloud, we’re committed to investing in Confidential Computing, so we’ve expanded our support to VM families like C2D VMs. Confidential GKE Nodes running on C2D VMs are available in regions across the globe, including us-central1 (Iowa), asia-southeast1 (Singapore), us-east1 (South Carolina), us-east4 (North Virginia), asia-east1 (Taiwan), and europe-west4 (Netherlands). Note that Confidential GKE Nodes are available where C2D or N2D machines are available.

Pricing for Confidential GKE Nodes

There is no additional cost to deploy Confidential GKE Nodes, other than the costs of Compute Engine and Confidential VM pricing.

Try out Confidential GKE Nodes for cluster-level enablement

• First, go to the Google Kubernetes Engine page in the Google Cloud console. In the top navigation bar, click Create. In the Create Cluster modal, choose ‘Standard: You manage your cluster’ and click Configure.
• Next, from the left navigation pane, under Cluster, click Security. Select the ‘Enable Confidential GKE Nodes’ checkbox.
• Then, from the left navigation pane again, under Node Pools, click Nodes. Under Machine Configuration and Machine family, select the Compute-optimized tab, and choose a C2D machine type.

Configure the rest of the cluster as desired and click Create.

Making secure design choices should be easy, especially when the workloads involve high-performance processing of sensitive data. You can help protect your sensitive applications and data today by adding Confidential GKE Nodes to your GKE workloads. Learn more about Confidential Computing here.

Taking prescription medication at the direction of anyone other than a trained physician is very risky—and the same could be said for selecting technology used to run a hospital, to manage a drug manufacturing facility and, increasingly, to treat a patient for a medical condition.

To pick the right medication, physicians need to carefully consider its ingredients, the therapeutic value they collectively provide, and the patient’s condition. Healthcare cybersecurity leaders similarly need to know what goes into the technology their organization’s use to manage patient medical records, manufacture compound drugs, and treat patients in order to keep them safe from cybersecurity threats.

Just like prescription medication, careful vetting and selection of the technology is required to ensure patient safety and establish visibility and awareness into the technology modern healthcare depends on to create a resilient healthcare system.

In this and our next blog, we focus on two topics critical to building resilience – software bill of materials (SBOM) and Google’s Supply chain Levels for Software Artifacts (SLSA) framework – and how to use them to make technology safe. Securing the software supply chain, or where the software we depend comes from, is a critical security priority for defenders and something Google is committed to helping organizations do.

Diving deeper into the technology we rely on

Cybersecurity priorities for securing healthcare systems usually focus only on protecting sensitive healthcare information, like Protected Health Information (PHI). Maintaining the privacy of patient records is an important objective and securing data and systems plays a big role in this regard.

Healthcare system leadership and other decision makers often depend on cybersecurity experts to select technologies and service providers that can meet regulatory rules for protecting data as a first (and sometimes only) priority. Trust is often placed on the reputations and compliance programs of the vendors who manufacture the technology they buy without much further inspection. Decision makers need to approach every key healthcare and life science technology or service provider choice as a high-risk, high-consequence decision, but few healthcare organizations have the skills, resources, and time to “go deep” in vetting the security built into the technology they buy before it enters a care setting.

Vetting needs to include penetrating analysis of all aspects of software and hardware, their architecture and engineering quality, the provenance of all parts that they’re made of, and assessing each component for risk. Doing this can sometimes require deep technical skills and advanced knowledge of medical equipment threats that may not be easy to acquire. Instead of making additional investments to help secure their networks and systems, many organizations choose simpler paths.

The failure to properly assess technological susceptibility to risk has exposed healthcare organizations and their patients to a variety of safety and security issues that may have been preventable. PTC (formerly Parametric Technology Corporation, which makes medical device software) disclosed seven vulnerabilities in March that impacted equipment used for robotic radiosurgery. In October 2019, the VxWorks Urgent 11 series of vulnerabilities was announced, affecting more than 1 billion connected devices, many used throughout healthcare and life sciences. More examples of medical devices and software found to have vulnerable components can be found on the FDAs cybersecurity website and in its recall database.

How a physician understands, selects, and prescribes medication parallels how we address these concerns when selecting technology. Recent FDA guidance suggests manufacturers must soon provide increased levels of visibility into the technologies they market and sell in the healthcare industry. Here’s where the SBOM, a key visibility mechanism, comes in.

What SBOMs do well, and how Google is helping make them better

The National Telecommunications and Information Administration defines the SBOM as a “nested inventory for software, a list of ingredients that make up software components.”

The concept of a SBOM appears to have found its start in enabling software makers back in the 1990s, although it originally stems from ideas popularized by visionary engineer and professor W. Edwards Deming. SBOM as a concept has advanced since then, with multiple standards for generating and sharing them now in use.

Thanks to the continued focus on improving and using SBOMs, we expect it will be much easier for defenders to use SBOMs to track software and its components, where they come from, what security vulnerabilities they contain, and equip protectors with their ability to stop those vulnerabilities from being exploited, at scale, and before they impact patient care.

“Software bills of materials help to bridge the knowledge gap created by running unknown, unpatched software and components as too many healthcare organizations currently do,” says Dan Walsh, chief information security officer at VillageMD, a tech-driven primary-care provider. “For security leaders, SBOM should be an extension of their asset inventory and management capability, regardless of whether that software was bought or built. At VillageMD, we are asking our vendors that store, transmit, receive or process PHI for an SBOM as part of our third-party vendor assessment program.”

Today’s SBOMs are most often basic text files generated by a software developer when the creation of software is complete and a product is assembled (or application is created from source code.) The text file contains information about the product’s software components and subcomponents, where those components and subcomponents came from, and who owns them. But unlike a recipe used to make a pharmaceutical, for example, an SBOM also tracks the software versions of components and subcomponents. SBOMs often capture:

• Supplier Name
• Component Name
• Version of the Component
• Other Unique Identifiers
• Dependency Relationship
• Author of SBOM Data
• Timestamp

Here’s the format of a SBOM generated using the SPDX v2.2.1 standard:

Technology producers, decision makers, and operators in any industry can use this information to deeply understand the risks the products pose to patients and the health system. An SBOM, for example, can show a reader if the software used on a medical device is merely out of date, or vulnerable to a cyber attack that could affect its safe use.

Google sponsors a number of initiatives focused on securing the software supply chain, including how to use SBOMs, through our work with U.S. government agencies, the Open Source Security Foundation, and Linux Foundation, including a project focused on building and distributing SBOMs. Learn about the SPDX project and Cyclone DX, read the ISO/IEC 5962:2021 standard (for SPDX), ISO ISO/IEC 19770-2:2015 (for SWID; another artifact that provides a SBOM), and other training resources from the Linux Foundation.

As an additional measure, healthcare organizations which use SBOM need to make sure they can trust that the SBOMs they rely on haven’t been changed since the manufacturer produced it. To defend against this, software makers can cryptographically sign their SBOMs making it easier to identify if a SBOM has been maliciously altered since it was first published.

While U.S. Executive Order 14028 created a federal mandate for the SBOM, and although many organizations have begun to incorporate that mandate into their software production workflows, many issues and roadblocks remain unresolved. At Google, we think the use of SBOM will help organization’s gain important visibility into the technologies that are entering our healthcare facilities and enable defenders to more capably protect both patient safety and patient data privacy.

Digging into the SLSA

We believe resilient organizations have resilient software supply chains. Sadly no single mechanism, like SBOM, can achieve this outcome. It’s why we created the SLSA framework, and services like Assured Open Source Software. SLSA was developed following Google’s own practices for securing its software supply chain.

SLSA is guidance for securing software supply chains using a set of incremental, enforceable security guidelines that can automatically create auditable metadata. This metadata will then result in a “SLSA certification” to a particular package or build platform. It’s a verifiable way to assure consumers that the software they use hasn’t been tampered with, something which doesn’t exist broadly today. We’ve recently explained more about how the SLSA works in blog posts on SLSA basics and more in-depth SLSA details.

Similarly, Assured Open Source Software gives organizations the ability to use the same regularly tested and secured software packages Google uses to build its software. Used in combination with a SBOM, technology makers can build reliable, safe, and verifiable products. Most technology buyers, such as those who run your local healthcare system, can use those same mechanisms to gain visibility into a technologies’ safety and fitness for use.

Where do we go from here?

Visibility into the components that make up the technology we use to care for patients is critically necessary. We can’t build a resilient healthcare system if our only priority is privacy of data. We must add resilience and safety to the list of our top priorities. Gaining deep visibility into the technology that decorates health system networks is a critical shift we must make. SBOM and SLSA help us make this shift. But remember, it’s not one or the other. As Dan Walsh from VillageMD says, the SBOM has a way to go:.

“It won’t solve all of your problems,” he cautions, but adds that when used correctly, “SBOM will help you improve visibility into the software that runs on the critical systems that keep societies safe and we’re excited to see it get traction.”

But when complemented with SLSA and topics we’ll cover next, such as a Vulnerability eXploitability Exchange (VEX), we are on a path to greater resilience.