Hi there! I’m David Challoner from Access Site Reliability Engineering (SRE), here with Anthony Bushong from Developer Relations to talk about how Corp Eng is adopting Anthos Service Mesh internally at Google.

Corp Eng is Google’s take on “Enterprise IT”. A big part of the Corp Eng mission is running the first and third party software that powers internal business processes – from legal and finance to floor planning and even the app hosting our cafe menus – all with the same security or production standards as any of Google’s first party applications.

Googlers need to access these applications, which sometimes then need to access other applications or other Google Cloud services. This traffic can cross different trust boundaries which can trigger different policies.

Access SRE runs the systems that mediate this access, and we implemented Anthos Service Mesh as part of our solution to secure the way Googlers access these applications.

But why?

You can probably tell, but the applications Corp Eng is responsible for have disparate requirements. This often means that certain applications are tied to disparate infrastructure due to legal, business or technical reasons – which can be challenging when those infrastructures work and operate differently.

Enter Anthos. Google Cloud built Anthos to provide a consistent platform interface unifying the experience of working with apps on these varying underlying infrastructures, with the Kubernetes API at its foundation.

So when searching for the right tool to build a common authorization framework to mediate access to CorpEng services, we turned to Anthos – specifically Anthos Service Mesh, powered by the open-source project, Istio. Whether these services were deployed in Google Cloud, in Corp Eng data centers, or at the edge onsite at actual Google campuses, Anthos Service Mesh delivered a consistent means for us to program secure connectivity.

To frame the impact ASM had on our organization, it’s helpful to introduce the roles of the folks who manage and use it:

For security stakeholders, ASM provides an extensible policy enforcement point running next to each application capable of provisioning a certificate based on the identity of the workload and enforcing mandatory fine-grained application-aware access controls.

For platform operators, ASM is delivered as a managed product, which reduces operational overhead by providing out-of-the-box release channels, maintenance windows, and a published Service Level Objective(SLO).

For service owners, ASM enables the decoupling of their applications from networking concerns, while also providing features like rate limiting, load shedding, request tracing, monitoring, and more. Features like these were typically only available for applications that ran on Borg, Google’s first-party cluster manager that ultimately inspired the creation of Kubernetes.

In sum, we were able to secure access to a plethora of different services with minimal operational overhead, all while providing service owners granular traffic control.

Let’s see what this looks like in practice!

The architecture

In this flow, user access first reaches the Google Cloud Global Load Balancer [1], configured with Identity Aware Proxy (IAP) and Cloud Armor. IAP is the publicly available implementation of Google’s internal philosophy of BeyondCorp, providing an authentication layer that works from untrusted networks without the need for a VPN.

Once a user is authenticated, their request then flows to the Ingress Gateway provided by Anthos Service Mesh [2]. This provides additional checks that traffic flows to services only when the request has come through IAP, while also enforcing mutual TLS (mTLS) between the Anthos Service Mesh Gateway to the Corp services owned by various teams.

Finally, additional policies are enforced by the sidecar running in every single service Pod [3]. Policies are pulled from source control using Anthos Config Management[4], and are propagated to all sidecars by the managed control plane provided by Anthos Service Mesh[5].

Managing the mesh

If you’re not familiar with how Istio works, it follows the pattern of a control plane and a data plane. We talked a little bit about the data plane – it is made up of the sidecar containers running alongside all of our service Pods. The control plane, however, is what’s responsible for updating these sidecars with the policies we want to enforce:

Thus, it is critical for us to ensure that the control plane is healthy. This is where Anthos Service Mesh gives our platform owners a huge advantage with its support for a fully-managed control plane. To provision cloud resources, like many other companies, our organization uses Terraform, the popular open-source infrastructure as code project. This gave us a declarative and familiar means for provisioning the Anthos Service Mesh control plane.

First, you enable the managed control plane feature for GKE by creating the google_gke_hub_feature resource below using Terraform.

resource "google_gke_hub_feature" "feature_asm" {
name = "servicemesh"
location = "global"
provider = google-beta
}

Keep in mind that at publication time, this is only available via the google-bet provider in Terraform.

Once created, we then provision a ControlPlaneRevision custom resource in a GKE cluster to spin up a managed control plane for ASM in that cluster:

apiVersion: mesh.cloud.google.com/v1alpha1
kind: ControlPlaneRevision
metadata:
  
