The European Commission (EC) has recently published new Standard Contractual Clauses (SCCs, also known as Model Contractual Clauses) to help safeguard European personal data. Following the applicable transition period, these new SCCs will replace the SCCs previously adopted by the EC. Google Cloud plans to incorporate the new SCCs into our contracts to help protect our customers’ data and meet the requirements of European privacy legislation.

Like the previous SCCs, these clauses can be used to facilitate lawful transfers of data under certain conditions. By imposing various contractual obligations, SCCs allow personal data subject to the EU’s General Data Protection Regulation (GDPR) to flow to recipients outside the European Economic Area (EEA). The GDPR is an important piece of EU privacy legislation that became applicable in 2018. It requires appropriate safeguards for EEA personal data moving from the EEA to any non-EEA countries that do not meet the EU ‘adequacy’ standard for privacy protection. 

Google Cloud’s industry-leading controls, contractual commitments, and accountability tools have helped organizations across Europe meet stringent data protection regulatory requirements for years. We have provided customers with SCCs since 2012. In 2017, EU Data Protection Authorities confirmed that Google Cloud’s contractual commitments met the legal requirements for transfers of data from the EU to the rest of the world under EU Data Protection Directive 95/46/EC. Google Cloud remains committed to protecting the privacy of our customers and their users, and to helping thems address EU regulatory obligations.  

To learn more about how Google Cloud can help organizations with their compliance efforts, visit our Cloud Compliance resource center.

Twenty years ago, organizations discovered the magic of server virtualization. Among the many benefits of virtualization, it heralded the end of the need for one physical server per application and the beginning of managing software-defined infrastructure. It helped automate building and installing systems, and it helped lay foundations for today’s Continuous Integration/Continuous Delivery mechanisms and DevOps practices. However, the adoption of virtualization was not always smooth and several hurdles stood in its path. Today’s organizations are facing similar obstacles in their journey to the cloud.

Organizations that wanted to virtualize their server environment two decades ago faced a significant challenge that was neither technical nor budgetary, but organizational, stretching across IT teams and beyond. The first team to be concerned about virtualization was the one in charge of installing the physical servers in the racks of the datacenter, managing the physical network connections and operating environmental controls, such as HVAC and power systems. These tasks were drastically reduced, if not outright eliminated.

The second team affected by this shift in technology was the one responsible for installing the operating system and running the post-install procedures. Their job almost completely disappeared as most virtual machines were automatically instantiated from templates.

As a result, successful adoption relied on the ability to smooth these organizational changes. Along the way, training the staff and making sure they acquire the new skills necessary to operate the virtualization infrastructure was critical. And usually, the affected teams eventually found that their new responsibilities were different but still essential to the organization, and perhaps even more appealing.

Virtualizations lessons for cloud transformation regulators

Discussions on virtualization didn’t end with these internal changes when organizations were operating in a regulated environment. They needed to engage closely with their regulators. Regulated organizations often considered the hypervisor solely as an additional layer of software with potential vulnerabilities.

This viewpoint raised risks (such as virtual machine escape) that didn’t exist with physical servers. Even if this is taken into account and the risks mitigated, it should have been considered in balance with all the benefits of machine virtualization, including security benefits such as asset identification, harmonization, and smoother patch management.

While the relevance and benefits of virtualization are now widely accepted, history has repeated itself as similar issues have arisen for organizations facing cloud migrations. When large cloud service providers (CSP) began supporting critical workloads for their customers, regulators increased their oversight over CSPs and issued guidance concerning cloud adoption. This happened in the European financial sector, with guidelines from the European Supervisory Authorities (European Banking Authority, European Securities and Market Authority and European Insurance and Occupational Pensions Authority,) and the coming Digital Operational Resilience Act regulation.

These regulations can help establish trust between providers and customers. As regulator decisions are vital for organizations, there is an opportunity now with cloud technology to balance the risks with the benefits and take into consideration all the ways CSPs can help organizations improve their overall security and compliance levels.

Cultural transformation can drive cloud transformation

Another similarity between cloud transformation and the journey to virtualization is the required internal transformation. When an organization decides to start its journey to the cloud, training its staff with the new technology and tools is a necessary step, but probably not the first nor the most arduous to make. A change of mindset is paramount to fully incorporate all the cloud benefits, in particular regarding security.

