Detective controls

Last reviewed 2022-12-21 UTC

Detective controls use platform telemetry to detect misconfigurations, vulnerabilities, and potentially malicious activity in the cloud environment. As shown in the diagram below, the example.com reference architecture has extensive detective controls to support its overall security posture.

The example.com architecture includes the following detective controls:

• Google security sources through Security Command Center, including security misconfiguration information and vulnerability changes. (For details, see the next section.)
• Connection of Google Cloud logs to Chronicle.
• Asset changes and policy compliance notifications from Cloud Asset Inventory.
• Logs from Google Cloud Logging (including Google Workspace Audit logs) that are sent to the SIEM tool.
• Custom findings from a serverless BigQuery-based tool.

In addition, if you have existing event sources from any of our third-party providers or have created your own custom sources and custom findings, you can integrate those findings into Security Command Center.

Security Command Center

Security Command Center provides a single user interface and data platform to aggregate and manage security findings. The example.com architecture uses Security Command Center to aggregate built-in findings from Google security sources. The available set of built-in security sources is dependent on your selection of the Standard or Premium tier as described in Set up Security Command Center. You can aggregate the built-in findings, third-party findings, and custom findings from the BigQuery analysis solution into Security Command Center and then share them with a SIEM using any of the following four options:

• Security Command Center notifications to a Pub/Sub topic
• Continuous exports
• Pre-defined SIEM integrations for Cortex XSOAR, Elastic Stack, Splunk, and QRadar
• Default BigQuery integration

Premium and Standard tiers

Security Command Center is available in two tiers:

• Security Command Center Premium. This tier is focused on customers with strong security requirements, especially enterprise customers. It includes a full suite of vulnerability and threat detection capabilities as well as integration options that include continuous exports, simplified integrations to third-party SIEMs (Cortex XSOAR, Elastic Stack, Splunk, and QRadar), and the automation of response and remediation actions. Security Command Center Premium tier is a paid service.
• Security Command Center Standard. This tier provides a basic subset of the Security Command Center Premium tier features for all customers. Its focus is on enabling customers to discover, identify, alert on, manage, and respond to the critical vulnerabilities in their estate. It includes integration with Pub/Sub notifications and BigQuery exports. Security Command Center Standard tier is available to customers free of charge.

Whether you choose Premium or Standard, you can enable the selected Security Command Center capabilities and manage the setup and configuration of the built-in detectors in the Security Command Center in a unified, centralized way.

The built-in security sources in both Security Command Center Premium tier and Standard tier are set by default to apply to all existing and future folders and projects in your Google Cloud organization. Unless there is a specific special security situation, we strongly recommend that you keep this default setting.

Security sources

Security Command Center aggregates findings from a wide variety of security sources, consisting of native Google provided findings, third-party findings, and customer-generated custom findings. The feature comparison table for the different tiers of Security Command Center lists the security event sources that can be enabled for the example.com reference architecture.

Note: Security Command Center is also integrated with a number of third-party security sources. In addition, your own applications can generate custom findings in Security Command Center through the findings and sources APIs. If your organization uses third-party security sources or custom findings, you can manage the resulting findings through the Security Command Center dashboard. The findings can also be shared with another system like an enterprise SIEM using Security Command Center API notifications.

Setting up basic security alerting

Beyond detection, it's important for you to be able to take action to respond and remediate detected vulnerabilities and threats. Based on your Security Command Center tier, you can configure one of the following methods to connect Security Command Center findings to your downstream alerting systems, ticketing, workflow, SOAR systems, and SIEMs:

• Using the API, the Pub/Sub notification config and topics

• Using the Google Cloud console, continuous exports

Security Command Center Pub/Sub notifications are managed through a set of notification configs. You can create your notification configs using either the gcloud command-line tool or client libraries and the API. To start, you should create a dedicated SCC Alerts project and restrict IAM access to just the users and services that are allowed to change and manage notification configurations. Within the project, you can then set up the Pub/Sub topics to which you will be publishing events. For each topic, you should further restrict access to that topic to only the necessary individuals and services whose duties require access to the security findings information in the topic.