name: asm-managed
  
namespace: istio-system
spec:
  
type: managed_service
  
channel: regular

Using this custom resource, we are able to set the release channel for the ASM managed control plane. This allows for our platform team to define the pace of upgrades in accordance with our team’s needs.

In addition to managing the control plane, ASM also provides management functionality around the data plane to ensure each sidecar Envoy is kept up to date with the latest security updates and is compatible with the control plane – one less thing for service operators to worry about. It does this using Kubernetes Mutating Admission Webhooks and Namespace labels to modify our Pod workload definitions to inject the appropriate sidecar proxy version.

Syncing mandatory access policies

With the core Anthos Service Mesh components in place, our security practitioners can define consistent, mandatory security policies for every single GKE cluster, using Istio APIs.

For example, one policy is enforcing strict mTLS between Pods using automatically provisioned workload identity certificates. Earlier, we talked about how this is enforced between the Istio Gateway; that same policy enforces mTLS between all Pods in our cluster.

Another policy we implement is denying all egress traffic by default, requiring service teams to explicitly declare their outbound dependencies. The following is an example of using an Istio Service Entry to allow granular access to a specific external service – in this case, Google. This helps prevent unintended access to external services.

apiVersion: networking.istio.io/v1alpha3

kind: ServiceEntry
metadata:
  
name: google
spec:
  
hosts:
  - www.google.com
  
ports:
  - number: 443
    
name: https
    
protocol: HTTPS
  
resolution: DNS
  
location: MESH_EXTERNAL
EOF

These policies are automatically synced to all service mesh namespaces in each cluster using Anthos Config Management. By using our internal source control system as a source of truth, Anthos Config Management can sync and reconcile policies across all of our GKE clusters, ensuring that these policies are in place for every single one of our services. You can find more details about our implementation of Anthos Config Management here.

With this in place, our team plans on eventually migrating away from security automation that operates solely based on explicit IP, port and protocol policies.

Integration with Identity-aware Proxy

The publicly available version of the BeyondCorp proxy used by CorpEng is called Identity-aware Proxy (IAP), which offers an integration with Anthos Service Mesh. IAP allows you to authenticate users trying to access your services and apply Context-Aware-Access policies. This integration comes with two main benefits:

• Ensuring that user traffic to services in the service mesh only come through Identity-aware Proxy
• Enforcing Context-aware access (CAA) trust levels for devices, defined by multiple device signals we collect

Identity-aware Proxy allows us to capture this information in a Request Context Token (RCToken), which is a JSON Web Token (JWT) created by Identity-aware Proxy that can be verified by ASM. IAP inserts this JWT into the Ingress-Authorization header. Using Istio Authorization Policies similar to the following policy, any requests without this JWT are denied:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: iap-gateway-require-jwt
namespace: istio-system
spec:
selector:
matchLabels:
app: istio-iap-ingressgateway
action: DENY
rules:
- from:
- source:
notRequestPrincipals: ["*"]

Here is an example policy that requires a fullyTrustedDevice access level – this might be a device in your organization that is known to be corporate-owned, fully-updated, and running an IT-approved configuration :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-fully-trusted-device
  namespace: fooService
spec:
  selector:
    matchLabels:
      app: fooService
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["*"]
    when:
    - key: request.auth.claims[google.access_levels]
      values: ["accessPolicies/$orgId/accessLevels/fullyTrustedDevice"]

This allows our security team to not only secure service to service communications, or outbound calls from services, but also specifically require incoming requests come from trusted devices and authenticated users using a trusted device.

Enabling service teams

As an SRE, one of our priorities is ensuring Service-level indicators (SLIs), SLOs, and Service-level agreements (SLAs) exist for services. Anthos Service Mesh helps us empower service owners to do this for their services, as it exposes horizontal request metrics like latency and availability to all services in the mesh.

Before Anthos Service Mesh, each application had to export these separately (if at all). With ASM service owners can easily define their Service’s SLOs in the cloud console or via terraform using these horizontally exported metrics. This then allows us to integrate SLOs into our higher-level service definitions so we can enable SLO monitoring and alerting by default. You can see the SRE book for more details on SLOs and Error budgets.

The takeaway

ASM is a powerful tool that enterprises can use to modernize their IT infrastructure. It provides:

• A shared environment-agnostic enforcement point to manage security policy
• A unified way to provision identities, describe application dependencies

