Today, we’re pleased to announce the general availability of Ubuntu Pro images on Google Cloud, providing customers with an improved Ubuntu experience, expanded security coverage, and integration with critical Google Cloud features. In partnership with Canonical, we’re making it even easier for customers that have fully embraced open source to ensure security and compliance for their most mission-critical and enterprise workloads.

With Ubuntu Pro on Google Cloud, you  now have access to features like:

• 10-year lifetime security updates – Canonical backs Ubuntu Pro for 10 years with security updates and a guaranteed upgrade path.
• FIPS & CC-EAL2 certification – Ubuntu Pro includes components that meet requirements from entities like FedRAMP, HIPAA, ISO, and PCI.
• Open-source security coverage – Protect your most important open-source workloads including MongoDB, Apache Kafka, Redis, NGINX, and PostgreSQL.
• Multi-version availability – Pro images are available for the three most popular Ubuntu Server distributions: 16.04 LTS, 18.04 LTS, and 20.04 LTS.
• Kernel Livepatch – Kernel patches are delivered immediately without having to reboot your VMs.
• Optional CIS and DISA STIG profiles – Choose from two leading profiles to harden your environment according to industry benchmarks.
• Cloud-based pricing – Ubuntu Pro does not require a contract, and pricing tracks with the underlying compute cost depending on the instance type.

Extended Security Maintenance (ESM) for Ubuntu 16.04 LTS with Ubuntu Pro

Availability of Ubuntu Pro images is especially important if you’re an Ubuntu 16.04 LTS customer and want extended security maintenance (ESM) for your virtual machines but don’t want to upgrade to Ubuntu 18.04 LTS or Ubuntu 20.04 LTS versions immediately. ESM is included with Ubuntu Pro 16.04. You can move your workloads from Ubuntu 16.04 LTS VM instances to Ubuntu Pro 16.04 instances to continue receiving ESM and all the above-mentioned benefits, without having to test your applications on a new version of the OS.

Gojek has evolved from offering just ride-hailing to a suite of more than 20 services today, serving everyday solutions for millions of users across Southeast Asia.

“We needed more time to comprehensively test and migrate our Ubuntu 16.04 LTS workloads to Ubuntu 20.04 LTS, which would mean stretching beyond the standard maintenance timelines for Ubuntu 16.04 LTS. With Ubuntu Pro on Google Cloud, we now have the ability to postpone this, and in moving our 16.04 workloads to Ubuntu Pro, we benefit from its live kernel patching and improved security coverage for our key open source components.”—Kartik Gupta, Engineering Manager for CI/CD & FinOps at Gojek

“With the launch of Ubuntu Pro on Google Cloud, we build on our joint investments with Google to optimize Ubuntu performance on Google Cloud, and add comprehensive security patching and Long Term Support for another 30,000 open source packages—the widest range of security-maintained open source on the planet,” said Mark Shuttleworth, CEO of Canonical. “As the world moves to open source for everything, Canonical offers the safety net of security maintenance that enterprises count on to unleash their developers.”

Getting started

Getting started with Ubuntu Pro on Google Cloud is simple. You can now purchase these premium images directly from Google Cloud by selecting Ubuntu Pro as the operating system straight from the Google Cloud Console.

To learn more about Ubuntu Pro on Google Cloud, please visit the documentation page and read the announcement from Canonical.

For more than a decade, Google has applied a Zero Trust approach to most aspects of our operations. Zero Trust’s core tenet–that implicit trust in any single component of a complex, interconnected system can create serious security risks–is fundamental to how we operate and build our security architecture.

Early in our security journey, we realized that despite our best efforts user credentials would periodically fall into the hands of malicious actors. This is why we developed the BeyondCorp framework. We needed additional layers of defense against unauthorized access that would not impede user productivity. We also understood that software that interacts with the larger world should not have a perimeter-based trust model. These realizations led to the layered protection in our BeyondProd framework, which extends the Zero Trust paradigm to our production workloads.

Earlier this year, the United States Office of Management and Budget (OMB) released a Federal Strategy to Move the U.S. Government Towards a Zero Trust Architecture. This marks an important step for the U.S. government’s efforts to modernize under Executive Order 14028 on Improving the Nation’s Cybersecurity. In parallel, guidance from the United Kingdom’s National Cyber Security Center (NCSC) has also called for the move to a Zero Trust approach to security and outlined in 2021 its report on Zero Trust architecture design principles.

Adopting a Zero Trust approach can help organizations inside and outside the public sector stay ahead of both regulatory requirements and security threats, but it requires thoughtful planning and execution. Our goal is to bring the best practices for Zero Trust together in one place, leveraging the experiences and knowledge of our existing customers, and Google’s own experience with implementing Zero Trust.

How Google Cloud can help government agencies move toward Zero Trust

