At Google Cloud, we are committed to advancing invisible security and democratizing security operations for every organization. Today, we’re proud to share the next step in this journey with the acquisition of Siemplify, a leading security orchestration, automation and response (SOAR) provider. Siemplify shares our vision in this space, and will join Google Cloud’s security team to help companies better manage their threat response.

In a time when cyberattacks are rapidly growing in both frequency and sophistication, there’s never been a better time to bring these two companies together. We both share the belief that security analysts need to be able to solve more incidents with greater complexity while requiring less effort and less specialized knowledge. With Siemplify, we will change the rules on how organizations hunt, detect, and respond to threats.

Providing a proven SOAR capability unified with Chronicle’s innovative approach to security analytics is an important step forward in our vision. Building an intuitive, efficient security operations workflow around planet-scale security telemetry will further realize Google Cloud’s vision of a modern threat management stack that empowers customers to go beyond typical security event and information management (SIEM) and extended detection and response (XDR) tooling, enabling better detection and response at the speed and scale of modern environments. 

“We’re excited to join Google Cloud and build on the success we’ve had in the market helping companies address growing security threats,” said Amos Stern, CEO at Siemplify. “Together with Chronicle’s rich security analytics and threat intelligence, we can truly help security professionals transform the security operations center to defend against today’s threats.”

The Siemplify platform is an intuitive workbench that enables security teams to both manage risk better and reduce the cost of addressing threats. Siemplify allows Security Operation Center analysts to manage their operations from end-to-end, respond to cyber threats with speed and precision, and get smarter with every analyst interaction. The technology also helps improve SOC performance by reducing caseloads, raising analyst productivity, and creating better visibility across workflows.

We plan to invest in SOAR capabilities with Siemplify’s cloud services as our foundation and the team’s talent leading the way. Our intention is to integrate Siemplify’s capabilities into Chronicle in ways that help enterprises modernize and automate their security operations. 

We’re looking forward to welcoming the Siemplify team to Google Cloud and working with them to help security operations teams accomplish so much more in defense of their organizations. You can read Siemplify CEO Amos Stern’s blog for more on this exciting news.

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.

In the fall of 2022, we announced new policy constructs for Google Cloud Firewall, a scalable, cloud-first firewall service that helps secure traffic flow to and from workloads in Google Cloud, and whose distributed architecture enables simplified, granular control including micro-segmentation. Whereas legacy VPC firewall rules included network tags that were not governed by our IAM infrastructure, Cloud Firewall’s new network firewall policies with IAM-governed tags conform to our hierarchical control model and can help improve security operations. 

We recommend that customers migrate from VPC firewall rules to the newly introduced network firewall policies. To assist with the migration, we developed a migration tool that creates a global network firewall policy and converts existing VPC firewall rules into the new policy.

With Google Cloud’s network firewall policies, we offer rules defined on a per-VPC network basis, either for all regions of the network (global network firewall policies) or a single region (regional network firewall policies). Granular controls enforced at the virtual machine (VM) level using IAM-governed Tags deliver intra-subnet micro-segmentation with pervasive policy coverage that automatically applies to workloads wherever they are deployed, independent of network architecture. 

Network firewall policies allow for: 

• Batch editing of multiple rules within a single policy, which saves time, simplifies rule management, and eliminates race conditions created by single rule update patterns
• A single resource to contain all the firewall rule sets applied to a VPC network, making it easy to modify and update the firewall configurations with unified APIs on the single resource
• Granular IAM controls based on your needs and requirements, such as separate IAM permissions for firewall policy creation, update, and association 
• Sharing and attaching of firewall configurations across VPC networks in the same project, which simplifies configuration and management

With these increased capabilities, the combination of the new policy structures and the IAM-governed tags can help simplify operations, while achieving more reliable granular control and the implementation of least-privilege policies. 

Going forward, all new enhancements and features for Cloud Firewall will only be supported through firewall policies. Network firewall policies and Tags integration are part of the Cloud Firewall Essentials tier, which is offered to customers at no additional charge. We encourage customers to migrate to network firewall policies to take advantage of future Cloud Firewall product enhancements, such as the Threat Intelligence, FQDN, and geo-location filtering features introduced in the Cloud Firewall Standard tier. For more details, please see our Cloud Firewall Standard announcement blog.

Network firewall policy migration tool overview 

The new migration tool helps you convert existing VPC firewall rules into the new policy. This tool does not delete or affect existing VPC firewall rules. Once the new global network firewall policy is created, you can attach the network firewall policy to a VPC. You also have the option to swap the evaluation order of network firewall policies and VPC firewall rules. 

Existing VPC firewall rules can be removed after you confirm the newly created network firewall policy works as intended. The best way to verify this is to enable firewall logging on both the existing VPC firewall rules and the new network firewall policy. After the evaluation order has been swapped to evaluate the new global policy first, you can review the firewall logs to confirm that the new network firewall policy rules are evaluated and hit as intended, and the hit count for the equivalent VPC firewall rules are shadowed and no longer getting hits. Support for the hit count and shadowed rule analysis will also be available in the upcoming release of Firewall Insights. More details can be found in the migration tool guide. 