This also enables previously unheard of operational capabilities such as distributed tracing or incremental canary rollouts – which were difficult to find in the typical enterprise application landscape.

Because it can be incrementally adopted and composed with existing authorization systems to close gaps – barriers to adoption are low and we recommend you start evaluating it today!

We’re pleased to announce that Confidential Space, our new solution that allows you to control access to your sensitive data and securely collaborate in ways not previously possible, is now available in public Preview. First announced at Google Cloud Next, Confidential Space can offer many benefits to securely manage data from financial institutions, healthcare and pharmaceutical companies, and Web3 assets. Today, we will explore some security properties of the Confidential Space system that makes these solutions possible.

Confidential Space uses a trusted execution environment (TEE), which allows data contributors to have control over how their data is used and which workloads are authorized to act on the data. An attestation process and hardened operating system image helps to protect the workload and the data that the workload processes from an untrusted operator.

The Confidential Space system has three core components:

1. The workload is a containerized image with a hardened OS that runs in a cloud-based TEE. You can use Confidential Computing as the TEE that offers hardware isolation and remote attestation capabilities.
2. The attestation service, which is an OpenID Connect (OIDC) token provider. This service verifies the attestation quotes for TEE and releases authentication tokens. The tokens contain identification attributes for the workload.
3. A managed cloud protected resource, such as a Cloud Key Management Service key or Cloud Storage bucket. The resource is protected by an allow policy that grants access to authorized federated identity tokens.

The system can help ensure that access to protected resources is granted only to authorized workloads. Confidential Space also can help protect the workload from inspection and tampering, before and after attestation.

In our published Confidential Space Security Overview research paper, we explore several potential attack vectors against a Confidential Space system and how it can mitigate those threats. Notably, the research notes how Confidential Space can protect against malicious workload operators and administrators, and malicious outside adversaries, who are attempting to create rogue workload attestations.

Through these protections, Confidential Space establishes confidence that only the agreed upon workloads will be able to access sensitive data. The research also highlights some of the extensive security reviews and tests executed to identify potential weak points in the system, including domain expert reviews, meticulous security audits, and functional and fuzz testing.

We asked the NCC Group for an independent security assessment of Confidential Space to analyze its architecture and implementation. NCC Group leveraged their experience reviewing other Google Cloud products to dig deep into Confidential Space.

The NCC Group’s extensive review, which included penetration testing and automated security scanning, found zero security vulnerabilities. In their report, the architecture review highlights how the security properties are achieved through the coordination of measured boot with vTPM attestation, reduced attack surface with constricted administrator controls and access, workload measurement and enforced launch policy, and resource protection policy based on attested workload runtime properties.

The combination of these attributes creates powerful security properties, gating release of data on runtime measurements of the actual workload code and environment instead of just user and service account credentials. Confidential Space provides a platform that includes:

• A dependable workload attestation, including workload code measurement, arguments and environment, and operating environment claims
• A fully-managed attestation verification service that validates expected environmental attestation claims
• A policy engine allowing for arbitrarily complex (or extremely simple) policy to be created around those claims
• A mechanism to attach those policies to Google Cloud resources

Together, the platform provides a mechanism where one can ensure that their data is only ever released into trusted workloads that will not abuse that data.

Take a look at our documentation and codelab and take it for a spin. We hope that Confidential Space can inspire organizations to solve their use cases around multi-party collaboration with sensitive data; please contact your Google Cloud sales representative if you have any questions.

As their name reflects, DueDil provides due diligence services ranging from customer-specific risk evaluations and selections to customer onboarding and real-time risk monitoring for leading financial services, high-growth tech and insurance companies. Founded in 2009, the company helps more than 3,000 enterprise users from over 400 clients to not only understand with whom they’re doing business, but to do so with increased efficiency and in compliance with regulatory requirements. 

Due diligence services have evolved in recent years, both because of new regulations and new technologies supplanting legacy systems and processes, many of which relied until recently on pen-and-paper workflows or exhaustive spreadsheet work. DueDil knew this technology transformation represented an opportunity to replace manual processes with automation–but it also recognized a second opportunity: to not merely process data but also activate it by connecting information in disparate IT systems and generating data-driven insights delivered at scale.  

