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.

Can you keep a secret? Many people struggle to keep secrets. So do organizations. An organization’s digital credentials — its passwords, API keys, tokens, and encryption keys baked into its software code — are its vital secrets, used to authenticate access to protected resources and services.    

The security of these secrets represent one of the biggest risks that enterprises must manage when securing application infrastructure and environments. Fortunately, we have an important tool to help our customers better manage their secrets: Google Cloud Secret Manager. 

Secret Manager is a secure and efficient tool to centrally store, access, manage, and audit your organization’s secrets. As we noted in our April 2023 Threat Horizons Report, insufficient management of credentials and keys is now one of the top security issues facing cloud customers today. In particular, we have observed service account keys being used for everything from insider threats to cross-cloud breaches to intellectual property espionage.

Along with the increasing popularity of DevOps, secrets are used throughout development. In some cases, secrets are coded as plaintext into configuration files or directly into functions, where they can end up exposed in code repositories. If compromised, secrets can be used to gain unauthorized privileged access to enterprise data, infiltrate critical systems, and launch attacks.

Secret Manager can help organizations better manage their secrets even as concerns over potential security breaches grow. Organizations must consider the following four points during their secrets management risk analysis: 

1. Secrets sprawl: As organizations move more workloads to the cloud, the number of secrets they need to manage increases exponentially. This can lead to secrets sprawl, where secrets are stored in a variety of different locations, making it difficult to track and manage them.
2. Human error: Humans are fallible, and this is especially true when it comes to managing secrets. Mistakes, such as accidentally sharing a secret with the wrong person or the misconfiguration of a secret management tool, can have serious consequences.
3. Compliance violations: Organizations that handle sensitive data are subject to a variety of compliance regulations, including PCI-DSS, SOC 2, HIPAA, and GDPR. Without proper management, secrets could lead to potential compliance violations. 
4. Downtime: If secrets are not properly managed or rotated, it could lead to downtime for applications and services that rely on them.

Secret Manager can enable IT teams to keep track of secrets by providing a centralized place to store and manage them. You can access secrets directly from the Secret Manager console, or use the Secret Manager API or SDKs. Secret Manager is also designed to scale with your application. You can store as many secrets as you need without performance issues, and its API-first design lets you extend and integrate into other existing systems. 

Secret Manager integrations in Google Cloud

In many cases, developers save secret configuration details as plaintext in code for ease of use. There are two main risks associated with this approach:

• Anyone with access to secrets can see and copy them. There is no way to enforce any auditing or access controls practices here.
• It becomes difficult to move code between dev, test, and production environments.

Cloud-centered integrations supported by Secret Manager with other Google Cloud services in the software supply chain make it easier and safer to store and access sensitive information. 

The tool is about the secret information being made securely available in build or runtime.

Secret Manager integrations also can play a role in securing sensitive information in the software supply chain:

1. Integration with CI/CD systems used to build and deploy your software

Cloud Code integration can help developers build more secure applications by preventing hard-coding of sensitive configuration data such as passwords, credentials, and tokens in the codebase. It replaces them with secrets which can be programmatically fetched as required. You can create, access, and modify secrets directly from within your favorite IDE without having to navigate away from it. Integration is available for VS Code, IntelliJ, and Cloud Shell Editor.

Cloud Functions integration lets you access and expose secrets as environment variables or as a volume via the filesystem.

Cloud Build: To handle sensitive data in builds, you can store them in Secret Manager and then configure the build steps to access the information directly. In the build steps, you can associate the value of a secret to an environment and you can access this value via an environment variable from scripts or processes. Two common uses for fetching sensitive dependencies during build time are:

• Storing Docker authentication credentials for pull/push of images to Docker hub.
• Creating GitHub pull requests in response to builds.

2. Integration with runtime engines

