Whether they were ready for it or not, the COVID-19 pandemic transformed many retailers into digital businesses. Retailers made huge investments into commerce technologies, customer experience tools, sales and fulfillment technology, and improving digital experiences to continue providing their goods and services to their customers. Now, more than a year into the COVID-19 pandemic, digital retail is the new normal. In fact, many retailers are planning on expanding their digital investments. However, as their digital footprint expands, so do their threats and security concerns. 

As a digital-focused retailer, your website is the most visible part of your attack surface. Your website is where your customers search for goods or services, make payments, or learn more about your brand. However, your website does not operate in isolation. There is an underlying infrastructure as well as the services that run on top of it that need protection from a wide array of attacks that may seek to compromise your data, internal employees, business, and customers. During this week’s Google Cloud Retail Summit, we’ve shared why Google Cloud is built to be the most trusted cloud for retailers. From providing you with control over your data as you move from your own data centers to the public cloud to giving you built-in technology to protect your applications all the way to your end users, Google Cloud helps you safely migrate to and operate in our Trusted Cloud.

Trusted Cloud Gives You Control, Transparency, and Sovereignty

• Access Transparency: We offer the ability to monitor and approve access to your data or configurations by Google Cloud support and engineering based on specific justifications and context, so you have visibility and control over insider access. 
• Certificate Authority Service (CAS): CAS is a highly scalable and available service that simplifies and automates the management and deployment of private CAs while meeting the needs of modern developers and applications. With CAS, you can offload to the cloud time-consuming tasks associated with operating a private CA, like hardware provisioning, infrastructure security, software deployment, high-availability configuration, disaster recovery, backups, and more, allowing you to stand up a private CA in minutes, rather than the months it might normally take to deploy.

• Confidential Computing: We already encrypt data at-rest and in-transit, but customer data needs to be decrypted for processing. Confidential Computing is a breakthrough technology which encrypts data in-use—while it’s being processed. Confidential VMs take this technology to the next level by offering memory encryption so that you can further isolate your workloads in the cloud. With the beta launch of Confidential VMs, we’re the first major cloud provider to offer this level of security and isolation while giving you a simple, easy-to-use option for your newly built and “lift and shift” applications.

• Cloud Key Management: We allow you to configure the locations where your data is stored, where your encryption keys are stored, and where your data can be accessed from. We give you the ability to manage your own encryption keys, even storing them outside Google’s infrastructure. Using our External Key Management service, you have the ability to deny any request by Google to access encryption keys necessary to decrypt customer data at rest for any reason.

Trusted cloud Helps You Prevent, Detect, and Respond to Threats

• BeyondCorp Enterprise is Google’s comprehensive zero trust product offering. Google has over a decade of experience managing and securing cloud applications at a global scale, and this offering was developed based on learnings from our experience managing our own enterprise, feedback from customers and partners, as well as informed by leading engineering and security research. We understand that most customers host resources across different cloud providers. With this in mind, BeyondCorp Enterprise was purpose-built as a multicloud solution, enabling customers to securely access resources hosted not only on Google Cloud or on-premises, but also across other clouds such as Azure and Amazon Web Services (AWS).

• Cloud Armor: We’re simplifying how you can use Cloud Armor to help protect your websites and applications from exploit attempts, as well as Distributed Denial of Service (DDoS) attacks. With Cloud Armor Managed Protection Plus, you will get access to DDoS and WAF services, curated rule sets, and other services for a predictable monthly price.