To capitalize on this opportunity, the company built its Business Information Graph, or B.I.G., a platform that maps approximately 300 million connections among companies. B.I.G. ingests billions of data points, and is refreshed multiple times per day, to surface unique insights about business’s relationships, such as fraud risks. The results that B.I.G. drives often speak for themselves: some DueDil customers onboard partners up to 80% faster, perform risk verification up to 18 times faster, and reduce time spent on manual portfolio checks by up to 80%. 

What powers all of this transformation? Application Programming Interfaces (APIs). 

“From a go-to-market standpoint, our product is an API,” said Denis Dorval, DueDil COO, in a recent webcast, explaining that customers can directly tap B.I.G.’s resources for themselves, and build atop them for their own needs, via DueDil’s API. 

Choosing an API management platform to deliver fast, secure, and scalable APIs

To execute on their vision of connecting B2B ecosystems for better insights and efficiency, DueDil looked for a cloud provider that could fulfill several specific criteria. They needed robust management for the APIs with which their internal developers leverage different systems for new use cases and process automations, as well as for the productized API they offer to customers. They needed sophisticated analytics and abundant processing power to crunch through billions of data points. And, they needed enterprise-grade security, scalability, and agility to underpin it all. Last but not least, the company prioritized a smooth transition; DueDil did not want the user experience to suffer as it switched providers.

“The stability of Google Cloud’s Apigee API management platform and the strength of its services stood out”, said DueDil’s Engineering Manager, Robert Cicero. 

“Apigee is a resilient and agile platform, fulfilling our need to build APIs quickly, safely, and at scale,” he remarked, noting that he appreciated that many of Apigee’s API security defense tools and policies work out-of-the-box. For instance, Apigee’s JSON threat detection policies, custom policies, and authentication and authorization processes can be deployed instantly and add minimal latency, meaning DueDil can stop security threats before they enter its network while still avoiding the risk of service lags.

Today, DueDil has five internal services that facilitate business due diligence, all exposed via Apigee. They also use Apigee’s monetization feature to drive API consumption. This said, because DueDil’s go-to-market strategy is fast-paced and client-oriented, they most often use Apigee to rapidly prototype APIs for their clients, so they can understand what a specific API would look like and how it would behave. This allows DueDil, its partners, and its customers to spend more time delivering value from insights rather than getting bogged down in building backend systems. 

Moreover, Apigee made it simpler to also connect to other Google Cloud services, such as BigQuery, Google Data Studio, and Google Cloud Storage. Apigee acts as a central nervous system among systems, giving DueDil not only the ability to connect systems and automate processes but also insight and visibility into how its B.I.G. services are being used by partners and customers. 

Plus, added Cicero, “the migration to Apigee was seamless, with arguably our biggest win being that no one knew that we had switched API management providers to Apigee.”  

Leveraging APIs to provide self-service while enforcing security and governance policies

Moving forward, DueDil plans to leverage Apigee to give staff members and clients more privileges, visibility, and opportunity to create and edit apps in a self-service manner, without needing to rely on an IT department or endure long approvals processes. Harnessing APIs to open up B.I.G. and other capabilities to more teams across the company will also allow DueDil to move faster and include more people in the innovation process. Leveraging Apigee API management capabilities, DueDil also intends to dive deeper and experiment with other Google Cloud products and services, including Cloud Function, Cloud Pub/Sub, and more.

“At the end of the day, every company goes about due diligence a little differently. The only way that we at DueDil are able to provide something that is configurable and dynamic to diverse businesses is if we use platforms that can adapt, too,” said Cicero. “Apigee gives us the agility required to create and deliver for a wide variety of businesses.”

Google Cloud, today, works across banking, capitalmarkets, insurance, and payments worldwide to solve their most challenging problems. Click here to learn more about how Google Cloud Apigee API management can help you design, secure, analyze, and scale APIs anywhere with visibility and control. To try Apigee API management for free, click here.

Ransomware, a form of malware that encrypts a user’s or organization’s most important files or data rendering them unreadable, isn’t a novel threat in the world of computer security. These destructive, financially-motivated attacks where cybercriminals demand payment to decrypt data and restore access have been studied and documented for many years. Today’s reality shows us that these attacks have become more pervasive, impacting essential services like healthcare or pumping gasoline. Yet despite attempts to stop this threat, ransomware continues to impact organizations across all industries, significantly disrupting business processes and critical national infrastructure services and leaving many organizations looking to better protect themselves. Organizations that continue to rely on legacy systems are especially vulnerable to ransomware threats, as these systems may not be regularly patched and maintained. 