From the Google Cloud console, you can create a continuous export directly from the finding page. You can then manage up to 500 separate continuous exports from the Security Command Center Settings page in the Google Cloud console. Continuous exports let you automate the export of all future findings to Pub/Sub or create filters to export future findings that meet specific criteria. You can filter findings by category, source, asset type, security marks, severity, state, and other variables.

Configuring notifications and continuous exports

After the security-alerting project is created and the topics have been created, you should define your notification configs. For detailed instructions, see Setting up finding notifications in the Security Command Center documentation. For information about managing notification configurations, see Creating and managing Notification Configs, and for information about filtering notifications, see Filtering notifications.

The default quota on notification configuration counts is 500 per organization. If you need more, submit a request to increase your Security Command Center API quota using the Google Cloud console, as shown in the screenshot below.

The first notification config you should create is one that sends all Security Command Center findings to a Pub/Sub topic that you can then connect to your SIEM. You need the following roles:

• Security Center Admin (broad permissions)

  or

  Security Center Notification Config Editor (specific permissions)

• Pub/Sub Admin on the Pub/Sub topic

After you've set up the roles, follow these instructions:

1. In the Google Cloud console, open Cloud Shell, or open a terminal at a computer where you have the Google Cloud CLI installed and configured.

2. Set up the Pub/Sub topic:

   # topic-id = siem-export
   gcloud pubsub topics create topic-id
   export TOPIC_ID=topic-id
   
   # subscription-id = siem-subscription
   gcloud pubsub subscriptions create subscription-id --topic topic-id
   

3. Set up the notification config with the filter:

   export ORGANIZATION_ID=organization-id
   export PUBSUB_PROJECT=project-id
   export GCLOUD_ACCOUNT=[e-mail]
   

4. Grant the gcloud account the required roles and permissions:

   gcloud pubsub topics add-iam-policy-binding
     "projects/$PUBSUB_PROJECT/topics/$TOPIC_ID"
     --member="user:$GCLOUD_ACCOUNT"
     --role="roles/pubsub.admin"
   
   gcloud organizations add-iam-policy-binding $ORGANIZATION_ID
     --member="user:$GCLOUD_ACCOUNT"
     --role="roles/securitycenter.notificationConfigEditor"
   
   # The topic to which the notifications are published
   PUBSUB_TOPIC="projects/project-id/topics/topic-id"
   
   # The description for the NotificationConfig
   DESCRIPTION="Notifies for active findings"
   
   # Filters for all active findings - both vulnerabilities and threats
   FILTER="state=ACTIVE"
   gcloud alpha scc notifications create notification-name
     --organization "$ORGANIZATION_ID"
     --description "$DESCRIPTION"
     --pubsub-topic $PUBSUB_TOPIC
     --filter $FILTER
   

For the full set of instructions, including information about how to set up notification configurations using the client libraries and API, see Setting up finding notifications.

In contrast to the Cloud Shell and API steps required to set up notification configs, you can directly create customized and filtered continuous export streams directly from the findings page in the Google Cloud console. For more information, see Exporting Security Command Center data.

Matching the notification configurations and continuous exports to your organization's hierarchy

You can use the definition and organization of both notification topics and continuous exports to configure the routing of security alerts to the appropriate teams within your organization. Security Command Center enables you to create and store a set of notification configurations, each of which is a unique combination of selection filter and Pub/Sub topic. You match your specific requirements and enforce IAM access policies to security findings by controlling the following:

• The number of notification configs that you create.
• The selection filter in each config.
• The name of the topic where the selected and filtered findings events are published.

Similarly, Security Command Center enables you to create and manage up to 500 different continuous exports, each with its own unique filter and topic name.

