As enterprises accelerate adoption of cloud-based services and products, they face a common challenge: How can they effectively secure and govern rapidly expanding volumes of their most sensitive data in new environments? 

Today, Google Cloud released an architectural whitepaper and accompanying source code for a solution which successfully completed an assessment facilitated by KPMG LLP and has been accredited by the Enterprise Data Management Council (EDM Council) as a Cloud Data Management Capabilities (CDMC) Certified Cloud Solution. The architecture, which includes Google Cloud’s BigQuery and Dataplex Data Catalog, has been validated against CDMC’s control framework and can be used by new or existing Google Cloud clients wanting to migrate their sensitive data to the cloud with greater confidence.

“This is an exciting milestone for Google Cloud and the CDMC framework,” said John Bottega, president of EDM Council. “Google is advancing cloud adoption across all industries. Now as a CDMC Certified Cloud Solution, their clients can have the added certainty that Google’s architecture has the key controls and accepted best practices in place to protect their data in the cloud.”  

Introducing CDMC

The CDMC framework, developed and published by EDM Council, provides a set of data management capabilities, standards, and best practices for securing their cloud implementations. Contributors to the framework include large global enterprises across regulated industries, major cloud service providers, technology service organizations, and advisory firms. 

The EDM Council also provides a data management assessment framework which includes a framework composed of 14 key controls and corresponding assessment procedures, which are used to validate that sensitive data is being managed effectively. To become a CDMC Certified Cloud Solution, the Google Cloud team designed, implemented, and documented a reference architecture which met the control requirements and was then assessed by KPMG LLP.

Using the solution, customer data assets are automatically classified and tagged with business metadata, their lifecycle is managed, and a reporting engine that proactively scans and publishes findings provides security administrators information about misconfigurations and security issues via a single dashboard.

Who should use this framework?

• CDOs and CISOs: The CDMC framework provides a systematic approach to handling sensitive data in the cloud and is a good starting point for chief digital officer-level discussions around what governance and security controls should be applied to different types of sensitive data. The Google Cloud CDMC assets can help with determining practical scope and efforts needed to implement the CDMC controls within your organization.
• Data platform architects and engineers: The Google Cloud reference architecture provides reusable patterns that can be adopted and customized to suit the particular needs of your organization, as well as your existing architecture and technology stack. 
• Data owners and data stewards: Once implemented, the resulting classification, automation, findings, and reports should reduce the manual burden of effectively governing sensitive data at scale.

Architecture

The architecture combines a number of Google Cloud’s services with built-in platform capabilities and data-protection services to protect data at scale. 

These services include:

• BigQuery, which can fully manage a serverless data warehouse that enables scalable analysis for petabytes of data.
• Dataplex’s Data Catalog, which can fully manage highly scalable data discovery and metadata management with built-in data lineage features.
• Cloud Data Loss Prevention, which provides tools to classify and mask sensitive data.
• VPC Service Controls, which defines a security perimeter around Google Cloud resources to mitigate data exfiltration risks.
• Looker Studio, which provides a sample dashboard to visualize the overall health of the environment.

Additionally, the architecture leverages: 

• Secure Data Warehouse Blueprint, which adheres to practices for data governance when creating, deploying, and operating a data warehouse in Google Cloud.
• Tag Engine, which automates the process of creating and populating metadata tags in Data Catalog.

The diagram below highlights the Google Cloud services used and how they mapped to the 14 CDMC key controls:

Further information

To get started, Google Cloud customers can: 

• Read our whitepaper that describes the architecture and controls
• Download and deploy the solution via our GitHub repository
• Read more about CDMC and its Key Controls Framework
• Read more about the EDM Council

Forensics is the application of science to criminal and civil laws. It is a proven approach for gathering and processing evidence at a crime scene. An integral step in the forensics process is the isolation of the scene without contaminating or modifying the evidence. The isolation step prevents any further contamination or tampering with possible evidence. The same philosophy can be applied to the investigation of digital events.

In this post we will review methods, tactics and architecture designs to isolate an infected VM while still making it accessible to forensic tools. The goal is to allow access so that data and evidence can be captured while protecting other assets. There are many forensic tools for networking that can be used to analyze the captured traffic. This post does not cover these tools but rather how to configure GCP to capture live traffic in the most efficient and secured way. Once traffic is captured, customers can use whatever tools they prefer to run the analysis. More details about these tools and required agents can be found here and details about open source tooling that Google and others are developing are available here.