Agencies can rely on Google Zero Trust capabilities for remote access, secure collaboration, and boundary security. To better serve the Zero Trust needs of our customers, we introduced BeyondCorp Enterprise in January 2021, a solution that provides Zero Trust secure access to resources and applications in the cloud and on-premises. BeyondCorp Enterprise was built based on years of Google’s own innovation as we implemented Zero Trust globally for ourselves. It leverages the Chrome browser and Google’s global network, and it offers integrated real-time threat and data protection.

Here are five ways BeyondCorp Enterprise can be applied to help organizations adopt the Zero Trust cybersecurity principles set forth in the recent White House memorandum (M-22-09) and other global government guidance for Zero Trust.

1. Enable enterprise applications to be used over the public internet: It’s no secret that VPN usage poses daily burdens and long-term challenges for IT and cybersecurity managers, as well as end-users. BeyondCorp Enterprise provides users with seamless and secure access to web applications (including SaaS apps and apps hosted on any cloud), plus central management controls and threat and data protection capabilities, all built-in to the Chrome browser. Through BeyondCorp Enterprise, end-users can access applications simply and still benefit from enterprise-grade security, without sacrificing their productivity or user experience.
2. Leverage phishing-resistant MFA to access secure resources: Many cyberattacks start with phishing messages that lead users to infected websites and attempt to steal credentials. The use of phishing-resistant MFA, as recommended by M-22-09, can protect personnel from sophisticated online attacks. BeyondCorp Enterprise supports strong phishing-resistant authentication, by allowing factors such as Titan Security Keys to be used as attributes in access policies that are enforced at the application layer. Organizations can customize how to incorporate phishing-resistant MFA methods into their access policies for individual applications and resources. Phishing protection is also built into the Chrome browser, powered by Google Safe Browsing, and these capabilities block access to malicious content, detect phishing sites, prevent malware transfers, and generate reports of unsafe activity, adding even more protection against bad actors.

3. Use context-aware authorization: The U.S. federal strategy states that a Zero Trust architecture should incorporate more granularly and dynamically defined permissions and that every request for access should be evaluated to determine whether it is appropriate. With context-aware authorization, organizations can build and customize access policies to include different contextual signals about a user including their role, their location, and even the time of day. Every interaction between a user and a BeyondCorp-protected resource is evaluated in real-time against the resource’s access policy to ensure users are and remain authorized to access it, with continuous authorization for all interactions at a per request level.
4. Incorporate device-level signal into authentication: At Google, we believe that trust must be granted based on what is known about a user’s identity and their device. We are pleased that OMB similarly recommends that authentication incorporate at least one device-level signal alongside identity information. Since BeyondCorp Enterprise supports device-level attributes without requiring users to install agents, this can be done easily by leveraging the Endpoint Verification extension in the Chrome browser, where administrators can gather endpoint security posture information and easily construct and implement granular resource access policies. The ability to collect and utilize this information through an agentless approach is especially helpful for BeyondCorp Enterprise customers who support a workforce with bring-your-own-device policies or unmanaged devices.
5. Include the extended workforce in your Zero Trust strategy: A Zero Trust approach aimed to provide secure access to the right users, at the right time, and for the right purposes should be inclusive of all users, not just full-time staff. Government agencies rely on contractors and partners to carry out many important missions. Unfortunately, the extended workforce is often more vulnerable to attacks if they are given too much privileged access or if their security practices are not properly assessed before access is provisioned. At the same time, federal administrators can’t always manage third-party devices or software directly, which can make secure access challenging.

BeyondCorp Enterprise supports a feature called protected profiles, an ideal solution for granting Zero Trust access to the extended workforce. It enables users to securely access resources from unmanaged devices and be protected by the same security capabilities without needing to install agents. Furthermore, administrators can gain visibility into risky activities and view any security events that are generated from within protected profiles.

Applying the NCSC Zero Trust principles on Google Cloud

Last year, the U.K. government’s NCSC launched its Zero Trust architecture design principles to help organizations securely adopt a Zero Trust architecture. To help private and public sector organizations in the U.K., the Google Cybersecurity Action Team (GCAT) released a detailed research paper that outlines how organizations can leverage Google Cloud technologies and services to align with these principles. This is a technical guide aimed at enterprise and security architects charged with developing and executing a Zero Trust strategy under the principles outlined by the NCSC, including:

• Know your architecture, including users, devices, services and data with Google Cloud Professional Services Organization (PSO) who can support discovery, planning and risk mitigation.
• Know your User, Service and Device identities including reference architectures for Cloud Identity.
• Assess your user behavior, device and service health by leveraging built in reporting from Google Cloud and Chronicle.
• Use policies to authorize requests with BeyondCorp Enterprise policy-based authorization.
• Authenticate & Authorize everywhere by reviewing the BeyondCorp and BeyondProd frameworks which combine to deliver ubiquitous authentication and authorization.
• Focus your monitoring on users, devices and services with device management and Cloud native monitoring capabilities.
• Don’t trust any network, including your own. Review details on Google’s Secure by Design infrastructure.
• Choose services designed for Zero Trust. Review how to protect modern and legacy applications with BeyondCorp.