Cloud Run: Native integration makes it easy to mount secrets in cloud run services. Using this integration, secrets can be made available to containers either as volume mounts or as env variables. Sensitive dependencies can be stored in environment variables, by referencing a secret name stored in Secret Manager instead of storing it as a plain text environment variable. This secret access operation can be done directly from the Cloud Run console without changing a single line of source code. 

If code reads secrets from a file instead of an env variable, the “mounted as volume” option can be used to make secrets look like files to the env vars. During service deployment, the service account used to run the containers are checked to see if they have the required permissions or not, preventing any unwanted access.

Kubernetes and GKE: The CSI driver–provider solution is an open-source work that provides integration with K8s. The driver lets customers centrally store their secrets in Google Secret Manager and consume them in a kubernetes native manner, as files mounted in K8s pods. The solution also comes with additional syncing capabilities. This method of consuming secrets also allows users to take advantage of SM’s capabilities like versioning, managed rotation, default/CMEK encryption and cloud-focused integrations with other Google Cloud services. Work is currently ongoing to provide official support to the driver solution as a GKE component.

Is Secret Manager right for my organization?

Developers carry a big responsibility to protect the sensitive data they are entrusted to work with, and keep secrets out of their code. However, organizations also have a responsibility to provide the tools and solutions needed to help their teams deliver on these expectations. Secret Manager makes it straightforward for developers to store and manage secrets while improving security. 

To learn more about Secret Manager, please review these resources: 

• Overview of Secret Manager
• Manage your Cloud Run secrets securely with Secret Manager (video)

Read the previous Best Kept Security Secrets blogs here:

• How VPC Service Controls can help build defense in depth
• Tap into the power of Organization Policy Service
• How Cloud EKM can help resolve the cloud trust paradox
• How Assured Workloads accelerates security and compliance

More people than ever have been conducting more of their lives online due to the COVID-19 pandemic. This creates a new landscape for fraudsters to create and release new attacks. Research commissioned by Forrester Consulting showed 84% of companies have seen an increase in bot attacks. 71% of organizations have seen an increase in the amount of successful attacks. 65% of businesses have experienced more frequent attacks and greater revenue loss due to bot attacks. With so many people visiting government websites to learn more about the COVID-19 vaccine, make vaccine appointments, or file for unemployment, these web pages have become prime targets for bot attacks and other abusive activities. But reCAPTCHA Enterprise has helped state governments protect COVID-19 vaccine registration portals and unemployment claims portals from abusive activities.

Assisting with unemployment claims during COVID-19

Alongside the wave of unemployment claims caused by COVID-19, many state government agencies, such as Wisconsin’s Workforce Development, have seen an increase in attempted malicious bot logins on their external websites. Many states have had malicious actors visit unemployment claims portals and enter stolen credentials to file fraudulent unemployment claims. Because many unemployment claims portals are mandated to pay a recipient within 2 weeks, the claims portal processes this fraudulent information and bad actors receive unemployment checks weeks before their false claims are recognized. By then, the fraudsters have their money and have repeated this process using other stolen credentials.

reCAPTCHA Enterprise helps state governments reduce false claims by preventing adversaries from automatically reusing credentials on unemployment claims portals. reCAPTCHA Enterprise’s scale and speed to determine fraudster behavior across the Internet helped some of the largest states in the United States, such as Texas. 

Registering for the COVID-19 Vaccine and accessing state-sponsored resources

Several states, such as Pennsylvania, are challenged by web traffic that fluctuates based on the COVID-19 Vaccine Phase. For example, during Phase 1, there was a large increase in web traffic from both humans and bots because of the demand for the very few available vaccination slots. As more states move into Phase 2 and Phase 3, and the vaccine is more widely available, traffic is increasing because bad actors know more people are coming to these websites to register to be vaccinated. 

reCAPTCHA Enterprise was implemented to stop bad actors from scripting bots to book vaccine appointments and then sell those appointment slots on another website for profit. These fake web pages are falsely promoted as websites where people can register for the vaccine. Vaccine appointments are not the only government system from which fraudsters try to profit. Transportation and social service departments also face frequent attacks, wherein fraudsters try to profit by booking and then selling appointments with those organizations. 