For more than 20 years Google has been operating securely in the cloud, using our modern technology stack to provide a more defensible environment that we can protect at scale. We strive to make our security innovations available in our platforms and products for customers to use as well. This underpins our work to be the industry’s most trusted cloud, and while the threat of ransomware isn’t new, our responsibility to help protect you from existing or emerging threats never changes. In this post, we share guidance on how organizations can increase their resilience to ransomware and how some of our Cloud products and services can help.

Develop a comprehensive, defensive security posture to protect against ransomware

Robust protection against ransomware (and many other threats) requires multiple layers of defense. The National Institute of Standards and Technology (NIST) outlines five main functions in the Cybersecurity Framework that serve as the primary pillars for a successful and comprehensive cybersecurity program in any public or private sector organization. Below are the recommendations from NIST and examples of how our Cloud technologies can help address ransomware threats:

Pillar #1 – Identify: Develop an understanding of what cybersecurity risks you need to manage for the scope of your assets, systems, data, people, and capabilities. In the case of ransomware, this covers which systems or processes are most likely to be targeted in a ransomware attack, and what the business impact would be if specific systems were rendered inoperable. This will help prioritize and focus efforts to manage risks. 

Our CISO Guide to Security Transformation whitepaper outlines steps for a risk-informed, rather than risk-avoidance, approach to security with the cloud. A risk-informed approach can help you address the most important security risks, instead of addressing the risks that you already know how to mitigate. Cloud service providers make this risk-informed approach easier and more efficient for you by developing and maintaining many of the controls and tools that you need to mitigate modern security threats. Services like Cloud Asset Inventory provide a mechanism to discover, monitor, and analyze all your assets in one place for tasks like IT ops, security analytics, auditing, and governance. 

Pillar #2 – Protect: Create safeguards to ensure delivery of critical services and business processes to limit or contain the impact of a potential cybersecurity incident or attack. In the case of ransomware, these safeguards may include frameworks like zero trust that protect and strongly authenticate user access and device integrity, segment environments, authenticate executables, reduce phishing risk, filter spam and malware, integrate endpoint protection, patch consistently and provide continuous controls assurance. Some examples of products and strategies to involve in this step include: 

• A cloud-native, inherently secure email platform: Email is at the heart of many ransomware attacks. It can be exploited to phish credentials for illegitimate network access and/or to distribute ransomware binaries directly. Advanced phishing and malware protection in Gmail provides controls to quarantine emails, defends against anomalous attachment types, and protects from inbound spoofing emails. Security Sandbox detects the presence of previously unknown malware in attachments. As a result, Gmail prevents more than 99.9 percent of spam, phishing, and malware from reaching users’ inboxes. Unlike frequently-exploited legacy on-premises email systems, Gmail is continually and automatically updated with the latest security improvements and protections to help keep your organization’s email safe.
• Strong protection against account takeovers: Compromised accounts allow ransomware operators to gain a foothold in victim organizations, perform reconnaissance, get unauthorized access to data and install malicious binaries. Google’s Advanced Protection Program provides the strongest defense against account takeovers and has yet to see a user that participates in the program be successfully phished. Further, Google Cloud employs many layers of machine learning systems for anomaly detection to differentiate between safe and anomalous user activity across browsers, devices, application logins, and other usage events.  
• Zero trust access controls that limit attacker access and lateral movement: BeyondCorp Enterprise provides a turnkey solution for implementing zero trust access to your key business applications and resources. In a zero trust access model, authorized users are granted point-in-time access to individual apps, not the entire corporate network, and permissions are continuously evaluated to determine if access is still valid. This prevents the lateral movement across the network that ransomware attackers rely on to hunt for sensitive data and spread infections. BeyondCorp’s protections can even be applied to RDP access to resources, one of the most common ways that ransomware attackers gain and maintain access to insecure legacy Windows Server environments. 
• Enterprise threat protections for Chrome: Leveraging Google Safe Browsing technology, Chrome warns users of millions of malware downloads each week. Threat protection in BeyondCorp Enterprise delivered through Chrome can prevent infections from previously unknown malware including ransomware, with real-time URL checks and deep scanning of files.