The following sections describe four examples of successful notification configuration and topic patterns.

Example	Description
One security queue	The simplest pattern is just one notification config, with the selection filter set for all projects and all findings categories and the target set to just one topic (for example, gcp-security-alerts). This pattern is for customers who want all Google Cloud security vulnerability and threat findings to be routed to a single centralized security operations center (SOC). For continuous exports, you can just configure one stream and one export filter.
By line of business	You should create multiple separate notification configs when you've adopted the approach where each line of business has its own SOC and therefore owns the end-to-end security responsibilities for your infrastructure, workloads, and applications. Then you should set up a unique Security Command Center notification config and a dedicated topic for each line-of-business SOC. The selection filter in the notification config should select all projects within the scope of the line of business and select all findings categories*. *This configuration enables IAM control and separation on the dedicated topics between each line-of-business team so that each team has access to and receives only the vulnerability and threat signals relevant to them. For continuous exports you could just configure one stream and one export filter per each line-of-business SOC.
Cloud DevSecOps	Similarly, you should create multiple separate notification configs or continuous exports when you've adopted the approach where each application team owns the end-to-end security responsibilities for their infrastructure, workloads, and applications. Then you should set up a unique Security Command Center notification config along with a dedicated topic for each application team. The selection filter in the notification config should select all projects within the scope of the application team and all findings categories. This configuration enables IAM control and separation on the dedicated topics between each application team so each application team has access to and receives only the vulnerability and threat signals relevant to them.
By Security finding category	You should create separate individual notification configs or continuous exports when you've adopted the approach where different types of security findings are handled by different customer teams. The most common example of this is when you've chosen to separate the response and remediation of vulnerabilities and misconfigurations from those of live, active threats. We've seen many customers route the first to their cloud security team and the second to their SOC. In this example case, you can set up a unique Security Command Center notification config and a dedicated Pub/Sub topic for the two teams. The selection filter in the notification config for misconfigurations and vulnerabilities should select all projects and all the finding sources for vulnerabilities (for example, Security Health Analytics and Web Security Scanner). The selection filter in the notification config for threats should select all projects and all the finding sources for threats (for example, Event Threat Detection, Container Threat Detection, and Abuse Anomaly Detection).

Vulnerability and drift detection

Configuration drift refers to changes in configuration away from a predefined standard or baseline. Over time, as a solution evolves, a certain amount of drift is necessary, but for security or stability reasons, some configuration details should not be violated. Managing drift can be a manual process where an administrator is notified and then takes action where needed. But it can also be automated for specific changes, reverting a change that violates a policy.

Built-in drift detection using Security Command Center Premium tier

Security Command Center Premium tier includes Security Health Analytics, which automatically runs more than 140 different misconfiguration and vulnerability checks daily against all the Security Command Center-supported resources in your organization. The resulting assessments are listed in the Vulnerabilities tab of the Security Command Center dashboard. You can view and explore the data either at the organization level or for specific sets of projects. You can also further filter the data by status, category, recommendation, severity, active or inactive status, and compliance benchmark. Then in the Compliance tab, the assessment results are specifically matched against CIS 1.0, CIS 1.1, CIS 1.2, NIST 800-53, PCI-DSS v3.2.1 and ISO 27001 benchmarks and summarized for either the full organization or for a specific set of customer-selected projects. Examples of both tabs are shown in the following screenshots.

This screenshot shows the Vulnerability tab in Security Command Center Premium tier.

This screenshot shows the Compliance tab in Security Command Center Premium tier.

With Security Command Center, you can set up different notification configs or continuous exports to generate alerts on changes in the Security Health Analytics findings to help you identify drift in the configurations of the resources that you care about. In addition, in the Security Command Center dashboard, you can use the Asset Changed view and Findings Changed view to discover and explore changes in user-selected time ranges (for example, last hour, last day, last 7 days, and last 30 days). Examples of both tabs are shown in the following screenshots.