For more detail on how we’re supporting the U.K.’s NCSC, please review our recent research paper for insight into their priorities, and where Google will be discussing Secure by Design principles and how to respond to security incidents.

Zero Trust assessment and planning services for organizations

Organizations that are managing complex environments while undergoing Zero Trust adoption could benefit strongly from experienced support and guidance. The Google Cybersecurity Action Team (GCAT) is committed to helping customers meet Zero Trust security and compliance requirements in the cloud through specialized consulting engagements and workshops for public sector customers. Read more about how growing cybersecurity requirements for U.S. federal government customers via executive orders and White House mandates are being supported through Google Cloud solutions.

GCAT’s multi-week Zero Trust Foundations engagement helps organizations build a strategy to achieve a Zero Trust security model across their operations. Zero Trust Foundations is co-delivered by Google Cloud’s Office of the CISO and our public sector Professional Services Organization. It can help focus and accelerate customers’ Zero Trust efforts by sharing lessons learned from Google’s own BeyondCorp zero-trust journey, and our global implementation of defense-in-depth best practices. Contact us today to learn more.

To learn more about ways Google Cloud can help organizations embarking on a Zero Trust journey, tune into our second annual Google Cloud Security Summit on May 17 and hear directly from customers who are already using our Zero Trust solutions to achieve their organization’s security goals.

About the Authors:
Jeanette Manfra is the former Assistant Director for the Cybersecurity and Infrastructure Security Agency at the Department of Homeland Security. Dan Prieto is the former Director of the Defense Industrial Base Cybersecurity program at the Department of Defense. Both Dan and Jeanette also served in the White House on the staff of the National Security Council’s cybersecurity directorate.

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.

When technology just works, it’s easy to trust. But too often, we place our trust in technology that doesn’t deserve it. When we do this with technology to provide healthcare, we put the safety of patients and the security and reliability of our global healthcare system at risk.

The institutions that make up our global healthcare system also place their trust in cybersecurity measures and technology to keep their systems running and repelling the unceasing wave of attacks they face. We often hear about the institutions that succumb to cyberattacks, but we don’t read much about the institutions that have been successful at defending their digital perimeter, and ultimately protected their ability to treat and protect patients.

Why were some institutions successful and others not as much? What cybersecurity capabilities made the healthcare institution resilient from these attacks? As we covered in our previous post on how healthcare can strengthen its cybersecurity resilience, establishing visibility and antifragility practices are necessary to repel attackers and build trust in the security and reliability of the technology our global healthcare system relies on.

As we continue our series on healthcare and cybersecurity, we’ll focus next on establishing sustainable visibility mechanisms so cybersecurity teams working in our global healthcare system can secure and preserve patient care and safety.

Visibility is akin to a patient taking 20 different medications but their doctor only knows about 10 of them. That’s the current state of many healthcare organizations’ relationship to the technology used on their networks and systems: They aren’t always aware of what technology is in use, whether it has vulnerabilities, how serious those vulnerabilities are, or how one weakness could lead to another or cascade out of control.

Visibility maps those technology assets (including the software, hardware, configurations, protections, who built it, and where the component parts come from) and help prioritize the importance of those assets in keeping systems and networks secure, no matter how complex the healthcare organization’s use of technology might be.

Building effective visibility

Building visibility into technology assets requires a structured approach. As mentioned in the first blog in this series, using a guide like the NIST Cybersecurity Framework (CSF) provides an important mental model we can use to get a clear picture of the strengths and weaknesses of an organization’s cybersecurity risk profile, and how it applies to the assets the organization seeks to protect.

Cybersecurity author and leader Sounil Yu’s book Cyber Defense Matrix provides an important interpretation of the NIST CSF framework that can help us better understand what visibility we have into technology assets and how they are protected. Visibility is about more than just seeing all assets we have all at once. It’s also about understanding which assets are mission-critical and must be protected at all costs versus which ones are perhaps important but less crucial overall. Without the right balance, we end up trying to protect everything while not protecting what matters enough. This is where structural awareness comes in.

Structural awareness, or the conscious understanding and state of an organization’s assets, is established as one implements controls captured in the NIST CSF functions Identify and Protect. These controls focus on identifying assets, their bill of materials, their creators, their dependencies on other assets, the protections and vulnerabilities they have, and the threats they face. While visibility helps create an accurate map of technology assets, structural awareness builds on that visibility and answers questions such as, “What are the ways the threat actor could compromise that asset? What could be lost? How would it most likely happen? Would I know?”