Fending off these attacks was made easier thanks to reCAPTCHA Enterprise, a frictionless fraud detection service that leverages our experience from more than a decade of defending the internet and data for our network of more than 5 million sites. The reCAPTCHA Enterprise platform can understand fraudulent behavior, introduce friction to block bots from booking appointments, and allow legitimate users to access the vaccine portals and other state portals. 

Because reCAPTCHA Enterprise does not require end users to complete captcha challenges, several state governments installed reCAPTCHA Enterprise across search, login, and registration web pages. State governments are also placing reCAPTCHA Enterprise on webpages where end users can access healthcare, receive assistance for housing or food, register motor vehicles, or propose legislation. With reCAPTCHA Enterprise on more pages, it becomes more difficult for malicious software or bots to carry out their attacks against different pages, but not for end users to browse, login into accounts, book appointments, or apply for resources. Because reCAPTCHA Enterprise requires no action from end users to stop fraud, state governments implemented reCAPTCHA Enterprise on all points of interaction on their webpages to ensure maximum security without impacting the user experience. 

Providing security everywhere and pricing for all

Many state governments are familiar with buying cloud services in a pay-as-you-go model. reCAPTCHA Enterprise eased the purchasing process by providing state governments with predictable, scalable, and customizable pricing. State governments know up front how much they can expect to pay each month based on the number of assessments reCAPTCHA Enterprise performs. reCAPTCHA Enterprise’s flexible pricing model keeps pace with the natural fluctuations of visitors to vaccination registration and unemployment claims. reCAPTCHA Enterprise has a dedicated sales team that can tailor pricing to your specific use cases so both your webpages and budget are not compromised. 

reCAPTCHA Enterprise has helped many state governments serve their constituents by making it easier to get vaccinated and collect unemployment. It helps constituents take advantage of public services and makes it more difficult for fraudsters to manipulate and interfere with them. 

To start protecting your web pages from credential stuffing and other attacks, get started with reCAPTCHA Enterprise today.

Our Cloud Data Loss Prevention (Cloud DLP) discovery service can monitor and profile your data warehouse to bring awareness of where sensitive data is stored and processed. Profiling is also useful for confirming that data is not being stored and processed where you don’t want it. 

But how can you make use of this intelligence within your existing security and governance workflows so you can reduce risk? Starting today, we have integrated Cloud DLP’s sensitive-data discovery service with Security Command Center, our platform-native security and risk management solution. By bringing together sensitive data intelligence with your security controls, security teams can identify and act quickly on the vulnerabilities and help address threats that matter for your organization.

Data sensitivity and risk prioritization

Not all security threats, vulnerabilities, and misconfigurations generate an equal degree of risk. Some affect only test data or development environments. But others can place your organization’s sensitive information at risk of exposure or misuse. Understanding what to prioritize is often a big challenge for security professionals.

When this awareness is fed into Security Command Center, it allows your team to prioritize the Security Command Center findings that are driving greater security and compliance risk, and to help make informed decisions as to how to address those issues.

Understanding BigQuery data exfiltration threats

Security Command Center’s threat detection capability can analyze access and copy behavior of BigQuery data to help detect potential risk of exfiltration. With Cloud DLP intelligence on where sensitive data lives in BigQuery tables and datasets, you can now focus and prioritize on the exfiltration findings tied to your sensitive assets.

Remediation and data security posture management

The intelligence from Cloud DLP’s sensitive-data discovery service helps you take a data-first approach to securing your assets.  Use insights like Cloud DLP’s predicted infoType to apply column-level, fine-grained access or dynamic masking policies and consider de-identification to further help reduce the risk of data use operations and improve your overall security, privacy, and compliance posture.

Get started