This new approach begins with a deep transformation at the organizational level. Organizations should avoid viewing the cloud as a datacenter because there’s so much more potential to cloud technology. This new approach and its accompanying organizational transformation is driven by two factors: The burdens that the CSP removes from the customer, and the new flexibility that software-defined infrastructure brings to the table.

The CSP directly manages several tasks and services, and their security, which means that they’re no longer a direct concern for the customer. These responsibilities include data center management, security-hardened hardware, default encryption for data at rest and data in transit, and resilient network management.

Since all the infrastructure used by the organization to manage its workloads is software defined, it brings much more flexibility to what can be done with it. Software-defined infrastructure can more easily enable security guardrails and continuous compliance that weren’t possible before.

While there’s a temptation to approach an organization’s cloud transformation as merely a “lift and shift” operation from on-premises infrastructure, the reality is that approach reduces the potential gains a cloud transformation can bring to an organization. Moving systems to the cloud accounts for a small portion of the potential impact, while updating the mindset can be truly transformational. Development, architecture and security processes need to be rebuilt; this inevitably requires a deeper transformation of the organization.

The next step is to transform the operations, to align them with the overall organization and the new defined processes, operationalize CI/CD and build DevOps practices. After that, the technological gap will be adjusted, moving the new tools and teaching teams how to best use them.

The important point here is the order of the transformation to manage: organization, operations and technologies (O-O-T) and not the other way round (T-O-O). Of course, these three steps should not be considered completely sequential, as technology plays an important role in the organization and the operations. However, it is essential to support the development of personnel and frameworks to take full advantage of the transformation opportunity, rather than primarily focusing on the tooling.

In addition, at Google Cloud, we believe in a shared fate that goes far beyond the usual shared responsibility model. We think it is part of our duty to help our customers to achieve their goals in their scope of responsibility. We prepare secure landing zones and guide the customers, we bring transparency to security controls and help them with cyber-insurance.

Our shared objective with our customers is to continuously improve security. Our Google Cybersecurity Action Team initiative helps us to be engaged alongside our customers, provide them with necessary guidance, support them in their security and compliance strategies, and assist their organizational and operational transformation in their cloud journey.

• Listen to a related podcast “How to Apply Lessons from Virtualization Transition to Make Cloud Transformation Better”
• Listen to “Preparing for Cloud Migrations from a CISO Perspective, Part 1”
• Read “The journey to the cloud mitigates enterprise risk”
• Also, review “Megatrends drive cloud adoption—and improve security for all”
• Visit Google Cybersecurity Action Team website

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.

Corporate firewalls typically include a massive number of rules, which accumulate over time as new workloads are added. When rules stack up piecemeal like this, misconfigurations occur that, at best, create headaches for security administrators, and at worst, create vulnerabilities that lead to security breaches.  

To address this, we have introduced the Firewall Insights module in our Network Intelligence Center, which provides a single console for managing Google Cloud network visibility, monitoring and troubleshooting. 

What are Firewall insights?

Historically, there hasn’t been an easy way to deal with the accumulation of complicated firewall rules. That was until we created Firewall Insights, which provides metrics reports and insight reports. These two reports contain information about firewall usage and the impact of various firewall rules on your VPC network. Even better, these insights and metrics are integrated into your Google Cloud Console for the VPC firewall and are also available via APIs.

You can use metrics reports to verify that firewall rules are being used appropriately and as intended. This report can uncover leftover rules from the past that are not actively used, review that the firewall rules allow or deny what is intended, perform live debugging of connections dropped, and leverage Cloud Monitoring to discover malicious attempts to access your network. 

You can use insight reports to identify firewall misconfigurations, detect security attacks, and optimize and tighten your security rules.

Let’s take a look at how these reports work.

Metrics Report, a deeper dive

Metrics insights analyzes your VPC firewalls usage by tracking metrics such as firewall hit counts and last used.  Let’s check this out with an example:

When you navigate to your VPC network and click on Firewall, ensure that you have selected Logs, Hit count and also Last hit in the column display options:

After this is enabled, now you should be able to see your VPC firewall rules with the hit count and last hit metrics. In the image below you can see that if logs are not enabled for rules, hit count and last hit metrics will not be collected. If logs are enabled, these details are collected, and shown in the VPC firewalls console.

As you can see in Figure 1.2, each firewall rule which has logging enabled will show hit counts, so based on the example above, the rule “uc1-db4-deny-http”  has been hit 109,154 times, the last time being 2021-03-10 (13:10:00). If you want to dive even deeper, you can click on the hit count and this will bring you to the logs viewer page where you can expand these logs and analyze all the details:

In order to enable logs for a particular firewall rule, you can edit it and turn logs on. By default, metadata is added in firewall logs. If you want to reduce the log size, you can do so by excluding these additional fields. Excluding these metadata fields will not impact the functionality of Firewall Insights.

From the “Firewall” page, you can also multi-select a group of firewall rules and turn on all logs at once.

Firewall rule usage metrics are accurate only for the period of time during which Firewall Rules Logging is enabled.

Insights Report, a deeper dive

Insights Report provides an intelligent analysis of the configuration of your firewalls. A report can contain one or more insights. 

We will see examples now about the different insight reports which include:

• Shadowed firewall rules
• Allow rules with no hit in the last six weeks
• Deny rules with hits in the last 24 hours

By definition, a shadowed rule is a VPC firewall rule that is completely overshadowed by one or more firewall rules with higher or equal priority. We call that shadowing rules. Let’s see an example on how to find shadowed rules:Let’s say that you try to use ping between two VMs but it fails. Let’s take a look at the firewall rules applied to the VM:

If we look closely, we can see that there are two rules with the same target tag, and those are almost identical except their source IP range. The IP range of the deny rule “uc1-app2-deny-all” includes the IP range of the rule allow “uc1-app2-allow-app1”. Therefore, we can see that “uc1-app2-allow-app1” is shadowed by “uc1-app2-deny-all”, and the ping between these VMs failed due to that.

To avoid such incidents in the future, Firewall Insights provides you with a convenient list of rules overshadowed by other firewall rules.

To see shadowed rules, you can click on the column selector, and add “Insights” to the firewall and route details:

Once this is applied, you will be able to see shadowed rules here:

Alternatively, you can navigate to Network Intelligence > Firewall Insights, where we will see the shadowed rule report:

If we click on the insight we will get more details:

Going back to the firewall insights card (Figure 1.8), we can also identify that “uc1-db4-allow-app3” is shadowed by a combination of two rules and if we clicked on the insight this would provide all the details.

From the Firewall Insights dashboard, let’s move on to “allow rules with no hit”, where we can see firewall rules that have not logged any hits in the past six weeks. Such rules could be as a result of a misconfiguration, or leftover rules from past deployments. Tighten your security boundaries by identifying and removing such rules. If we go back to Network Intelligence > Firewall Insights, we can see allow rules with no hit:

We can drill down to view the full list of rules with no hit. We can see, for instance, one of the rules, the bottom one “uc2-app1-allow-internet”, might be a leftover rule to allow internet access from a past deployment, which means it has little likelihood of being hit in the future. So you may want to consider removing it from the rule set:

Click on the firewall rule to review all the details, and take a look at the prediction, which is made based on the hit pattern that we saw for similar rules in the same organization:

Let’s go back to the Firewall Insights dashboard and move on to the last category, “deny rules with hits in the last 24 hours”, which help you capture the traffic blocked by deny rules. These traffic types could indicate external attacks into your VPC network, or compromised VM instances attempting to send traffic out of your network. Let’s examine future hit prediction on a firewall rule. Navigate to Network Intelligence > Firewall Insights and take a look at the deny rules with hits card:

If your click on the “uc4-web-deny-web” rule, you can see the hit count monitoring, and if you click on the hit number we can dive deeper in the logs:

These tips should help you effectively leverage Firewall Insights to gain better control over a massive firewall rule set. Automate shadowed rule detection, quickly troubleshoot misconfigured rules, effortlessly pinpoint the overgranting rules hidden in the rule set, and identify the failed attempts to break into your network that were rejected by your firewall rules. 

To learn more about Firewall Insights, please refer to our documentation. Additionally, to see how we’re advancing intelligent automation in network security, check our recent blog post.