In cloud security context, when a VM shows signs of compromise, the most common immediate reaction is to take a snapshot, shut down the instance and relocate the image snapshot to an isolated environment, a method known as “dead analysis”. However, shutting down the instance will impede an important step in the investigation and digital forensics, as some important information in a buffer or the RAM may be lost. 

The other forensic approach is “live analysis”, in which the VM is kept on and evidence is gathered from the VM directly. Live forensics enables the imaging of RAM, bypasses most hard drives and software encryption, determines the cause of abnormal traffic, and is extremely useful when dealing with active network intrusions. This process is usually performed by forensic analysts. For example, if there is a good chance the malware resides only in memory then live forensics is, in some cases, the only way to capture and analyze the malware. In this method, in addition to disk and memory evidence, a forensic analysis can also capture live-network from data sent over the compromised VM network interfaces. Some of the benefits of collecting live networks are reconstruction and visualizing traffic flow in real-time, in particular during active network intrusions or attacks. 

In the cloud, a VM must be isolated when it becomes apparent that an incident has happened, in order to protect other VMs from being infected. Our Cloud Forensics 101 session covers the process and required artifacts, such as logs, that need to be collected for cloud forensics. 

What happens when your image is compromised

Let’s now assume that one of the VMs in your infrastructure has been compromised and alarms are coming from products such as GCP’s Cloud Security and Command Center, Chronicle backstory or your SIEM. 

An incident response plan consists of 3 phases: preparation (actions taken before an attack), detection (actions taken during an attack) and response (actions taken after an attack). During the detection phase, the Computer Security Incident Response Team (CSIRT) or threat analysts decide whether live acquisition analysis is required. If live forensics is required, for example when it is vital to acquire a VM’s RAM, then one of the first courses of action is to isolate and contain the VM from the rest of the world and connect the Forensics VPC to the VM for investigation. The forensics VPC resides in a forensics GCP project, it includes digital forensics tools to capture evidence from the VM such as SANS Investigative Forensics Toolkit – SIFT, The Sleuth Kit, Autopsy, Encase, FTK and alike. These tools are already installed, configured, tested and ready to use. The forensics project will also save and preserve evidence such as disk and memory images for forensic review.

We’ll cover two scenarios in this post, the first scenario is to isolate the image and connect the forensics VPC to the image for live acquisition. 

In the second scenario we will also capture live traffic from the isolated image for live network digital forensics. To capture live traffic from the infected VM, we will leverage the GCP Packet Mirroring service to duplicate all traffic going in and out of the VM and send it to a Forensics VPC for analysis. Network forensics analysis tools such as Palo Alto VM-Series for IDS, ExtraHop Reveal(x), CheckPoint CloudGuard, Arkime (formerly Moloch), Corelight are installed, configured and ready for deployment in the Forensics VPC, these tools will be used to analyze the duplicate network traffic. 

Isolating the infected VM from other resources and connecting the forensics VPC

As part of the Incident Response plan preparation phase, the CSIRT created a Google Cloud Forensics Project. Since the Forensics project will be used only when needed, it’s better to automate the creation of the project and its resources with a tool such as Terraform. It is important to grant access to this project only to individuals and groups who deal with incident response and forensics, such as CSIRT. As shown in figure 1, the Forensics project on the right includes its own VPC, non-overlapped subnet and VM images with pre-installed and pre-configured forensics tools. Internal load-balancer and instance-groups are also configured, we will use these resources to capture live traffic, as described later in this post.

In order to contain the spread of any malware or network activity, such as data exfiltration, we’ll isolate the VM with VPC firewall rules. The GCP VPC firewall is a distributed firewall that always enforces its rules, protecting the instances regardless of their configuration and operating systems. In other words, the compromised VM cannot override the firewall enforcement if its policies follow the principle of least privilege . Rules can be applied to all instances in the network, target network tags or service accounts.

Step 1 in the diagram above shows how an infected VM is isolated from the rest of the network by firewall rules that deny any ingress and egress traffic from any CIDR beside the forensics subnet CIDR. The infected VM is tagged with a unique network tag, for example “<image-name>_InfectedVM”, then firewalls rules are applied on the network tag. This ensures that the infected VM is isolated from the project and the Internet while enabling access to the VM via VPC peering which we’ll configure in step-2. You can learn more about VPC firewalls rules here.

In step 2, the VPC from the forensics project is peered with the VPC in the production project. When VPC peering is established routes are exchanged between the VPCs. By default, VPC peering exchanges all subnet routes, however, custom routes can also be filtered if required. At this point, the VM from the forensics project can communicate with the infected VM and start the live forensics analysis job using the pre-installed and pre-configured forensics tools.

