Google Security Operations SIEM Use Case Guide 1

Reducing Alert Volume and Surfacing Targeted Threats

Overview

Every internet-facing organization is bombarded by automated scanners, bots, and opportunistic exploitation tools, generating thousands of firewall alerts per day that are not real threats. This leads to alert fatigue that overwhelms SOC analysts, causing them to ignore alerts and miss real targeted attacks that get buried in the noise.

The GreyNoise Solution

GreyNoise maintains a global sensor network that observes which IPs are conducting mass, indiscriminate internet scanning. By integrating GreyNoise threat indicators directly into Google SecOps, it can automatically identify and remove known mass-scanning traffic from your Google SecOps alerts. The residual traffic after filtering, traffic that is unknown to GreyNoise, carries a higher probability of being a genuine, targeted attack against your organization.

The core logic is simple:

"If an IP is hitting everyone on the internet, it is not targeting YOU. Filter it out."

Prerequisites

Ensure your environment meets these prerequisites before beginning the setup:

Tools and Access

PrerequisitesDetails
Google SecOpsA Google SecOps Instance with an Admin role user.
Google Cloud PlatformA Google Cloud Platform project, with deployed ingestion scripts for GreyNoise. Note: Access to a GCP project with sufficient permissions to enable APIs, create service accounts, IAM bindings, GCS buckets, Cloud Functions, Cloud Scheduler jobs, and Secret Manager secrets.
GreyNoise API KeyGreyNoise API key to configure during deploying ingestion script.
Firewall Logsfirewall logs/events from a third-party product
Log FieldsLogs must contain: principal.ip, and network.direction fields

Implementation Steps

To achieve the use case, follow the steps below:

Step 1: Connectivity Verification of the GreyNoise Data Ingestion Script

Before building any detection logic, confirm that the GCP Cloud Function is deployed and actively ingesting indicators into Google SecOps. Navigate to Investigation > SIEM Search and run the following UDM filter to confirm ingested data is present:

graph.metadata.event_metadata.base_labels.log_types = "GREYNOISE"

Expected Result: You should see GreyNoise IP entities appearing in the Results panel. If no results are returned, check the Cloud Function logs in GCP Cloud Logging for any errors before proceeding.

Step 2: Verify if Firewall Logs exist in the instance

Confirm that your firewall logs are present in Google SecOps SIEM. In the SIEM Search (UDM Search), filter for network connection events:

metadata.event_type = "NETWORK_CONNECTION"

Expected Result: You should see the firewall/network events populated in the results panel before proceeding. Validate that the result set includes records with a populated principal.ip field. This field serves as the join key for GreyNoise correlation.

Step 3: Create Detection Rule

Create a YARA-L detection rule in Google SecOps that correlates inbound network events with GreyNoise IP indicators. This rule is the core mechanism for surfacing targeted threats while filtering noise.

Detection Rule:

// Use case 1: Reducing Alert Volume and Surfacing Targeted Threats
// Rule declaration: defines a YARA-L rule
rule greynoise_intelligence_inbound_traffic_unknown_to_greynoise {
  // Metadata section: non-functional fields used for documentation and triage
  meta:
    // Identifies who wrote or owns this rule
    author          = "GreyNoise Intelligence"
    // Human-readable name for display
    rule_name       = "GreyNoise Intelligence Inbound Traffic Unknown to Greynoise"
    // Explains what the rule is designed to detect
    description = "Detects inbound traffic from Source IPs not known to GreyNoise with 10+ occurrences."
    // Indicates the risk level if this rule fires
    severity        = "High"
    // Indicates the response urgency level for this alert
    priority        = "High"
  // Events section: defines the UDM field filters that must be satisfied
  events:
    // Capture inbound network traffic from your perimeter devices
    // Filter to only network connection events
    $network.metadata.event_type = "NETWORK_CONNECTION"
    // Filter to only inbound traffic
    $network.network.direction = "INBOUND"
    // Bind the source (principal) IP address to a placeholder variable for correlation
    $network.principal.ip = $correlation_ip
    // Exclude events where the source IP is empty or null
    $correlation_ip != ""
    // Join logic: Check if the Source IP exists in the GreyNoise dataset
    // Filter the GreyNoise enrichment records by their log type label
    $greynoise.graph.metadata.event_metadata.base_labels.log_types = "GREYNOISE"
    // Ensure the enrichment record comes from the GreyNoise Intelligence product
    $greynoise.graph.metadata.product_name = "GreyNoise Intelligence"
    // Confirm the GreyNoise entity being evaluated is an IP address type
    $greynoise.graph.metadata.entity_type = "IP_ADDRESS"
    // Join the GreyNoise entity IP to the same correlation variable used in network events
    $greynoise.graph.entity.ip = $correlation_ip
  // Match section: groups correlated events
  match:
    // Aggregate all events sharing the same $correlation_ip within a 15-minute window
    $correlation_ip over 15m
  // Outcome section: computes derived fields attached to the generated alert
  outcome:
    // Count the total number of distinct network connection events in the window
    $connection_count = count($network.metadata.id)
    // Count the number of unique destination IPs targeted by this source IP
    $unique_targets_hit = count_distinct($network.target.ip)
    // Count the number of unique destination ports targeted by this source IP
    $targeted_port_count = count_distinct($network.target.port)
  // Condition section: final boolean logic that should match
  condition:
    // Fire ONLY when: no GreyNoise record exists for the IP,
    // at least one matching network event exists,
    // and 10 or more network events were seen in the window
    !$greynoise and $network and #network >= 10
}

