Towards Superior Cybersecurity: How SLSA and SBOM Help Build a Resilient Healthcare Industry

2941
Of your peers have already read this article.
3:30 Minutes
The most insightful time you'll spend today!
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.
Revamping Cloud Security: Google Introduces Attack Path Simulation to Security Command Center

1163
Of your peers have already read this article.
3:30 Minutes
The most insightful time you'll spend today!
To help secure increasingly complex and dynamic cloud environments, many security teams are turning to attack path analysis tools. These tools can enable them to better prioritize security findings and discover pathways that adversaries can exploit to access and compromise cloud assets such as virtual machines, databases, and storage buckets.
Other attack path tools rely on static, point-in-time snapshots of an organization’s cloud footprint, which often contain sensitive data about their environment, how it is configured, and where the most sensitive data resides.
At Google Cloud, we are taking a different approach. We are excited to announce today at the Google Cloud Security Summit that we are adding attack path simulation to Security Command Center, our built-in security and risk management solution for Google Cloud. This new risk management capability automatically analyzes a customer’s Google Cloud environment to pinpoint where and, importantly, how vulnerable resources may be attacked, so security teams can stay one step ahead of adversaries.
We expect attack path simulation capabilities to be available in Security Command Center Premium later this summer.
Unlike some third-party security products, Security Command Center continuously scans an organization’s cloud environment gathering near real-time data about cloud resources and security vulnerabilities. Our attack path simulation engine uses this information to automatically generate and render high-risk attack paths, without the hands-on toil of having to repeatedly run manual queries.
A different approach to attack path analysis
Other attack path analysis tools involve significant operational toil. The static, point-in-time snapshots that these tools generate have to be sent to an external provider, which can add risk. Then security teams have to follow up with complex queries before they can identify likely attack paths.
Google Cloud’s advanced attack simulation engine leverages our first-party, agentless visibility of Google Cloud assets, the relationships between assets, and the current state of defenses. Attack path simulation is fully automated with no need to manually run queries. Simulations run in the Google Cloud environment, and do not send snapshots outside your environment, avoiding exposure of sensitive information.
See what attackers can see
Effective attack path analysis should mimic how a real-world attacker can reach and compromise high value resources. This is why Security Command Center simulates how attackers try many different ways to infiltrate a cloud environment. SCC then generates attack path graphs to give defenders insight into how adversaries could exploit a single security weakness or various combinations of security vulnerabilities to access valuable assets. SCC also provides detailed information on how to remediate issues and shore up defenses based on its findings

We are delivering combined attack path simulation and analysis as a managed service. There are no agents to install or manage. Results automatically reflect changes in your organization’s Google Cloud environment. Because our attack path simulations are conducted on models of an organization’s cloud resources, there is no performance or operational impact to the live production environment.
Better security prioritization
Security Command Center automatically computes an attack exposure score for misconfigurations and vulnerabilities that expose valuable resources to attackers. The score is a measure of cyber risk. It takes into account how exposed valued resources are, and the paths of least resistance for attackers to reach those resources.
Security teams can use these scores to prioritize remediation efforts and improve their overall risk posture.

How attack path analysis has already reduced risk for customers
Dozens of customers have already used our attack path capabilities in private Preview to improve their security posture and reduce their operational risk.
Security Command Center alerted one customer to a finding with a high attack exposure score. The finding was related to a service account whose keys were not being rotated. After reviewing the attack paths related to this finding, the cloud security manager discovered that even though the service account was named “test,” it provided access to storage buckets outside of the test environment.
If an attacker had been able to steal the credentials for this test account, they could have easily accessed production data. The security manager removed administrator privileges on the account. The attack path simulation enhanced their understanding of the severity of the finding, and helped convince them to make it a high-priority fix.
Another customer using attack path simulation needed to assess which security findings created the greatest risk. Two findings related to the same service account with high exposure scores rose to the top of the list. The attack paths revealed that the service account had access to more than 500 storage buckets. If an attacker were to gain access to this account they would be able to read, write, or delete data across any of those buckets, many of which contained sensitive business data and confidential customer information.
Using Security Command Center’s attack path results, the security team remediated the risk by limiting permissions to the storage buckets needed for that specific role.
Next steps
Attack path simulation capabilities are planned for availability later this summer. We expect forthcoming enhancements to use Security AI Workbench to translate complex attack graphs to human-readable explanations of attack exposure, including impacted assets and recommended mitigations.
You can learn more about Nordnet Bank’s experience using attack path simulation at our Security Summit session. To get started with Security Command Center today, please go to the Google Cloud console.