Shared VPC is a network construct that allows you to connect resources from multiple projects, called service-projects, to a common VPC in a host-project. VPCs from different projects can securely communicate with each other via the hosted project network while centralizing the network administration. Figure 2 depicts Shared VPC topology, rather than using VPC peering, during step 2 the Forensics project is simply attached to the host project. After the attachment, the Shared VPC allows the forensics tools to communicate with the infected VMs.

Capturing live network traffic with Google Traffic Mirroring

If live network forensics is required, for example during active network intrusions, then the incoming and outgoing traffic needs to be duplicated and captured. While VPC Flow logs capture the networking metadata telemetry, this is not enough for live network forensics analysis. GCP Packet Mirroring clones the traffic of a specified instance in a VPC and forwards it to a specified internal load balancer which collects the mirrored traffic and sends it to an attached instance group. Packet mirroring captures all the traffic from the specified subnet, network tags, or instance name. 

Figure 3 depicts the steps that allow the compromised VM to communicate with the rest of the world (for example beaconing with C&C) while capturing all traffic for investigation in a peered VPC deployment.

Figure 4 depicts the steps that allow the compromised VM to communicate with the rest of the world while capturing all traffic for investigation in a shared VPC deployment.

We will use the Forensics’ project internal load balancer and the instance group VMs which include packet capture and analysis tools. Note that production and forensics networks must be in the same region. Detailed steps to configure packet mirroring are available on this page. 

If you are using a Shared VPC then check the Packet Mirroring configuration for Shared VPC for configuration details. Figure 4 depicts the packet mirroring flow in a shared VPC topology.

It is recommended to automate and periodically test the process to make sure that in case of an incident, the entire setup and Forensics toolchain can be quickly deployed. If after initial investigation a suspicious destination, such as a Command and Control [C&C] Server, has been identified, then the Packet Mirroring policy can be adjusted with a policy filter that only mirrors traffic from that C&C server IP address.

An incident management plan must be in place for companies using cloud services, and this plan should also include the option of using live acquisition when necessary. design and preparation for forensics acquisition allows the company to build the infrastructure that can be deployed and connected to the appropriate VM automatically. The architectures described in this post can help the process of collecting and preserving vital evidence for the forensic process, while the incident response team resolves the incident.

Cloud transformation and the adoption of modern DevOps technology presents both opportunities and challenges for IT compliance functions. With DevOps style application development, the feedback loop for developers and engineers is much tighter than with traditional application development pipelines, enabling speed and agility of application release cycles. While speedy CI/CD is a critical advantage of DevOps, it also shifts compliance left in the development timeline, and therefore puts pressure on the IT risk & compliance organization to modernize their approach to regulatory compliance as well. With the ongoing shift towards cloud technologies and DevOps, modernization of regulatory compliance is no longer optional for an IT compliance function

Compliance modernization is a broad mandate that spans the way the function is governed; the tools, technology, and analytics it uses; the number and nature of its connections to other parts of the business; verifiability and auditability of the controls’ evidence, the expectations assigned to it; and more.

Public cloud technology is becoming a core part of many industries today, and with this comes some potential risks such as cloud misconfigurations exposing intellectual property, loss of physical control of assets, skillset scarcity around cloud based security and compliance. 

Given the constantly changing risk landscape, it is critical that regulations more closely align to address these risks. As regulations and risks evolve, the aim of a modern compliance function is to help an organization stay compliant as it goes through a digital transformation. As organizations go through digital transformation, IT compliance also needs to transform — via upgrading the technology stack, modifying the business processes and most importantly re-skilling people to become cloud aware.

Today we are releasing the new paper by Google Cloud’s Office of the CISO. In the paper we reveal a new approach for modernizing your compliance approach using modern approaches and Google Cloud toolsets. Your team can leverage the paper to add value to enterprises, both by charting a course to the safe use of cloud technology and by reducing risk through the use of the public cloud.

Read the paper “Assuring Compliance in the Cloud.”

Also, review these related resources:

• “Risk Governance of Digital Transformation in the Cloud“ paper
• “Making Compliance Cloud-native” (episode 14) with Zeal Somani
• Google Cloud Compliance resource center
• Our compliance blueprints: PCI DSS on GKE and GCP FedRAMP Blueprint
• Google Cloud security best practices center