• Chronicle: Chronicle is a threat detection solution that identifies threats, including ransomware, at unparalleled speed and scale. Google Cloud Threat Intelligence for Chronicle surfaces highly actionable threats based on Google’s collective insight and research into Internet-based threats. Threat Intel for Chronicle allows you to focus on real threats in the environment and accelerate your response time.
• Google Workspace Security: Used by more than five million organizations worldwide, from large banks and retailers with hundreds of thousands of people to fast-growing startups, Google Workspace and Google Workspace for Education include the collaboration and productivity tools found here. Google Workspace and Google Workspace for Education are designed to help teams work together securely in new, more efficient ways, no matter where members are located or what device they use. For instance, Gmail scans over 300 billion attachments for malware every week and prevents more than 99.9% of spam, phishing, and malware from reaching users. We’re committed to protecting against security 1 threats of all kinds, innovating new security tools for users and admins, and providing our customers with a secure cloud service.
• Identity & Access Management IAM: Identity and Access Management (IAM) lets administrators authorize who can take action on specific resources, giving you full control and visibility to manage Google Cloud resources centrally. For enterprises with complex organizational structures, hundreds of workgroups, and many projects, IAM provides a unified view into security policy across your entire organization, with built-in auditing to ease compliance processes.
• reCAPTCHA Enterprise: reCAPTCHA has over a decade of experience defending the internet and data for its network of more than 5 million sites. reCAPTCHA Enterprise builds on this technology with capabilities, such as two-factor authentication and mobile application support, designed specifically for enterprise security concerns. With reCAPTCHA Enterprise, you can defend your website against common web-based attacks like credential stuffing, account takeovers, and scraping and help prevent costly exploits from malicious human and automated actors. And, just like reCAPTCHA v3, reCAPTCHA Enterprise will never interrupt your users with a challenge, so you can run it on all webpages where your customers interact with your services.

• Security Command Center: With Security Command Center (SCC), our native posture management platform, you can prevent and detect abuse of your cloud resources, centralize security findings from Google Cloud services and partner products, and detect common misconfigurations, all in one easy-to-use platform. We have Premium tier for Security Command Center to provide even more tools to protect your cloud resources. It adds new capabilities that let you spot threats using Google intelligence for events in Google Cloud Platform (GCP) logs and containers, surface large sets of misconfigurations, perform automated compliance scanning and reporting. These features help you understand your risks on Google Cloud, verify that you’ve configured your resources properly and safely, and document it for anyone who asks.

• VirusTotal: VirusTotal inspects items with over 70 antivirus scanners and URL/domain blocklisting services, in addition to a myriad of tools to extract signals from the studied content. Any user can select a file from their computer using their browser and send it to VirusTotal.
• Web Risk API: With Web Risk, you can quickly identify known bad sites, warn users before they click infected links, and prevent users from posting links to known infected pages from your site. Web Risk includes data on more than a million unsafe URLs and stays up to date by examining billions of URLs each day.

Trusted cloud Plays an Active Role in Our Shared Fate 

Our trusted cloud provides a shared-fate model for risk management. We stand with retailers from day one, helping them implement best practices for safely migrating to and operating in our trusted cloud.

We hope you enjoy the sessions we’ve created for you with Google Cloud Retail Summit and that they help you understand the ways our trusted cloud can help secure retailers all over the world.

In May, the White House issued an Executive Order aiming to improve the nation’s cybersecurity defenses and requiring US Federal agencies to develop plans to implement Zero Trust architectures in alignment with National Institute of Standards and Technology National Institute of Standards and Technology (NIST) guidance. This Executive Order also calls on agencies to accelerate cloud adoption, with a preference for cloud capabilities that implement or advance the adoption of Zero Trust. 

Zero Trust moves front and center 

The White House guidance is timely and necessary given the surge of ransomware and other cyber attacks over the past year targeting remote workers and VPNs, software supply chains, identity infrastructure and email, and various critical infrastructure sectors. These attacks have raised concerns about cyber-risk across the board, including pervasive IT monocultures that persist, unquestioned, despite their exploitability by attackers. 

This order ties together multiple strands of US cybersecurity best practices and policy that have evolved over the past decade, including stronger identity and access controls, expanded use of encryption and authentication, increased monitoring and visibility, and prioritizing high-value IT assets. Yet the urgent challenge of cybersecurity requires more than simply adding to the existing proliferation of cyber tools or ratcheting up traditional measures around hygiene and compliance. The Administration’s focus on Zero Trust marks a critical shift to prioritizing architectures in which the strategic coordination of layered cyber defenses drives improved cyber outcomes.  