3526
Of your peers have already downloaded this article
10:45 Minutes
The most insightful time you'll spend today!
In its 25-criterion evaluation of data security portfolio providers, Forrester identified the 13 most significant ones and researched, analyzed, and scored them.
Here’s a summary of what Forrester said about Google Cloud
- Google puts cloud and cloud security at the center of its strategy. Capabilities from Google Cloud Platform, G Suite, Cloud Security Command Center, G Suite Security Center, BeyondCorp, and more are a part of Google’s overall portfolio. There is support for hybrid environments (multi-cloud and on-premises) and use of open source models where it’s possible to enable integration and portability. Its tools are software-based, available in management console or via APIs, and enable organizations to ease into automation to scale data security efforts.
- Google supports a Zero Trust approach with its capabilities to identify data, map flows, encrypt, control access, and automate. Strengths include depth and granularity in access control and security data analytics. Weaknesses include user-driven data classification and file encryption. Customers appreciate Google’s ease of deployment and scalability of its capabilities. Google is a good fit for buyers whose infrastructure runs on Google Cloud and G Suite.
Download the report now!
Chrome OS’s Hybrid Work Model Powers Google’s Return to Work Strategy

7488
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
The pandemic continues to deeply affect our lives around the globe. In some places, new cases are surging and returning to work is the last thing on people’s minds. In other areas, conditions are improving and companies are starting to think about transitioning their workforce back to the office.
Exactly when and how to do this remains complex and varies by country, industry, and company. What’s certain is that hybrid work will become an essential part of the business world moving forward. And finding solutions that bridge the gap between “in-person” and “somewhere else” are crucial.
At Google, we’ve been focused on what the hybrid transformation means for us. To prepare for hybrid work, using modern solutions is a key enabler.
Chrome OS: Supporting Google’s return to office strategy
At Google, we’ll move to a hybrid work week where most Googlers spend approximately three days in the office and two days wherever they work best. It’s no surprise that as the modern, secure, cloud-first platform, Chrome OS is playing a key role in our transition to a hybrid work model. Because Chrome OS devices can easily be shared, more flexible working models and spaces are now possible. And with user profiles stored in the cloud and collaboration solutions like Google Workspace, employees can log in to any Chrome OS device, access what they need and pick up where they left off.
Here are just a few ways we are using Chrome OS and its tools to support the return to the office:
- In select office locations, Googlers can reserve desks through an internal booking tool set up with a high-performance Chromebox, keyboard, mouse, and monitor. Employees can log in to the Chromebox which syncs their cloud profile, and start working with the same environment they have on all their Chrome OS devices.
- We’re announcing new docking stations that are designed for Chrome OS devices and allow employees to bring in their Chromebook from home, connect to the dock with one USB-C cable, and use a monitor, keyboard, and mouse for a full desktop experience.
- Every Chrome OS device enables a zero-trust security working model with BeyondCorp Enterprise providing our workforce with simple and secure access to applications while providing additional security controls for IT.
- We’ve deployed the new Chrome OS Readiness Tool to our extended workforce to identify employees that are able to switch to Chrome OS. This allows us to expand the latest security, deployment, and manageability benefits to more of the workforce.
Additional ways Chrome OS is helping organizations with return to office
We aren’t the only ones supporting our return to office and hybrid work strategy with Chrome OS. We’ve heard more ways our customers are using Chrome OS to make the transition as smooth as possible. These include:
- Streamlining deployment and management of Chrome OS devices using zero-touch enrollment which allows devices to automatically enroll into a corporate domain without IT configuration.
Grab & Go Chromebooks being used for frontline and hybrid information workers, allowing employees to grab a Chromebook from a cart and get to work right away. - Parallels Desktop for Chrome OS being deployed to allow employees to access Windows or legacy apps locally on their Chrome OS devices.
- Existing Windows and Mac devices being modernized and repurposed to run a Chrome OS experience using CloudReady. (Google is currently offering a CloudReady promotion. Learn more here.)
While the Chrome OS team has been working towards making remote working as seamless as possible for IT, we’ve also made advancements in supporting traditional technology that’s required in the office.
- In October, we announced Chrome Enterprise Recommended: a collection of identity, printing, productivity, communications, and virtualization solutions that are verified to run great on Chrome OS.
- With the increased usage of video conferencing on Chrome OS devices, we’ve made improvements to Google Meet and Zoom performance including camera and video improvements to reduce any unnecessary processing and features that intelligently adapt to your device, your network, and what you are working on.
- For improved access to Windows and legacy apps, VMware Horizon introduced multi-monitor support and USB redirection and Citrix Workspace released a tech preview with webcam enhancements and Microsoft Teams optimizations.
- We integrated with the Okta Workflows platform, so IT administrators can include Chrome OS in it’s access logic and deploy quickly without code. Recently, we’ve added the ability to require users to reauthenticate on their Chrome OS device once Okta has detected that the user has changed their password. Try out this new capability by signing up for our Trusted Tester program.
- We’ve increased our support for direct IP printing with additional printer models since the beginning of 2020. In addition, we have made improvements to management features, including support for multiple print servers and launched policy APIs to provide a better IT admin experience.
Join us for a digital event with Modern Computing Alliance and its newest member HP
Last year we announced the launch of the Modern Computing Alliance—a collaboration of industry leaders including Box, Chrome Enterprise, Citrix, Dell, Google Workspace, Imprivata, Intel, Okta, RingCentral, Slack, VMware, and Zoom aim to create the pioneering solutions that businesses need. We are thrilled to introduce HP, who brings their innovative hardware and enterprise hardware expertise to the Modern Computing Alliance and has been working closely with the alliance to ensure true silicon-to-cloud innovation.
As an alliance, we’ve been deeply engaged in the hybrid work shift. We invite you to join us for a digital event where we discuss questions about returning to work. Like how product design can encourage participation and collaboration regardless of where employees are, important security issues to keep in mind, and what factors businesses should consider to support a safe, working environment.
Home. Heading back. Hybrid.
Hear from the experts on hybrid work and return to office.
Date: May 20th, 2021
Register here.
If you are ready to try Chrome OS today, it’s easy to get started. You can contact us to get connected to a partner, sign up for a free 30-day trial of Chrome Enterprise Upgrade to start managing Chrome OS devices, or deploy the Chrome OS Readiness Tool to identify employees that are ready to switch to Chrome OS.POSTED IN:
Conversations on Government Security with Dmitri Alperovitch, CrowdStrike’s Founder and Former CTO