Create & Enable Detection Rule

  1. From Google SecOps SIEM, navigate to Detection > Rules & Detections.

  2. Go to the Rules Editor Tab, click on the + button.

  3. Copy and paste the Detection Rule provided above in the editor.

  4. Click on SAVE NEW RULE.

  5. To generate detections, Enable Detecting, and to generate alerts, Enable Alerting.

  6. Click the Rules Dashboard tab to see all rules.

  7. Search or browse for the rule you want to activate. Click on the 3 dots in the top right corner for the specific rule and toggle Live Rule as enabled to activate the Detection Rule.

See Google SecOps: Detection Rules for more information.

Step 4: Trigger Retrohunt and View Alerts

Once the rule is live and alerting is enabled, it will immediately begin triggering alerts for matching events. To run the rule for a specific time range, we need to run YARA-L retrohunt by following these steps:

Steps to run YARA-L Retrohunt:

  1. From Google SecOps SIEM, navigate to Detection > Rules & Detections.

  2. Click the Rules Dashboard tab to see all rules.

  3. Search or browse for the rule. Click the 3 dots in the top-right corner for the specific rule's row.

  4. Click on the YARA-L Retrohunt.

    Note: You can change the Run Frequency as needed.

  5. Select the time range.

  6. Click on Run.

Wait approximately five minutes to verify if alerts have been generated. Even without running a YARA-L retrohunt, the rule will automatically trigger alerts for new incoming events as long as it is live and alerting is enabled.

Follow these steps to view alerts in Google SecOps:

Steps to view alerts

  1. From Google SecOps SIEM, navigate to Detection > Rules & Detections.

  2. Click the Rules Dashboard tab to see all rules.

  3. Search or browse for the rule. Click the 3 dots in the top-right corner for the specific rule's row.

  4. Click on the View Rule Detections.

  5. The list of Alerts will be visible in the Detections section, with the Detection Type column set to Alert.

  6. To view the outcome variables of Alert, click on the Alert row, then on the Alert viewer tab, and click on Variables.

Understanding the Output

The YARA-L detection rule correlates inbound network connection events with GreyNoise intelligence data, then progressively filters activity to surface only the most relevant and potentially targeted threats:

  • Targets only inbound network traffic by filtering on network.direction = "INBOUND".
  • Correlates every inbound source IP against ingested GreyNoise intelligence indicators using the shared principal.ip value.
  • Excludes all IPs already recognized by GreyNoise intelligence - removing known internet-wide scanners, mass reconnaissance platforms, and background internet noise.
  • Retains only source IPs generating 10 or more events within a 15 minutes window - eliminating low-frequency opportunistic traffic and random connection attempts.
  • Aggregates useful investigation context, including:
    • Total connection count
    • Number of unique targets contacted
    • Number of distinct destination ports targeted
  • Surfaces the highest-confidence candidates for analyst investigation: inbound IPs that repeatedly interact with the environment and are not recognized by GreyNoise intelligence.

Result: Out of 6955 raw events, 11 IPs survived. What remains is a focused set of inbound source IPs demonstrating repeated activity against your environment without matching known internet scanning behavior. These IPs represent higher-priority candidates for immediate triage and investigation, as they may indicate exploitation attempts or malicious activity that has not yet been classified as widespread internet noise.

Alert Volume Reduction

Filter / LogicWhat It RemovesImpact on Alert Volume
network.direction = "INBOUND"Internal traffic and standard outbound browsing activityHigh: Keeps analysts laser-focused on external threats rather than internet noise.
!$greynoiseKnown GreyNoise-classified internet scanners and background noiseMaximum: Eliminates known "internet background noise" that requires no action.
#network >= 10One-off probes and low-frequency internet noiseHigh: Retains only persistent or repeated activity patterns
match $correlation_ip over 15mShort-lived or isolated connectionsMedium: Highlights sustained reconnaissance behavior
The Net Result47 out of 50 events dropped.94% Reduction: Only 3 high-risk IPs require human investigation.

Results and Impact

Before vs After GreyNoise

Before GreyNoise FilteringAfter GreyNoise Filtering
Large volumes of inbound perimeter alertsOnly high-confidence suspicious IPs remain
Analysts manually investigate known scanning IPsKnown internet noise is automatically excluded
High alert fatigue from mass scanning activityReduced analyst overload
0% suppression of known noise94% suppression of known noise
Manual enrichment required for external IP reputation checksGreyNoise context automatically incorporated
Targeted threats hidden within internet noiseUnknown and suspicious activity clearly surfaced

Benefits for the SOC Team

  • Significant Reduction in Alert Volume: Known internet scanners, mass-crawling infrastructure, and opportunistic probing activity are filtered before reaching the analyst queue. Analysts are presented only with events that require meaningful investigation.

  • Automated Threat Intelligence Correlation: Source IPs are automatically evaluated against GreyNoise Intelligence datasets. Common internet background activity is resolved automatically without requiring manual validation.

  • Reduced Investigation Time: GreyNoise enrichment eliminates the need for repetitive external reputation lookups and manual enrichment, significantly reducing investigation overhead.

  • Improved Visibility into Targeted Threats: By removing internet background noise, previously hidden reconnaissance attempts and targeted attack patterns become easier to detect and prioritize.

  • Reduction in Alert Fatigue: As inbound traffic volume grows, GreyNoise filtering scales with the environment, ensuring the targeted Alerts remain focused for SOC and operationally manageable.

Conclusion

GreyNoise Intelligence enhances Google SecOps detections by filtering out internet noise before alerts reach analysts.

By integrating GreyNoise correlation directly into YARA-L detection rules, SOC teams move from investigating large volumes of low-value alerts to working from a smaller, prioritized queue of meaningful security events.

The core value of this use case is to reduce the noise between SOC analysts and the threats that actually matter.