You can access the migration tool as a gcloud command. There are two mandatory arguments in this command: (1) the source VPC Network (SOURCE_VPC_NETWORK) and (2) the target network firewall policy (TARGET_NETWORK_FIREWALL_POLICY).

gcloud compute firewall-rules migrate --source-network=SOURCE_VPC_NETWORK –target-firewall-policy=TARGET_NETWORK_FIREWALL_POLICY [OTHER_FLAGS]

Please note, a network firewall policy with the same name cannot exist before running this command, since the migration tool will create it.

Additionally, logging will remain unchanged for any migration, meaning that if a VPC firewall rule has logging turned on, the migration tool will leave it on and if logging is turned off, the migration tool will keep it off.

For a more detailed guide, including information on how to change the rule evaluation order, and how to migrate from VPC firewall rules that contain network tags and/or service accounts, please refer to the migration guide. 

Migrate today 

We encourage you to migrate your firewall configuration from VPC firewall rules to the newly introduced network firewall policies to enhance your security posture with a fully distributed, cloud-first stateful inspection firewall service. In addition, migrating to network firewall policies ensures you will have access to the latest firewall features, such as Cloud Firewall Standard. The migration tool is here to help you with this transition. Check out the guide to learn more.

While cloud security skeptics might believe that data in the cloud is just one access configuration mistake away from a breach, the reality is that a well-designed set of defense in depth controls can help minimize the risk of configuration mistakes and other security issues. Our Virtual Private Cloud (VPC) Service Controls can play a vital role in creating an additional layer of security while also making it easier to manage your data in a way that most cloud services can’t do today.

Organizations across industries and business models use cloud services for activities such as processing their data, performing analytics, and deploying systems. VPC Service Controls can empower an organization when deciding how users and data can cross the perimeter of the supported cloud services, if at all. While VPC Service Controls are designed to help stop attackers, they can also enable contextual trusted data sharing (similar to how Zero Trust allows contextual access).

What are VPC Service Controls

VPC Service Controls help administrators define a security perimeter around Google-managed services, which can control communication to and between those services. The Service Controls isolate your Google Cloud resources from unauthorized networks, including the internet. For example, this can help you keep a clear separation between services that are allowed to run in production and services that are not.

VPC Service Controls can help you prevent mistakes that lead to costly data breaches because they control access to your data at a granular level. They add context-aware access controls on these services, and can help you achieve your organization’s Zero Trust access goals.

Like wearing two layers of clothing made from different fabrics to protect you from winter weather, VPC Service Controls may appear similar to Identity and Access Management (IAM) but they come from a different approach to implementing security. IAM enables granular identity based access control; VPC Service Controls create a security perimeter that protects your cloud resources and sets up private connectivity to Google Cloud’s APIs and services. While it’s recommended to use both, VPC Service Controls have an added bonus: They can support blocking data theft during a breach.

The additional layer of security that VPC Service Controls offer customers is challenging to achieve with on-premise systems or even with other cloud providers. You can think of it as an firewall for APIs that also adds a logical security control around three paths that data can take:

• From the public internet to your resources
• Inside your VPC and the cloud service perimeter
• For service-to-service communication (for example, denying access to someone who wants to load data to BigQuery or exfiltrate data from a BigQuery instance.)

How VPC Service Controls can help stop attackers

VPC Service Controls are used to enforce a security perimeter. They can help isolate resources of multi-tenant Google Cloud services, which can help reduce the risk of data exfiltration or a data breach.

For example, a bank that migrated financial data processing to Google Cloud can use VPC Service Controls to isolate their processing pipeline from public access (or any unauthorized access) by defining a trusted service perimeter.

How VPC Service Controls can enable trusted sharing

VPC Service Controls are used to securely share data across service perimeters with full control over what resource can connect to other resources, or outside the perimeter. This can help mitigate data exfiltration risks stemming from stolen identities, IAM policy misconfigurations, some insider threats, and compromised virtual machines.

Returning to our bank example, that same bank using VPC Service Controls may securely share or access data across Service Perimeters and Organizations. They may allow access to specific partners and for specific operations.

How VPC Service Controls support Zero Trust access

VPC Service Controls deliver Zero Trust access to multi-tenant Google Cloud services. Clients can restrict access to authorized IPs, client context, user identity, and device parameters while connecting to multi-tenant services from the internet and other services.

A bank can use moving its services to the public cloud as an opportunity to abandon outdated access management approaches and adopt Zero Trust access. VPC Service Controls let them create granular access control policies in Access Context Manager based on attributes such as user location and IP address. For example, it would allow an analyst to only access Big Query from a corporate device on the corporate network during business hours. These policies can help ensure the appropriate security controls are in place when granting access to cloud resources from the Internet.

Next steps with VPC

Check out these pages to learn more about VPC Service Controls for your sensitive cloud deployments, especially for regulated workloads. This blog is the third in our Best Kept Security Secrets series, which includes how to tap into the power of Organization Policy Service and how Cloud EKM can help resolve the cloud trust paradox.

