Detective controls Stay organized with collections Save and categorize content based on your preferences.
Threat detection and monitoring capabilities are provided using a combination ofbuilt-in security controls from Security Command Center and custom solutions that let youdetect and respond to security events.
Centralized logging for security and audit
The blueprint configures logging capabilities to track and analyze changes toyour Google Cloud resources with logs that are aggregated to a single project.
The following diagram shows how the blueprint aggregates logs from multiplesources in multiple projects into a centralized log sink.
The diagram describes the following:
- Log sinks are configured at the organization node to aggregate logs from allprojects in the resource hierarchy.
- Multiple log sinks are configured to send logs that match a filter todifferent destinations for storage and analytics.
- The
prj-c-loggingproject contains all the resources for log storage andanalytics. - Optionally, you can configure additional tooling to export logs to a SIEM.
The blueprint uses different log sources and includes these logs in the log sinkfilter so that the logs can be exported to a centralized destination. Thefollowing table describes the log sources.
Log source | Description |
|---|---|
You cannot configure, disable, or exclude Admin Activity auditlogs. | |
You cannot configure, disable, or exclude System Event auditlogs. | |
You cannot configure or disable Policy Denied audit logs, but you canoptionally exclude them withexclusionfilters. | |
By default, the blueprint doesn't enable data access logs because thevolume and cost of these logs can be high. To determine whether you shouldenable data access logs, evaluate where your workloads handle sensitive data andconsider whether you have a requirement to enable data access logs for eachservice and environment working with sensitive data. | |
The blueprint enables VPC Flow Logs for every subnet. Theblueprint configureslog samplingto sample 50% of logs to reduce cost. If you create additional subnets,you must ensure that VPC Flow Logs are enabled for eachsubnet. | |
The blueprint enables Firewall Rules Logging for every firewallpolicy rule. If you create additional firewall policy rules for workloads,you must ensure that Firewall Rules Logging is enabled for each newrule. | |
The blueprint enables Cloud DNS logs formanaged zones. If you create additional managed zones, you must enablethose DNS logs. | |
Requires a one-time enablement step that is notautomated by the blueprint. For more information, seeShare data withGoogle Cloud services. | |
Requires a one-time enablement step that is not automated by theblueprint. For more information, seeEnable Access Transparency. |
The following table describes the log sinks and how they are used withsupported destinationsin the blueprint.
Sink | Destination | Purpose |
|---|---|---|
| Logs routed to Cloud Loggingbuckets withLogAnalytics and a linked BigQuery dataset enabled | Actively analyze logs. Run ad hoc investigations by usingLogs Explorer in theconsole, or write SQL queries, reports, and views using thelinkedBigQuery dataset. |
| Store logs long-term for compliance, audit, and incident-trackingpurposes. Optionally, if you have compliance requirements for mandatorydata retention, we recommend that you additionally configureBucketLock. | |
| Export logs to an external platform such as your existingSIEM. This requires additional work to integrate with your SIEM, such asthe following mechanisms:
|
For guidance on enabling additional log types and writing log sink filters, seethelog scoping tool.
Threat monitoring with Security Command Center
We recommend that you activate Security Command Center to automatically detect threats,vulnerabilities, and misconfigurations in your Google Cloud resources.Security Command Center creates security findings from multiple sources including thefollowing:
- Security Health Analytics:detects common vulnerabilities and misconfigurations across Google Cloudresources.
- Attack path exposure:shows a simulated path of how an attacker could exploit your high-valueresources, based on the vulnerabilities and misconfigurations that are detected byother Security Command Center sources.
- Event Threat Detection:applies detection logic and proprietary threat intelligence against your logsto identify threats in near-real time.
- Container Threat Detection:detects common container runtime attacks.
- Virtual Machine Threat Detection:detects potentially malicious applications that are running on virtual machines.
- Web Security Scanner:scans for OWASP Top Ten vulnerabilities in your web-facing applications onCompute Engine, App Engine, or Google Kubernetes Engine.
For more information on the vulnerabilities and threats addressed bySecurity Command Center, seeSecurity Command Center sources.
You must activate Security Command Center after you deploy the blueprint. For instructions,seeOverview of activating Security Command Center.
After you activate Security Command Center, we recommend that you export the findings thatare produced by Security Command Center to your existing tools or processes for triagingand responding to threats. The blueprint creates theprj-c-scc project with aPub/Sub topic to be used for this integration. Depending on yourexisting tools, use one of the following methods to export findings:
- If you use the console to manage security findings directly in Security Command Center,configurefolder-level and project-level rolesfor Security Command Center to let teams view and manage security findings just for theprojects for which they are responsible.
If you use Google SecOps as your SIEM,ingest Google Clouddata toGoogle SecOps.
If you use a SIEM or SOAR tool with integrations to Security Command Center, share datawithCortex XSOAR,Elastic Stack,ServiceNow,Splunk,orQRadar.
If you use an external tool that can ingest findings from Pub/Sub, configurecontinuous exports to Pub/Sub and configure your existing tools to ingest findings from the Pub/Sub topic.
Custom solution for automated log analysis
You might have requirements to create alerts for security events that are basedon custom queries against logs. Custom queries can help supplement thecapabilities of your SIEM by analyzing logs on Google Cloud and exportingonly the events that merit investigation, especially if you don't have thecapacity to export all cloud logs to your SIEM.
The blueprint helps enable this log analysis by setting up a centralized sourceof logs that you can query using a linked BigQuery dataset. Toautomate this capability, you must implement the code sample atbq-log-alertingand extend the foundation capabilities. The sample code lets you regularly querya log source and send a custom finding to Security Command Center.
The following diagram introduces the high-level flow of the automated loganalysis.
The diagram shows the following concepts of automated log analysis:
- Logs from various sources are aggregated into a centralized logs bucket withlog analytics and a linked BigQuery dataset.
- BigQuery views are configured to query logs for the securityevent that you want to monitor.
- Cloud Scheduler pushes an event to a Pub/Sub topic every 15minutes and triggers Cloud Run functions.
- Cloud Run functions queries the views for new events. If it finds events,it pushes them to Security Command Center as custom findings.
- Security Command Center publishes notifications about new findings to anotherPub/Sub topic.
- An external tool such as a SIEM subscribes to the Pub/Sub topicto ingest new findings.
The sample has severalusecasesto query for potentially suspicious behavior. Examples include a login from alist of super admins or other highly privileged accounts that you specify,changes to logging settings, or changes to network routes. You can extend theuse cases by writing new query views for your requirements. Write your ownqueries or referencesecurity log analyticsfor a library of SQL queries to help you analyze Google Cloud logs.
Custom solution to respond to asset changes
To respond to events in real time, we recommend that you use Cloud Asset Inventory tomonitor asset changes.In this custom solution, an asset feed is configured to trigger notifications toPub/Sub about changes to resources in real time, and thenCloud Run functions runs custom code to enforce your own business logicbased on whether the change should be allowed.
The blueprint has an example of this custom governance solution that monitorsfor IAM changes that add highly sensitive roles including Organization Admin,Owner, and Editor. The following diagram describes this solution.
The previous diagram shows these concepts:
- Changes are made to an allow policy.
- The Cloud Asset Inventory feed sends a real-time notification about the allowpolicy change to Pub/Sub.
- Pub/Sub triggers a function.
- Cloud Run functions runs custom code to enforce your policy. Theexample function has logic to assess if the change has added the OrganizationAdmin, Owner, or Editor roles to an allow policy. If so, the functioncreatesa custom securityfinding andsends it to Security Command Center.
- Optionally, you can use this model to automate remediation efforts. Writeadditional business logic in Cloud Run functions to automatically takeaction on the finding, such as reverting the allow policy to its previousstate.
In addition, you can extend the infrastructure and logic used by this samplesolution to add custom responses to other events that are important to yourbusiness.
What's next
- Read aboutpreventativecontrols(next document in this series).
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-05-15 UTC.