To get started with richer sensitive data intelligence, enable the connection between Cloud DLP’s discovery service and Security Command Center.  There is no additional cost to enable the integration for users of both products.  

As soon as it’s enabled, you can begin to use your sensitive data intelligence to supercharge your security and support your compliance teams’ work.

Read more about how the sensitive data discovery service can meet your organization’s needs, and how you can get started managing your security posture with Security Command Center.

Security is often seen as a zero-sum game between “go fast” or “stay secure.” We would like to challenge this school of thought and introduce a framework to change that paradigm to a “win-win game,” so you can do both—“go fast” and “stay secure.”

Historically, application security tools have been implemented much like a gate at a parking lot. The parking lot has perimeter-based ingress and egress boom gates. The boom gates let one car through at a time, and vehicles often are backed up at the gates during busy hours. However, there are few controls once you get inside. You can access nearly any space on any level and easily move between levels.

When you apply this analogy to application development, AppSec tools are often implemented as “toll gates” within waterfall-native workflows. Developers are required to get in line, submit to a security scan, and wait to see the results. When the results are produced, developers spend significant time and energy investigating red flags raised by security. This process is slow and, not surprisingly, not very popular with developers. It’s why they often view traditional security programs as inhibitors to innovation.

Guardrails not gates

We suggest a workflow that’s less like a parking lot gate and more like a freeway with common-sense safety measures. Freeways have directive rules for all users. Speed limits, single direction of travel, and mandatory speed reduction zones when exiting contribute to freeway safety. Some freeways implement preventative measures based on these rules, such as physical walls dividing opposite flows of traffic and protective guardrails to reduce collisions and keep vehicles from veering off the road. While driving on a freeway comes with its own complications, there are no boom-style gates blocking your path.

Following the same directive rules, there are detective and responsive controls, such as speed detectors, cameras, signs reminding drivers which direction they are going, and how fast they are traveling. Some freeways have deployed rumble strips to remind a dozing driver to stay in their lane.

Applying lessons from freeways to application development and compliance in the cloud represents the perfect opportunity to build software more securely.

Modern application security tools should be fully automated, largely invisible to developers, and minimize friction within the DevOps pipeline. To do this, these security tools should work the way developers want to work. Security controls should integrate into the development lifecycle early and everywhere. These controls should live within the developer’s preferred tools and create rapid feedback loops so mistakes can be remediated as soon as possible.

A typical compliance cycle looks like this:

Here, we highlight the gap between the desired state and the actual state that becomes problematic when audit times come. This increases the overall cost of the audit and the time spent in generating the evidence of controls.

Instead, this is what we need.

We need the actual state to track the desired state continuously. We need continuous preventative controls to stop insecure resources from being introduced. We need detective controls to find non-compliant resources promptly and constantly. We need responsive controls to fix non-compliant resources automatically. In all, we need continuous compliance.

Infrastructure continuous compliance reference architecture

How do we get started with continuous compliance? Here is the reference architecture that enables you to develop this capability.

The architecture is centered on building a close-loop of directive, preventative, detective and responsive controls. It is also open and extensible. Although we reference Google Cloud architectures in this blog, you can use them for other cloud service platforms or even on-premise

The National Institute of Standards and Technology’s Open Security Controls Assessment Language (OSCAL) is a helpful resource to express your control library in a machine-readable format. OSCAL can allow organizations to define a set of security and privacy requirements, which are represented as controls, which then can be grouped together as a control catalog. Organizations can use these catalogs to establish security and privacy control baselines through a process that may aggregate and tailor controls from multiple source catalogs. Using the OSCAL profile model to express a baseline makes the mappings between the control catalog and the profile explicit and machine-readable.

Directive controls

The starting point of the close-loop is the directive and harmonized controls. Next, you should have control mappings rationalized to the technical controls against your compliance requirements. These requirements can come from various sources, such as the threat landscape of your industry, your internal security policies and standards, your external regulatory compliance, and industry best practice frameworks.