Over the past two decades, Google has innovated to build some of the largest and most secure computing systems in the world. This scale requires us to deliver pioneering approaches to cloud security, which we pass on to our Google Cloud customers. We are committed to solving hard security problems like only Google can, as the tip of the spear of innovation and threat intelligence.

Today we’re excited to share the next step in this journey with the completion of our acquisition of Mandiant, a leader in dynamic cyber defense, threat intelligence and incident response services. Mandiant shares our cybersecurity vision and will join Google Cloud to help organizations improve their threat, incident and exposure management.

Combining Google Cloud’s existing security portfolio with Mandiant’s leading cyber threat intelligence will allow us to deliver a security operations suite to help enterprises globally stay protected at every stage of the security lifecycle. With the scale of Google’s data processing, novel analytics approaches with AI and machine learning, and a focus on eliminating entire classes of threats, Google Cloud and Mandiant will help organizations reinvent security to meet the requirements of our rapidly changing world.

We will retain the Mandiant brand and continue Mandiant’s mission to make every organization secure from cyber threats and confident in their readiness.

Context and threat intelligence from the frontlines

Our goal is to democratize security operations with access to the best threat intelligence and built-in threat detections and responses. Ultimately, we hope to shift the industry to a more proactive approach focused on modernizing Security Operations workflows, personnel, and underlying technologies to achieve an autonomic state of existence – where threat management functions can scale as customers’ needs change and as threats evolve.

Today Google Cloud security customers use our cloud infrastructure to ingest, analyze and retain all their security telemetry across multicloud and on-premise environments. By leveraging our sub-second search across petabytes of information combined with security orchestration, automation and response capabilities, our customers can spend more time defending their organizations.

The addition of Mandiant Threat Intelligence—which is compiled by their team of security and intelligence individuals spread across 22 countries, who serve customers located in 80 countries—will give security practitioners greater visibility and expertise from the frontlines. Mandiant’s experience detecting and responding to sophisticated cyber threat actors will offer Google Cloud customers actionable insights into the threats that matter to their businesses right now. We will continue to share groundbreaking Mandiant threat research to help support organizations, even for those who don’t run on Google Cloud.

Advancing shared fate for security operations

Google Cloud operates in a shared fate model, taking an active stake in the security posture of our customers. For security operations that means helping organizations find and validate potential security issues before they become an incident.

Detecting, investigating and responding to threats is only part of better cyber risk management. It’s also crucial to understand what an organization looks like from an attacker’s perspective and if an organization’s cybersecurity controls are as effective as expected.

By adding Mandiant’s attack surface management capabilities to Google Cloud’s portfolio, organizations will be able to continually monitor assets for exposures, enabling intelligence and red teams to move security programs from reactive to proactive to understand what’s vulnerable, misconfigured and exposed.

Once an organization’s attack surface is understood, validating existing security controls is critical. With Mandiant Security Validation, organizations will be able to continuously validate and measure the effectiveness of their cybersecurity controls across cloud and on-premise environments.

Transforming security operations and incident response

Security leaders and their teams often lack the resources and expertise required to keep pace with today’s ever changing threats. Organizations already harness Google’s security tools, expert advice and rich partner ecosystem to evolve their security program. Google’s Autonomic Security Operations also serves as a prescriptive solution to guide our customers through this modernization journey.

With the addition of Mandiant to the Google Cloud family, we can now offer proven global expertise in comprehensive incident response, strategic readiness and technical assurance to help organizations mitigate threats and reduce business risk before, during and after an incident.

In addition, Google Cloud’s security operations suite will continue to provide a central point of intelligence, analysis and operations across on-premise environments, Google Cloud and other cloud providers. Google Cloud is also deeply committed to supporting our technology and solution partners, and this acquisition will enable system integrators, resellers and managed security service providers to offer broader solutions to customers.

Comments on the news

“The power of stronger partnerships across the cybersecurity ecosystem is critical to driving value for clients and protecting industries around the globe. The combination of Google Cloud and Mandiant and their commitment to multicloud will further support increased collaboration, driving innovation across the cybersecurity industry and augmenting threat research capabilities. We look forward to working with them on this mission.” – Paolo Dal Cin, Global Lead, Accenture Security

“Google’s acquisition of Mandiant, a leader in security advisory, consulting and incident response services will allow Google Cloud to deliver an end-to-end security operations suite with even greater capabilities and services to support customers in their security transformation across cloud and on-premise environments.” – Craig Robinson, Research VP, Security Services, IDC

“Bringing together Mandiant and Google Cloud, two long-time cybersecurity leaders, will advance how companies identify and defend against threats. We look forward to the impact of this acquisition, both for the security industry and the protection of our customers.” – Andy Schworer, Director, Cyber Defense Engineering, Uber

We welcome Mandiant to the Google Cloud team, and together we look forward to helping security teams achieve so much more in defense of their organizations. You can read our release and Kevin Mandia’s blog for more on this exciting news.