4834
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
As I was preparing for my fireside chat with Dmitri Alperovitch, Founder and Former CTO of CrowdStrike and Executive Chairman of the Silverado Policy Accelerator, for the Google Cloud Government Security Summit taking place on Tuesday, July 20th, I was reflecting about recent developments in cybersecurity, Zero Trust best practices – including aspects of Google’s journey – and the benefits that this approach to cybersecurity brings to the public sector.
As Dmitri and I discussed what we wanted to share during our session at the Government Security Summit, I quickly realized how pertinent the information was to our public sector audience. For that reason, ahead of Tuesday’s event, I wanted to give you a glimpse of what is to come in our fireside chat. Read below for an exclusive preview of what we plan to discuss. If you are planning to attend on Tuesday, we encourage you to ask questions through our interactive chat function and sign up for 1:1 time with our Ask the Expert program.
Check out my chat with Dmitri below…
Heather: What do you see as the most significant changes in both the attack surface and cybercriminal tactics in recent years? And why do these changes present unprecedented challenges for public sector?
Dmitri: In terms of the threat landscape, the more things change, the more they stay the same. The adversaries haven’t changed that much. It’s actually striking. Not all threats are emanating from governments or state actors – either directly or by providing safe harbor to criminals – but a large portion are. That has not changed. The volume and scale of attacks have grown, however, and become massive. And now, the greatest challenge is that everyone is a target. Before, only top-end institutions and government organizations were facing nation state threats. That has changed either through targeted attacks or accidental ones, such as WannaCry. The question now is “How do we protect the most vulnerable and extend much-needed protection to smaller organizations that do not have deep security expertise or resources?”
Heather: Earlier this year, the Biden Administration released its Cybersecurity Executive Order (EO). What do you see as the most important takeaways and potential impact of the EO?
Dmitri: The Cybersecurity EO is set to have a significant impact. The biggest change is a shift in strategy. For many decades, we all had the mentality that we have to keep attackers out of the network. That is great in theory, but we all know that it is a virtual impossibility with a network of any significant size. Adversaries will find a way in. And, we used to think it was game over once they were in the network.
Then about 10 years ago, we began to see a change. Google led the way with its BeyondCorp strategy as did Lockheed Martin with its sentinel Kill Chain framework. Now, when an adversary penetrates a network, it’s not the end of the game, but the beginning. That is the case if the organization is prepared with a network architecture built around Zero Trust principles. The adversary now has to move laterally, steal credentials, and elevate privileges to get to the resources they want. A Zero Trust architecture can slow them down and give organizations time to detect and eject adversaries from the network. The EO recognizes the power of this approach and has made Zero Trust its fundamental tenet.
Heather: Federal agencies have spent the last 60 days looking at Zero Trust and developing their plans. What do you hope to see? What is critical to accelerating implementation?
Dmitri: The EO establishes a very ambitious timeline, and the US government is not known to move rapidly due to a number of restrictions and considerations. That said, the EO recognizes the idea that logging has to be at the center of modern architecture. Agencies need full visibility into what is going on at endpoints and across the network, have to hunt continuously across networks for adversaries, and must work to rapidly eject them. That is at the core of the EO, and it is a great shift. The private sector should be watching and learning as well.
Heather: What pitfalls should the Federal government look out for in moving forward to implement the EO?
Dmitri: One of the main challenges is the limited authority of the President. Congress is the only branch with the power to change the laws. While the establishment of the Cybersecurity and Infrastructure Security Agency (CISA) a few years ago allows for hunting across agency networks, CISA still has limited authority. It cannot manage the cybersecurity of more than 120 civilian agencies.
Some agencies are performing well when it comes to security, but we have to recognize that this is not the norm. Not all agencies have the capacity to recruit the best cybersecurity talent, but their needs may be just as great. We need to centralize capabilities and leverage the cloud, like Google, to provide all agencies with the best cyber talent and resources.
Join us at the Google Cloud Government Security Summit to hear the rest of our conversation. The event is complimentary. Register today to reserve your spot on July 20th. If you have any questions about the event, please reach out to us at cloudsummitsupport@google.com.
Aiming for successful cloud security transformations to help CISOs prepare for future threats

