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.

As the way people work continues to evolve, keeping security policies in place that protect organizations but give workers the ability to get things done is more important than ever. IT and security teams must aim to stay a step ahead of web-based security threats that come their organization’s way. To help, the Center for Internet Security (CIS) team has released the latest CIS Benchmark 2.1 for Google Chrome. This Benchmark offers independent recommendations on which Chrome policies to configure to help support organizations’ security and compliance needs. Thanks to Chrome being built with security at its core, in many cases, Chrome default settings are aligned with CIS recommendations.

Chrome is secure by default, but we also pride ourselves on providing customizations for enterprises to allow Chrome to better fit the needs of their business. And with hundreds of policies available through Chrome Browser Cloud Management and Group Policy Objects (Note: The CIS Benchmark is also available as a GPO), organizations can do just that. 

Throughout the CIS guide you’ll notice that there are different designations for configuration profiles. Any labeled Level 1, are considered to be a good baseline for an organization. Level 2 profiles are recommended for deployments that require the highest level of security, but note that these settings could have a trade off on user productivity. We recommend looking at each setting and determining if it’s a good fit for your business. 

The benchmark is made up of five sections:

• Enforced Defaults — Notes policies that are configured by default when you install Chrome. Enforcing these settings at an enterprise level can prevent these settings from being changed by business users to less secure options.
• Attack Surface Reduction — Details how to disable web features that may not be necessary in your enterprise environment and could reduce your overall attack surface.
• Privacy — Surfaces settings that improve user privacy.
• Data Loss Prevention — Contains settings that can help prevent data loss and protect your organization’s data. (Note: These recommendations cover additional capabilities that can be added to Chrome through BeyondCorp Enterprise). 
• Forensics (Post Incident) — Shares recommendations on policies that give insights into post incident forensics and analysis. 

Organizations can use these benchmarks to optimize the best way to secure Chrome in their environment. Download the CIS Benchmark here and check out our team’s configuration guide for additional recommendations on how to configure Chrome.

Note: This benchmark was created using a consensus review process composed of subject matter experts. Consensus participants provide perspective from a diverse set of backgrounds such as consulting, software development, audit and compliance, security  research, operations, government, and legal. While these recommendations come from a trusted source, it’s important for each organization to weigh which policies make the most sense for their business.

Over the past decade, cybersecurity has posed an increasing risk for organizations. In fact, cyber incidents topped the recent Allianz Risk Barometer for only the second time in the survey’s history. The challenges in combating these risks only continue to grow. Adversaries tend to be agile and are consistently looking for new ways to land within your digital environments. They also drive attack vectors that work, which means enterprise risk leaders are now forced to look for new ways of securing infrastructure and data.

Cloud comes of age in the modern day cybersecurity threat landscape

When cloud, in its various delivery models, was first introduced, it didn’t fit neatly into the security frameworks that had seemingly protected networks for many decades. Public cloud was the answer to ongoing IT challenges: scale, resources, security capabilities, and budget cycle limitations. Now, public cloud is meeting the increasing challenge of implementing cybersecurity controls and frameworks that are capable of protecting today’s global enterprise.

Cloud adoption – with all its scale and redistribution of longstanding security paradigms – is the optimal choice for infrastructure and security, particularly as organizations grapple with the need to engage in digital transformation. We assert that successful digital transformation is impossible without incorporating the use of the scale, security architecture, and resiliency of the cloud.

Consequently, cloud adoption becomes a necessary component of roadmap discussions and planning as your organization looks to reduce overall risk. Risk leaders and enterprise cybersecurity leaders must consider that moving data, digital processes, and priority workloads to the public cloud is a crucial step for meeting the current and future digital needs of the enterprise. Going forward, this digital transformation increasingly will include hybrid infrastructure environments composed of a combination of on-premises and cloud solutions.

Pinpointing where threats thrive

As digital environments become more complex within a given organization, proactively countering adversaries becomes all the more difficult. It’s harder to implement, scale, and adhere to existing security and control frameworks. It’s also increasingly challenging to apply framework guidance to new applications, build and support infrastructure within a secure foundation, and maintain good cyber hygiene through the digital lifecycle.

As reported by TechTarget, the 2020 hack of the SolarWinds Orion IT performance monitoring system is a prime example. It grabbed headlines “not because a single company was breached, but because it triggered a much larger software supply chain incident.” This vulnerability in popular, commercially available, and widely utilized software compromised the data, networks, and systems of thousands of companies when a routine software update turned out to be backdoor malware.

A close look at the root problems behind high-profile security breaches reveals that it’s a lack of agility and an inability to scale resources that prohibit the modern security organization’s ability to respond quickly enough to counter new challenges. Look even closer and you’ll often find an insufficient implementation of best practices and ineffective solutions, leaving an organization continually chasing the next tool or solution and scrambling to stay ahead of emerging threats.