As cloud adoption continues to grow, so too does the number of cloud-born security threats. However, cloud environments can present significant opportunities to improve security with the right tools and processes in place.

When it comes to effective threat detection, investigation and response (TDIR) in the cloud, modern solutions must ensure that the entire security operations workflow — from data analysis through detection to response — are working in tandem to deliver the insights, context, and processes needed for cyber defenders to respond to threats with speed and precision. 

At Google Cloud, we believe that modern security operations should rely less on customer engineering and more on packaged outcomes delivered by solution providers. With this in mind, we are excited to announce today at our annual Security Summit that Chronicle Security Operations now provides turnkey TDIR for Google Cloud. By integrating with our cloud-focused Security Command Center Premium (SCC) and Google Cloud telemetry, Chronicle can collect and analyze data from Google Cloud, detect and investigate threats, and automate responses to mitigate risks.

In our recent State of Cloud Threat Detection and Response Survey, 71% of respondents said that “entire classes of threats are eliminated by migrating to the cloud,” and 82% stated that “the cloud affords the ability to process more data, including on-prem data, which can improve detection across the board.” 

To take advantage of all that the cloud can do for security, organizations should to do more than “lift and shift” their existing security tools and processes to the cloud. The cloud presents a different attack surface, often across several cloud services and data repositories, and each can have different attack tactics, potential misconfigurations, and context.  

This update to Chronicle helps enable teams to:

• Detect with confidence. Out-of-the-box detection rule sets developed by Google threat researchers surface cloud attack vectors and provide high fidelity, contextualized alerts that quickly give insight into potential threats in your Google Cloud environment. 
• Investigate with full context. Visualize threat storylines, complete with cloud-specific context that is correlated with additional data and context from across your environment for fast and efficient investigations.
• Respond with speed and precision. Streamline workflows and automate response actions with prebuilt playbooks and best practices designed specifically for Google Cloud. Chronicle SOAR’s case management and team collaboration help ensure fast and timely response.
• Simplify data ingestion. Chronicle automatically ingests, normalizes and contextualizes cloud telemetry from a variety of Google Cloud services (such as Cloud Asset Inventory, Google Kubernetes Engine, Google Compute Engine, cloud audit logs, and Cloud DLP), reducing the need for complex and time-consuming engineering.

Putting Google Cloud TDIR to work 

Let’s take a closer look at how our end-to-end cloud TDIR workflow manages a potential Google Cloud attack. 

Setting up cloud TDIR in Chronicle only takes a few clicks. Security Command Center’s built-in threat detection identifies attacks against Google Cloud resources. These findings, as well as audit, NAT, DNS, and firewall logs, are ingested into Chronicle to provide additional insight and context into Google Cloud threats.

Chronicle now provides detection rules for Google Cloud threats. These rules correlate SCC findings with Chronicle’s advanced detection engine to reveal the broad scope of malicious activity, giving you visibility and more contextual information into what’s going on in your environment. In our example, Chronicle alerts on suspicious activity that can indicate an attempt to exfiltrate data from BigQuery.

The new Chronicle Alert Graph surfaces key details of primary alerts you’re investigating in seconds. Combining cloud alerts and telemetry and correlating that with vital context from other sources (such as user data, endpoint data, and threat intelligence,) you can explore the visual representation of an alert’s relationship to other alerts and entities, dig into the potential attack paths, get quick summaries of implicated security artifacts, and pivot into your Google Cloud Console to do a deeper dive into potentially-impacted resources.  

In our example, we can see a BigQuery exfiltration event associated with a customer and that it’s associated with a particular service account tied to a Google Cloud org. Alert context below tells us more about what’s been impacted. It shows us that cloud credentials in the form of encryption keys and email addresses were associated with the event.

Chronicle case management automatically groups any related alerts into threat-centric cases, uniting the information that matters and making it simple for you to see and understand the scope of the event. 

In our example, Chronicle groups these alerts together based on common source address and username, and the case wall provides the summary of the alerts and actions that are taking place across the entire case.

Chronicle playbooks, designed specifically for Google Cloud, automate your desired response processes. In our example, when an alert was generated a playbook automatically ran through predefined steps that gathered data, enrichment, and took automated remediation steps to prevent this service account and instance from continuing.

Ready to detect with confidence, investigate with broad context, respond with speed and precision, and simplify data ingestion? Chronicle Security Operations is your go-to for turnkey, end-to-end threat detection, investigation, and response on Google Cloud.    

Tune in to our Security Summit session to learn more and see a demo of the new Google Cloud TDIR capabilities.