2949
Of your peers have already read this article.
3:30 Minutes
The most insightful time you'll spend today!
Many security leaders head into the cloud armed mostly with tools, practices, skills and ultimately the mental models for how security works that were developed on premise. This leads to cost and efficiency problems that can be solved by mapping their existing mental models to those of the cloud.
When it comes to understanding the differences between on-premises cybersecurity mental models and their cloud cybersecurity counterparts, a helpful place to start is by looking at the kinds of threats each one is attempting to block, detect, or investigate.
Traditional on-premise threats focused on stealing data from databases, file storage, and other corporate resources. The most common defenses of these resources rely on layers of network, endpoint, and sometimes application security controls. The proverbial “crown jewels” of corporate data were not made accessible with an API to the outside world or stored in publicly accessible storage buckets. Other threats aimed to disrupt operations or deploy malware for various purposes, ranging from outright data theft to holding data for ransom.
There are some threats that are specifically aimed at the cloud. Bad actors are always trying to take advantage of the ubiquitous nature of the cloud. One common cloud-centered attack vector that they pursue is constantly scanning IP address space for open storage buckets or internet-exposed compute resources.
As Gartner points out, securing the cloud requires significant changes in strategy from the approach we take to protect on-prem data centers. Processes, tools, and architectures need to be designed using cloud-native approaches to protect critical cloud deployments. And when you are in the early stages of cloud adoption, it’s critical for you to be aware of the division of security responsibilities between your cloud service provider and your organization to make sure you are less vulnerable to attacks targeting cloud resources.
Successful cloud security transformations can help better prepare CISOs for threats today, tomorrow, and beyond, but they require more than just a blueprint and a set of projects. CISOs and cybersecurity team leaders need to envision a new set of mental models for thinking about security, one that will require you to map your current security knowledge to cloud realities.
As a way to set the groundwork for this discussion, the cloud security transformation can start with a meaningful definition of what “cloud native” means. Cloud native is really an architecture that takes full advantage of the distributed, scalable, and flexible nature of the public cloud. (To be fair, the term implies that you need to be born in the cloud to be a native, but we’re not trying to be elitist about it. Perhaps a better term would be “cloud-focused” or doing the security “the cloudy way.”)
However we define it, adopting cloud is a way to maximize your focus on writing code, creating business value, and keeping your customers happy while taking advantage of cloud-native inherent properties—including security. One sure way to import legacy mistakes, some predating cloud by decades, into the future would be to merely lift-and-shift your current security tools and practices into the public cloud environment.
Going cloud-native means abstracting away many layers of infrastructure, whether it’s network servers, security appliances, or operating systems. It’s about using modern tools built for the cloud and built in the cloud. Another way to think about it: You’ll worry less about all these things because you’re going to build code on top of that to help you move more quickly. Abandoning legacy security hardware maintenance requirements is part of the win here. To put another way, security will follow in the steps of IT that has been transformed by the SRE and DevOps revolution.
You can extend this thinking to cloud native security, where some of your familiar tools combine with solutions provided by cloud service providers to take advantage of cloud native architecture to secure what’s built and launched in the cloud. While we talked about the differences between on-prem targeted threats compared to threats targeting cloud infrastructure, here are other vital areas to re-evaluate in terms of a cloud security mental model.
Network security
Some organizations practice network security in the cloud as if it were a rented data center. While many traditional practices that worked reasonably well on-premise for decades, along with many traditional network architectures, are either not applicable in the cloud or not optimal for cloud computing.
However, concepts like a demilitarized zone (DMZ) can be adapted to today’s cloud environments. For example, a more modern approach to DMZ would use microsegmentation and govern access by identity in context. Making sure that the right identity, in the right context, has access to the correct resource gives you strong control. Even if you get it wrong, microsegmentation can limit a breach blast radius.
Becoming cloud native also drives the adoption of new approaches to enterprise network security, such as BeyondProd. It also benefits organizations because it gets them away from traditional network perimeter security to focus on who and what can access your services—rather than where requests for access originated.
Although network security changes driven by cloud adoption can be enormous and transformational, not all areas shift in the same way.
Endpoint security
In the cloud, the concept of a security endpoint changes. Think of it this way: A virtual server is a server. But what about a container? What about microservices and SaaS? With software as a service cloud model, there’s no real endpoint there. All along your cloud security path, users only need to know what happens where.
Here is a helpful mental model translation: An API can be seen as sort of an endpoint. Some of the security thinking developed for endpoints applies to cloud APIs as well. Securing access, permissions, privileged access thinking can be carried over, but the concept of endpoint operating system maintenance does not.
Even with automation of service agents on virtual machines in the cloud, insecure agents may increase risks because they are operating at scale in the cloud. Case in point: This major Microsoft Azure cross-tenant vulnerability highlighted a new type of risk that wasn’t even on the radar of many of its customers.
In light of this, across the spectrum of endpoint security approaches, some disappear (such as patching operating systems for SaaS and PaaS), some survive (such as the need to secure privileged access,) and yet others are transformed.
Detection and response
With a move to the cloud comes changes to the threats you’ll face, and changes to how you detect and respond to them. This means that using on-prem detection technology and approaches as a foundation for future development may not work well. Copying all your on-premises detection tools and their threat detection content won’t reduce risks in the way that most cloud-first organizations will need..
Moving to the cloud provides the opportunity to rethink how you can achieve your security goals of confidentiality, integrity, availability, and reliability with the new opportunities created by cloud process and technology.
Cloud is distributed, often immutable, API-driven, automatically scalable, and centered on the identity layer and often contains ephemeral workloads created for a particular task. All these things combine to affect how you handle threat detection for the cloud environment and necessitate new detection methods and mechanisms.
There are six key domains where threats in the cloud can be best detected: identify, API, managed services, network, compute, and Kubernetes. These provide the coverage needed related to network, identity, compute, and container infrastructure. They also provide specific detection mechanisms for API access logs and network traffic captures.
As with endpoint security, some approaches become less important (such as network IDS on encrypted links), others can grow in importance (such as detecting access anomalies,) while others transform (such as detecting threats from the provider backplane).
Data security
The cloud is changing data security in significant ways, and that includes new ways of looking at data loss prevention, data encryption, data governance, and data access.
Cloud adoption sets you on a path to what we at Google call “autonomic data security.” Autonomic data security means security has been integrated throughout the data lifecycle and is improving over time. At the same time, it makes things easier on users, freeing them from having to define and redefine myriad rules about who can do what, when, and with which data. It lets you keep pace with constantly evolving cyberthreats and business changes, so you can keep your IT assets more secure and make your business decisions faster.
Similar to other categories, some data security approaches wane in importance or disappear (such as manual data classification at cloud scale), some retain their importance from on-prem to cloud unchanged, while others transform (such as pervasive encryption with effective and secure key management).
Identity and access management
The context for identity and access management (IAM) in the cloud is obviously different from your on-premise data center. In the cloud, every person and service has its own identity and you want to be able to control access.
Within the cloud, IAM gives you fine-grained access control and visibility for centrally managing cloud resources. Your administrators authorize who can act on specific resources, giving you full control and visibility to manage cloud resources centrally. What’s more, if you have complex organizational structures, hundreds of workgroups, and a multitude of projects, IAM gives you a unified view into security policy across your entire organization.
With identity and access management tools, you’re able to grant access to cloud resources at fine-grained levels, well beyond project-level access. You can create more granular access control policies to resources based on attributes like device security status, IP address, resource type, and date and time. These policies help ensure that the appropriate security controls are in place when granting access to cloud resources.
The concept of Zero Trust is strongly in play here. It’s the idea that implicit trust in any single component of a complex, interconnected system can create significant security risks. Instead, trust needs to be established via multiple mechanisms and continuously verified. To protect a cloud-native environment, a zero trust security framework requires all users to be authenticated, authorized, and validated for security configuration and posture before being granted or keeping access to cloud-based applications and data.
This means that IAM mental models from on premise security mostly survive, but a lot of underlying technology changes dramatically, and the importance of IAM in security grows significantly as well.
Shared fate for greater trust in cloud security
Clearly, cloud is much more than “someone else’s computer.” That’s why trust is such a critical component of your relationship with your chosen cloud service providers. Many cloud service providers acknowledge shared responsibility, meaning that they supply the underlying infrastructure but leave you responsible for many seemingly inscrutable security tasks.
With Google Cloud, we operate in a shared fate model for risk management in conjunction with our customers. We believe that it’s our responsibility to be active partners as our customers deploy securely on our platform, not delineators of where our responsibility ends. We stand with you from day one, helping you implement best practices for safely migrating to and operating in a trusted cloud.
Get ready to go cloud native
We offer you several great resources to help you prepare for cloud migration, and guide you as you review your current security approaches for signs of on-prem thinking.
Listen to our podcast series where Phil Venables, Vice President, CISO at Google Cloud, and
Nick Godfrey, Director, Financial Services Security & Compliance and member of Office of the CISO at Google Cloud, join me in a discussion on preparing for cloud migration (Podcast 1, Podcast 2). You can deepen your cloud native skills by earning a Professional Cloud Security Engineer certification from Google.
More Relevant Stories for Your Company

VCP Peering and Private Endpoints on Vertex AI to Better Security and Predictions in Near Real-time
One of the biggest challenges when serving machine learning models is delivering predictions in near real-time. Whether you’re a retailer generating recommendations for users shopping on your site, or a food service company estimating delivery time, being able to serve results with low latency is crucial. That’s why we’re excited

Google Cloud Leads the Landscape for Unstructured Data Security Platform: Forrester
As organizations expand their use of cloud computing services, more of their sensitive data inevitably moves to and lives in the cloud. Much of this sensitive data is unstructured and can be challenging to secure. Despite this potential challenge, the usefulness of cloud for data storage and processing is too

SEED: The 4 Areas of a Well-functioning and Responsible AI
The future of AI is better AI—designed with ethics and responsibility built in from the start. This means putting the brakes on AI-driven transformation until you have a well-functioning strategy and process in place to ensure your models deliver fair outcomes. Failing to recognize this imperative is a threat to

A Look Back on Google Cloud’s Data Analytics Development Efforts from June
June is the month that holds the summer solstice, and some of us in the northern hemisphere get to enjoy the longest days of sunshine out of the entire year. We used all the hours we could in June to deliver a flurry of new features across BigQuery, Dataflow, Data