While the cost to individual businesses is high, most organizations struggle with the needed skills and resources to rigorously maintain data security basics and ensure readiness for inevitable attacks. The previous sentence is especially true when you consider that maintaining an effective state of cybersecurity readiness is a costly practice that requires the continual development of expertise, the evaluation of new tools, and an ongoing element of vigilance.

Threat visibility is a big part of the problem. You can’t protect your company from what you can’t see. For individual enterprises – with critical data workloads housed in a combination of on-premises servers, a variety of endpoints, and both private and public cloud instances – staying ahead in the ongoing battle requires a new approach.

The identification of actionable alerts and other data contributes to a better overall state of readiness. Thought leadership and discussions related to Autonomic Security Operations provide a promising outlook for security organizations willing to lean into the changing technology landscape – a landscape that now benefits from leveraging automation and machine learning currently used in security stacks. Reducing the chance of introducing vulnerabilities or missing-critical alerts starts with ensuring full visibility into an increasingly expanding and complex environment.

The evolution of a shared responsibility to a shared fate

Industry megatrends are driving cloud adoption and with it a path to improved cybersecurity. Among these trends is the concept of shared fate as an evolution of the historical shared-responsibility model. Shared fate drives a flywheel of increasing trust which develops as more enterprises transition to the cloud. This compels an even higher security investment and a more vested interest from cloud service providers.

At Google Cloud, shared fate means we take an active stake in our customers’ security posture, offering capabilities and defaults that help ensure secure deployments and configurations in the public cloud. We also offer experience-based guidance on how to configure cloud workloads for security, and can assist with risk management, reduction, and transfer.

The Google Cloud Risk Protection Program represents the continuing evolution of the shared-fate model. The program offers a practical solution that provides the modern enterprise a snapshot comparison of its current security state against well-adopted cloud-security frameworks. It also give you an opportunity to explore cyber insurance designed to meet your needs from our partners Allianz and Munich Re.

When performed with diligence, cloud adoption can help increase your overall cybersecurity effectiveness. Using a hybrid approach – and steadily reducing which data assets remain on premises – can strengthen your overall security posture and reduce risks to the organization.

Cloud security and the ability to reduce risk

In comparison to the enterprise-by-enterprise security scramble to protect data and workloads in individual private clouds, global public cloud solutions like Google Cloud can be a force multiplier when adhering to established best practices. By that, we mean, quite literally, that you get more security at every touchpoint – from infrastructure and software to access and data security.

Strong security in the public cloud starts with the foundational pieces: the hardware and design elements. At Google, for example, we take a security-by-design approach within both the data center and purpose-built components themselves. Within Google Cloud, data is encrypted by default – both at rest and in transit. Google’s baseline security architecture adheres to the zero trust principles, meaning that every network, device, person, or service initially cannot be trusted.

Embarking on a zero trust architecture journey gives modern security practitioners the ability to methodically shut down traditional attack vectors. Zero trust also provides more granular visibility and control of rapidly expanding environments. The recent emphasis of its benefits, as the U.S. White House set forth through an executive order on increasing cybersecurity resilience, is an example of the wide-scale recognition by both government and industry on the benefits of this approach.

Since adopting a zero trust approach more than a decade ago, Google has achieved a recognizable level of maturity, reflected by our internal infrastructure and multiple enterprise offerings, enabling different aspects of the zero trust security journey.

Compliance and privacy drive critical elements of the cloud adoption cycle

Privacy frameworks, regulatory compliance, and data sovereignty are driving critical elements of the cloud adoption cycle. Cloud providers must ensure they have the necessary controls, attestations, and abilities to audit in order to provide organizations with the tools to preemptively satisfy regulatory and compliance mandates across the globe.

Now consistently expected to be part of a design feature that’s built into the cloud journey, it cannot simply be an add-on capability. The direction of this evolution promises to play more of a role in the future of cloud adoption, not less. Because this is an ongoing component of enterprise risk evaluation, your business must consider cloud providers that can partner on this critical aspect of the journey – and not leave you without the resources to respond to this growing critical need.

Building trust into your digital transformation journey

Digital transformation is difficult because the modern enterprise must build and design for both today and tomorrow. From a security perspective, the challenge has often been that security industry practitioners cannot always predict what the future will look like. That said, there are clear steps you can take to mitigate all-around risk throughout the process.

How you approach the cloud is, of course, integral to your journey, but it doesn’t need to be an all-or-nothing proposition. And although technology debt continues to persist with legacy systems, that doesn’t mean you shouldn’t begin to move forward.

Google Cloud enables you to modernize at your own pace and understand what’s realistic. We recommend you move what data you can to a more secure public cloud today, followed by a phased approach to move more in the months and years that follow. The key tenets of our approach to security in the public cloud include:

• The security-by-design posture of Google Cloud can help modern-day enterprises scale security capabilities and reduce risk with an architecture built on zero trust principles.
• The Google Cloud approach to security and resiliency includes a framework to help you protect against adverse cyber events by using our comprehensive suite of solutions.
• Google Cloud can help ensure your organization adheres to the requirements of a growing and increasingly complex regulatory and compliance environment.
• The ideal model of a future organization is one where cloud plays a major role in infrastructure design and architecture. Your organization should begin to view public cloud as an enabler of the business and a core component of digital transformation.

As you transition more data to the public cloud, it’s paramount that trust is ingrained in every step you take with your cloud service provider. Many service providers readily take on a shared responsibility with your organization when it comes to security. At Google, we take it several steps further with our shared fate model to help ensure data security in the public cloud. Your future and our’s are part of the same data security journey.

We’re excited to announce the public preview of Certificate Manager and its integration with External HTTPS Load Balancing. Certificate Manager enables you to use External HTTPS Load Balancing with as many certificates or domains as you need. You can bring your own TLS certificates and keys if you have an existing certificate lifecycle management solution you’d like to use with Google Cloud, or enjoy the convenience of our fully Managed TLS offerings.  

Extend the security and performance of the Google network to your customers

Certificate Manager brings support for multiple certificates per customer. When  coupled with our global anycast load balancing solution with automated autoscaling and failover, you now have a powerful platform for building robust SaaS and PaaS offerings. This enables custom domain support for your customers with the lowest latency and the highest level of availability. 

Alon Kochba, the head of web performance at website-building service Wix, explained how the new features lighten their workload. 

“As a SaaS product, we need to terminate SSL for millions of custom domains and certificates. GCP’s Certificate Manager and External HTTPS Load Balancing lets us do this at the edge, close to the clients, without having to rely on our own custom solution for terminating SSL,” Kochba said.

Customers who switch to External HTTPS Load Balancing can also now protect their SaaS users from denial of service attacks, OWASP Top 10 risks, and other common Web attacks by adopting Cloud Armor.

DNS authorization

This release also now enables you to provision your Google-managed certificates with DNS-based authorizations and have them ready to use before your load-balancing production environment is fully set up. This will help streamline the migration process to Google Cloud, for example. To create a DNS authorization, use the following command:

  gcloud beta certificate-manager dns-authorizations create example-authorization --domain="example.com"

This command returns the CNAME record for _acme-challenge.example.com that you must add to your DNS configuration in the DNS zone of the target domain. This CNAME record points to a special Google Cloud domain, e.g.: “534959-1a8a-40cf-90b6-b1f5f8d22517.2.authorize.certificatemanager.goog” that is used  to verify domain ownership.

When you request a certificate based on the above authorization, Cloud Certificate Manager will work with the Certificate Authority automatically to get and later renew your certificate for that domain.

Wildcard support

This DNS-based domain control authorization also allows us to bring you support for wildcard certificates. To configure the use of wildcard certificates you first must configure the DNS authorization as we’ve indicated above. Once that has been completed, you can configure the use of a wildcard certificate using the following command. Our example below is for a top-level registered domain and its wildcard subdomains.

  gcloud beta certificate-manager certificates create example-wildcard-certificate --domains="example.com,*.example.com" --dns-authorizations="example-authorization"

Monitoring for Certificate Expiration

Another new feature that will be enabled with this product  is the ability to monitor certificate expiration with Google Cloud Logging.  Cloud Logging creates a record of certificate expiration, uses the `certificatemanager.googleapis.com/Project` monitored resource, and is represented by the following message:

  message CertificatesExpiry {
  // Expiration state of the certificate.
  enum State {
    // Unspecified state, should never be reported.
    STATE_UNSPECIFIED = 0;

    // Certificate will expire soon.
    CLOSE_TO_EXPIRY = 1;
    // Certificate is expired.
    EXPIRED = 2;
  }

  // Number of reported certificates.
  int64 count;

  // Names of reported certificates. If there are too many, the list is sampled.
  repeated string certificates = 2;

  // State of reported certificates.
  State state = 3;

  // Approximate expiration time of reported certificates.
  // Multiple certificates with close expiration time are batched 
  // together in a single log, so the timestamp is not precise.
  google.protobuf.Timestamp expire_time = 4;
}

The log message is delivered every hour and contains a sample of the certificates being close to expiry or already expired.

Pricing

The best part is that there’s no additional charge to use the Certificate Manager for the first 100 certificates. To use more than 100 certificates with the management tools, we will charge on a per-certificate, per-month pricing structure. This empowers you to scale up to as many certificates as you need, and as cost-effectively as possible. The pricing will be enabled when the solution goes to General Availability.

It is our hope that these new features, combined with the programmability offered by Certificate Manager, will enable you to simplify the way you deploy HTTPS and offer a more scalable and secure service to your customers.