This screenshot shows the Asset Changed tab in the Security Command Center dashboard.

This screenshot shows the Findings Changed tab in the Security Command Center dashboard.

In the dashboards, you can explore the time ranges relative to now—that is, to the current time. If instead you want the reference point to be a different time, you can use either the Security Command Center command-line interface or the API or client libraries to set your own reference point.

Managed web vulnerability scans

If you deploy web applications, you should also leverage Security Command Center Premium tier's built-in managed web vulnerability scans. Web Security Scanner currently provides 20 built-in web vulnerability detections that cover the OWASP top 10. Managed scans automatically run once each week to detect and scan public web endpoints.

Rapid Vulnerability Detection

Rapid Vulnerability Detection scans networks and web applications to detect weak credentials, incomplete software installations, and other critical vulnerabilities that have a high likelihood of being exploited.

Active threat detection

In addition to enabling built-in vulnerability and misconfiguration assessments and threat prevention, you should also leverage Security Command Center Premium tier's built-in active threat detection capabilities. The initial set that's built in to Security Command Center Premium tier includes Event Threat Detection and Container Threat Detection.

Event Threat Detection

Event Threat Detection is a built-in service with Security Command Center Premium tier that detects threats that target your Google Cloud assets. It provides near real-time detection of threats from platform logs, network logs, and compute logs, and it leverages native Google threat intelligence and detection algorithms. Findings are automatically written to Security Command Center and can also be exported to Cloud Logging. Event Threat Detection performs basic deduplication on findings for users and is enabled by default when you're using Security Command Center Premium tier.

Container Threat Detection

Container Threat Detection is a built-in service with Security Command Center Premium tier that detects threats that target Google Kubernetes Engine (GKE) containers. It provides near real-time detection of reverse shell execution, suspicious binary execution, and the linking of suspicious libraries. Container Threat Detection is uniquely able to make the connection between containers and underlying physical nodes at the time of threat detection.

To use Container Threat Detection, you must run the latest Container-Optimized OS image for your GKE environment. Container Threat Detection automatically deploys and manages a daemonset container on every node to transmit data plus additional information that identifies the container. Findings are automatically written to Security Command Center and Cloud Logging.

Virtual Machine Threat Detection

Virtual Machine Threat Detection detects cryptocurrency mining applications running inside VM instances.

Sensitive Actions Service

Sensitive Actions Service automatically monitors all of your organization's Admin Activity audit logs for sensitive actions. Admin Activity audit logs are always on, so you do not need to enable or otherwise configure them.

Real-time compliance monitoring of custom policies

To monitor compliance of custom policies in real time, the example.com architecture uses Cloud Asset Inventory real-time notifications. Cloud Asset Inventory can send a Pub/Sub message for each configuration change to a specific asset name or to an asset type. The message triggers a Cloud Function to examine the change. If that change represents a policy violation, the Cloud Function can take action such as reverting the change or notifying an administrator.

One policy that's monitored in example.com is external Gmail accounts that are being granted any permissions to example.com projects. A Cloud Function is used to check when an IAM policy is created or modified that has a Gmail address as a member. If the Cloud Function detects that the policy has been violated, the Cloud Function reverts the change and sends a custom finding to Security Command Center. The following diagram shows this configuration. You can extend policies to monitor compliance across assets in your organization.

Cloud Asset Inventory also enables you to export configuration metadata to a BigQuery table for in-depth analysis. When the data is in BigQuery, you can use SQL queries to explore the configuration and build reports. The following query shows an example to detect IAM policies that grant access to a Gmail account.

SELECT name, asset_type, bindings.role
FROM `PROJECT_ID.DATASET_ID.TABLE_NAME`
JOIN UNNEST(iam_policy.bindings) AS bindings
JOIN UNNEST(bindings.members) AS members
WHERE members like "[e-mail]"

What's next

• Read about integrating with monitoring tools (next document in this series).