Control mappings will form a Technical Control Library. The library is a dataset mapping out harmonized controls to requirements written in different compliance frameworks. The control mapping justifies the security controls. It builds the linkage between security and compliance and helps you reduce your compliance audit cost. This dataset should be a living document.

An easy first step in building such as library is to begin with the CIS Google Cloud Platform Foundation Benchmark. The benchmark is lightweight and it constitutes foundational security any entity should get right on Google Cloud. In addition, Security Command Center Premium’s Security Health Analytics can help you to monitor your Google Cloud environment against these benchmarks on a continuous basis across all the projects within your organization.

The Technical Control Library will guide the rest of the closed-loop. For every directive control, you should have corresponding preventative control to stop non-compliant resources from being deployed. You should have the detective control to look over the entire environment seeking non-compliant resources. And you should have the responsive control remedying non-compliant resources automatically or kicking off responsive workflow with your Security Operations function. Finally, every policy evaluation point should have a feedback loop to the engineers. A prompt and meaningful feedback loop provides a better engineering experience and increases development velocity in the short run. These feedback loops will breed good behaviors to write better and more secure code in the long run.

Preventive controls

Almost every action on the Google Cloud is an API call, such as when creating, configuring, or deleting resources, so preventative controls are all about API call constraints. There are different wrappers for these API calls, including Infrastructure-as-Code (IaC) solutions such as Terraform or Google Cloud Deployment Manager, the Cloud Console interface, Cloud Shell SDK, Python, or GO SDK.

As with any other application code deployment, the IaC solutions should use a Continuous Integration (CI) solution. On the CI, you could orchestrate IaC constraints, similar to writing unit tests for application code. Since all IaC solutions come in or can be converted to JSON format, you can use Open Policy Agent (OPA) as the IaC constraint solution. OPA’s Rego policy language is declarative and flexible, which allows you to construct almost any policy in Rego.

For the input sources that are not IaC, you could fall back to the organization policies and IAM as these two controls have the closest proximity to Google Cloud. That said, it’s considered a best practice to restrict non-IaC inputs for higher environments such as production-like or production, so you could codify your infrastructure, apply controls and workflows in the source repository.

Detective and responsive controls

Even if you’ve nailed the preventive controls, and the cloud environment is sterile, we still need detective and responsive controls. Here’s why.

For one, not all the controls can be safely implemented as preventative controls in the real world. For instance, we may not fail all the Google Compute Engine deployments at the CI if these VMs have external IP addresses because external IP addresses may be required for a specific software or use cases. Another reason is that we want to produce time-stamped compliance status for audit purposes. Taking the CIS compliance as an example, we could have enforced all the CIS check on the CI and set IaC as the only deployment source for cloud infrastructure.

However, we will still need to demonstrate the runtime CIS compliance report using Security Command Center. Security responsive controls are not limited to remediation actions. They can also take the form of notifications via email, messaging tools, or integration with ITSM systems. If you use Terraform to deploy the infrastructure and use Cloud Function for auto-remediation, you need to pay attention to the Terraform state. Since auto-remediation actions performed by Cloud Function are not recorded in the Terraform state file, you will need to inform the engineers to update the source Terraform code.

The future

The fact that manual processes around security and compliance don’t scale points to automation as the next enabler. The economics of automation require a systemic discipline and holistic enterprise-wide approach to regulatory compliance and cloud risk management.

By defining a data model of the compliance process, the aforementioned OSCAL represents a game-changer for automation in risk management and regulatory compliance. While we realize that adopting “as code” practices is a long-term investment for most of our customers, Risk and Compliance as Code (RCaC) has a number of building blocks to get you started. By adopting the RCaC tenets you shift towards codified policies and infrastructure for a secure cloud transformation. Stay tuned as we introduce exciting new capabilities and features to Google Cloud Risk and Compliance as Code in the months to come.