In many ways then, the demand for accelerating the adoption of Zero Trust in federal IT is not a new requirement, as departments and agencies are already implementing many of the core technical components that can contribute to achieving the goals laid out in the executive order.  

What is new, however, is the fact that Zero Trust, when done right, is primarily an outcomes-oriented approach to security. Successfully implementing Zero Trust can drive down cyber risk, transform the daily security experience of users, reduce management complexity and toil for IT managers, and improve the overall productivity of the workforce. 

Outcomes, not just technology 

Successfully implementing Zero Trust is not about the individual technology components and inputs themselves.  Instead, what matters most is how security components are integrated and orchestrated to achieve and enforce a simple set of core principles: 

• Connecting from a particular network must not determine which services you can access
• Access to services and data is granted based on what we know about you and your device
• All access to services must be authenticated, authorized and encrypted.  

Using this set of principles as our north star, Google began our Zero Trust journey, with BeyondCorp, over a decade ago, under similar circumstances to those driving federal cybersecurity policy now. Google had been targeted by nation-state cyber attacks (Operation Aurora), and in the aftermath, we recognized that providing remote access with VPNs was not sustainable or efficient for business performance, especially at a time when Google’s global workforce was growing rapidly. Something had to change.

To improve our security posture and user experience, we had to reimagine our infrastructure and production networks. This ultimately drove innovations in how we protect our supply chains and resulted in a complete rethinking of the scale, analytics and visibility needed to fully modernize and transform enterprise security. The journey forced us to consolidate redundant systems, understand usage patterns better, and transform how people experience security day to day.

A shift in technology and a change in mindset

When we developed BeyondCorp, we had to reimagine our infrastructure and production networks in order to affect a better security posture and user experience. This ultimately drove innovations in how we protect our supply chains and resulted in a complete rethinking of the scale, analytics and visibility needed to fully modernize and transform enterprise security. 

Moving to a Zero Trust approach drastically changed how Google’s end users did business and reduced the toil on both individual users and IT professionals to do their part to secure the enterprise, further fostering  the innovation, architectures, operational integrations and best practices we see today. Now, the layered defenses and invisible security our users experience have been incorporated into Google’s secure cloud offerings, so our customers can experience the same benefits and provide their users with a secure and productive work environment. 

Leadership for a cross-team journey

Of course, change isn’t trivial, especially in government. A shift in behavior, user experience, collaboration, tools and infrastructure requires planning, change management, and executive support.  To make the Zero Trust journey a success, organizations need the long-term focus and vision of leadership to drive meaningful change. For traditional security and technology leaders, accelerating the journey to Zero Trust will require them to think less tactically and and act more strategically, in order to focus more on outcomes and less on inputs, and to integrate, harmonize, orchestrate and automate what were previously standalone IT and security efforts.  For non-technology leaders, their engagement and leadership is essential – and much more likely – given the visible benefits to collaboration, culture, and the business from what could otherwise be seen as a technology-centric initiative.      

Done right, Zero Trust brings a sea change from how most people experience security.  The crossroads of the Zero Trust journey present organizations with two clear choices: stick with an old and not-so-secure security model that’s clunky and burdensome, or adopt a new model that’s more intuitive, easy, and secure.  

Jump start your own journey

Today, the same opportunity exists to transform government security, operations, and organizational models by implementing Zero Trust. By sharing lessons learned from Google’s BeyondCorp journey and building core security capabilities into many of our cloud products, our goal is to help government agencies  accelerate their own Zero Trust journey, transforming the security posture of their highest value and most-critical applications and data.  

To learn more, watch our on-demand sessions from the Google Cloud Government Security Summit,

About the authors

Dan Prieto previously served in the White House as Director for Cybersecurity Policy on the staff of the National Security Council.  He also served as CTO and Director of the Defense Industrial Base Cybersecurity Program in the Office of the Department of Defense CIO.

Max Saltonstall tells stories about Google Cloud, how we use similar Cloudy tools inside Google, and what diverse solutions Cloud’s many customers have created. At Google he’s worked within DoubleClick, Corporate Engineering, Staffing and the Cloud CTO Office.

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.

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.