• Endpoints designed for security: Chromebooks are designed to protect against phishing and ransomware attacks with a low on-device footprint, read-only, constantly invisibly updating Operating System, sandboxing, verified boot, Safe Browsing and Titan-C security chips. Rollout of ChromeOS devices for users who work primarily in a browser can reduce an organization’s attack surface, such as relying too much on legacy Windows devices, which have been found to often be vulnerable to attacks.

Pillar #3 – Detect: Define continuous ways to monitor your organization and identify potential cybersecurity events or incidents. In the case of ransomware, this may include watching for intrusion attempts, deploying Data Loss Prevention (DLP) solutions to detect exfiltration of sensitive data from your organization, and scanning for early signs of ransomware execution and propagation.  

The ability to spot and stop malicious activity associated with ransomware as early as possible is key to preventing business disruptions. 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.

DLP technologies are also useful in helping detect data that could be appealing to ransomware operators. With data discovery capabilities like Cloud DLP, you can detect sensitive data that’s accessible to the public when it should not be and detect access credentials in exposed code. 

Pillar #4 – Respond: Activate an incident response program within your organization that can help contain the impact of a security (in this case, ransomware) event.  

During a ransomware attack or security incident, it’s critical to secure your communications both internally to your teams and externally to your partners and customers. Many organizations with legacy Office deployments have shifted to Google Workspace because it offers a more standardized and secure online collaboration suite, and in the event of a security incident, a new instance can quickly be stood up to provide a separate, secure environment for response actions.

Pillar #5 – Recover: Build a cyber resilience program and back-up strategy to prepare for how you can restore core systems or assets affected by a security (in this case, ransomware) incident. This is a critical function for supporting recovery timelines and lessening the impact of a cyber event so you can get back to operating your business. 

Immediately after a ransomware attack, a safe point-in-time backup image that is known not to be infected must be identified. Actifio GO provides scalable and efficient incremental data protection and a unique near-instant recovery capability for data. This near-instant recovery facilitates identifying a clean restore point quickly, enabling resumption of business functions rapidly. Actifio GO is infrastructure-agnostic and can protect applications on-premises and in the cloud. 

In Google Workspace, if files on your computer were infected with malware but you sync them to Google Drive, you may be able to recover those files. Additionally, ensuring that you have a strong risk transfer program in place, like our Risk Protection Program, is a critical element of a comprehensive approach to managing cyber risk. 

Key ransomware prevention and mitigation considerations for business and IT leaders

As you plan for a comprehensive defense posture against ransomware threats, here are some key questions to consider:

• Does your organization have a ransomware plan, and what does it entail? Remember to demand a strong partnership with your cloud providers based on a shared understanding of risk and security objectives. 
• How are you defending your organization’s data, systems and employees against malware? 
• Are your organization’s systems up to date and patched continuously? 
• Are you watching for data exfiltration or other irregularities? 
• What is your comprehensive zero trust approach, especially strongly authenticating my employees when they access information? 
• Are you taking the right back ups to high assurance immutable locations and testing that they are working properly? This should include testing that does a periodic restore of key assets and data. 
• What drills are you conducting to battle-test your organization’s risk management and response to cyber events or incidents? 

Ransomware attacks will continue to evolve 

Recently, ransomware groups have evolved their tactics to include stealing data prior to it being encrypted, with the threat of extorting this data through leaks. Additionally, some ransomware operators have used the threat of distributed-denial-of-service (DDoS) attacks against victim organizations as an attempt to further compel them to pay ransoms. DDoS attacks can also serve as a distraction, occupying security teams while attackers seek to accomplish other objectives such as data exfiltration or encryption of business-critical data. By deploying Google Cloud Armor — which can scale to absorb massive DDoS attacks— you can help protect services deployed in Google Cloud, other clouds, or on-premise against DDoS attacks.

Protecting against ransomware is a critical issue for all organizations, and these questions and best practices are only the start of building a mature and resilient cybersecurity posture.  It’s important to remember that you can’t focus on a single piece of defense; you need a comprehensive cybersecurity program that enables you to identify, prevent, detect, respond, and recover from threats. Above all, you need a range of solutions from a battle-tested and highly-resilient cloud platform that works across these elements in an integrated way with your business. To learn more about how Google Cloud can help you implement a comprehensive cybersecurity program to protect against threats like ransomware and more, visit our Google Cloud Security Best Practices Center.