Yu says that structural awareness is efficiently achieved with the help of automation, and is not as people-intensive as many practitioners, decision-makers, and executives might think. If a cyberattack is like an explosion, cybersecurity teams’ structural awareness helps them understand how the explosion could happen before (or ‘left of’) it goes ‘boom’.

It’s also important to remember that while structural awareness is related to situational awareness in some ways, they are different concepts. Situational awareness refers to mechanisms that are used to detect and respond to an event. Structural awareness mechanisms are ‘left of boom,’ or mechanisms that protect your assets so that events don’t happen. The goal is to stay ‘left of boom’ and avoid being ‘right of boom’. Being proactive in your protections and being ready to respond in either case is really important, nonetheless.

Thinking about assets in terms of users, devices, networks, applications and workloads and data (asset classes), and adopting mechanisms to discover assets of each type through visibility controls suggested by the NIST CSF, will lead to developing structural awareness. Structural awareness can help avoid the boom, but if the boom does happen, it can also help shape the situational awareness needed to react. The Cyber Defense Matrix is an ongoing project, and you can read more about it (and contribute to it) here.

Framing asset discovery for resilience

Cybersecurity teams must map out their organizations’ most critical healthcare services and systems that support them, but that’s easier said than done. Asset discovery can feel overwhelming. Trying to find, count, and audit the hardware, software, users, and data down to the component across even a small part of one’s technology footprint can feel like pushing a dead car up a steep hill. The way to make this easier is to prioritize this effort in the parts of the business where the impact of a quality or safety issue has the potential to create the most harm to the organization and those who depend on it.

A smart place to begin the process to find and evaluate the measurements that an institution uses to monitor those processes.

Healthcare providers: Start with the quality and safety measurements which must be submitted to various regulatory agencies in order to maintain licenses to operate.

• Health insurers: Look at the performance improvement metrics used to ensure subscriber benefits, quality requirements, and legal mandates are being met.
• Health IT services: Use service level agreements for measuring contract compliance with things like uptime, recovery time and point objectives, and response turnarounds.
• Life sciences organizations: Begin with the relevant Good Practice definitions and the metrics used to monitor quality and safety levels of products and services.

When analyzing the types of technology unique to healthcare – like network-connected medical devices such as infusion pumps, implantable pacemakers, ventilators, EKG equipment, and MRI machines – it’s important to ask what are the immediate safety hazards if there was a cyberattack. Not sure how to answer that question? The International Medical Device Regulators Forum produced a risk categorization model that could be helpful in framing that response. Operational technology, like blood bank and sample refrigerators, climate control, air handling, infection control and pneumatic tube systems, may also be used to identify and prioritize inventory efforts.

Once priorities have been set, teams can begin gathering data on critical services, the owners of those services, the systems those owners rely on, and the technology itself.

Inventory tactics on Google Cloud

Building service-technology mapping is not a one-time exercise. Organizations should take the time to automate inventory creation and maintenance, so they can maintain an up-to-date view of all the items in their environment at any given time. This is especially for organizations that have highly dynamic environments.

Google Cloud provides best practices on discovering and cataloging assets in its Cloud Architecture Center. Implement controls found in the Identity and Protect categories using the NIST Framework & Google Cloud technical paper. Automation is your friend when building and maintaining a complete and accurate inventory. Google Cloud Asset Inventory and Security Command Center can be used to inventory a variety of resources running in Google Cloud. Cloud Build, Google Cloud’s CI/CD platform, implements SLSA 1 and provides a trustworthy audit of software artifacts deployed through a managed pipeline. Cloud DLP inventories and labels data stored on Google Cloud Storage and services like BigQuery.

Meanwhile, a number of Google Cloud Marketplace partners have solutions that can help build a comprehensive inventory, and innovation continues to improve our technological options. One emerging field of security technology, called attack surface management, helps discover previously-unknown assets. Finally, our next blog on resilience discusses how to use a software bill of materials (also known by the breezy acronym SBOM) to gain visibility and structural awareness into applications.

It’s important to remember that when starting down this path, the goal is not to gain 100% visibility into every single component on every single device attached to every network supporting every service running. Success or failure is not achieved when the inventory process has reached an arbitrarily-determined ‘percentage complete.’ We want to prioritize expanding visibility and developing structural awareness on assets where safety and quality are at risk, so we can improve their resilience.

And finally, we feel it’s important to emphasize that in the past, healthcare industries have focused mainly on protecting the confidentiality of data. While that’s important, we must evolve security programs beyond protecting confidentiality as its primary (and some cases, only) focus.

To be resilient, we must design and build cybersecurity capabilities that deliver safety, integrity, and availability of the technology that cares for patients directly. As we gain visibility into the technology we depend on to keep us healthy, we improve our understanding about which parts of it we can trust, and which parts we can’t. Improving visibility is an important early step on our path to resilience.