CrowdStrike Next-Gen 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 overwhelming SOC analysts, causing them to ignore alerts and miss real targeted attacks that get buried in the noise.

The GreyNoise Solution

GreyNoise continuously observes the internet and labels IPs associated with scanner intelligence and malicious activity. In CrowdStrike Next-Gen SIEM, SOC teams can use the daily GreyNoise lookup feed to suppress known noise and keep analyst attention on activity that is more likely to represent targeted threat behavior.

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
CrowdStrike FalconFalcon Next-Gen SIEM or Falcon Insight XDR
GreyNoise AppGreyNoise Threat Intel app for Foundry Templates
API KeyGreyNoise API key configured in the app under Configuration
Firewall LogsPalo Alto or equivalent firewall logs ingested in the Next-Gen SIEM
Log FieldsLogs must contain source.ip, network.direction
ECS MappingYour firewall data is accurately mapped to the ECS schema before being ingested into Next-Gen-SIEM.

Key Next-Gen SIEM Function

The entire integration relies on one single command:

CommandPurpose
match(file="ti_greynoise_indicators.csv", field=[source.ip], column=[source.ip])Matches source IPs to GreyNoise lookup metadata generated by the official Foundry workflow.

Implementation Steps

Step 1: Connectivity Verification of GreyNoise App

Confirm GreyNoise integration is installed and the lookup creation workflow is enabled. Verify ti_greynoise_indicators.csv exists in the Next-Gen SIEM repository used by SOC detections.

Verification checklist:

  1. Verify Workflow is enabled - refer to the Lookup File Workflow section in the user guide for steps.
  2. Verify that the lookup file exists - refer to the Incorporating the Lookup File section in the user guide for steps.

Expected result: The ti_greynoise_indicators.csv file should exist in the lookup files, and workflow should be enabled.

Step 2: Verify Your Firewall Logs are available

Confirm that your logs are ingested into CrowdStrike and that the required fields are populated.

Note: Replace <VENDOR_NAME> with the name of your vendor when you execute the query.

#Vendor=<VENDOR_NAME>
| tail(limit=5)
| match(file="ti_greynoise_indicators.csv", field=[source.ip], column=[source.ip])
| select([source.ip, "source.ip.greynoise.is.classification", "source.ip.greynoise.is.last_seen_timestamp"])

Expected result: GreyNoise fields populate for matching IPs. If no enrichment appears, verify the following before proceeding: that related firewall data is ingested properly and mapped to the ECS schema in Vendor Parser, that workflow settings (API key, query, repository) are correct, and that the scheduler has run at least once since setup.

Step 3: Run the Full Search

This is the full production-ready search. It pulls inbound firewall logs, enriches each source IP with GreyNoise intelligence, and surfaces the events with GreyNoise data that require analyst attention.

Note: Replace <VENDOR_NAME> with the name of your vendor when you execute this query.

// GreyNoise data
defineTable(query={
  readFile([ti_greynoise_indicators.csv], include=source.ip)
}, include=[source.ip], name="GreyNoiseData")
// FW/WAF logs
| #Vendor = <VENDOR_NAME>
// Filter inbound internet traffic (inbound/incoming as per logs)
| network.direction="inbound"
// Exclude known ips found by GreyNoise
| !match(table=GreyNoiseData, field=source.ip)
| groupBy(source.ip, function=[count(as=Count)], limit=max)
// Prioritize remaining events by source IP volume (threshold >= 10, then sorted)
| Count >= 10
| sort(Count, order=desc, limit=max)

Step 4: Save as a Correlation Rule

Once the search is verified end-to-end, save it as a Correlation rule to run automatically and generate a detection or a case:

Steps:

  1. Go to Next-Gen SIEM → Rules.
  1. Click on Add rule → Create new rule.
  1. Set the following details:
  • Name: UC1 - Inbound Threat Detection (GreyNoise Enriched).
  • Description: Add any relevant description for your SOC team.
  • Search query: Insert the query mentioned in Step 3 above after updating your vendor name in it.
  1. Set the following details:
  • Create case containing detection: If you want to generate a case containing detection, select the checkbox and case template. (A detection will always be created as an outcome of the rule.)
    Recommendation: Enable this for high-confidence detections that require immediate investigation. For noisy or informational detections, keep it disabled to avoid unnecessary case creation.
  • Trigger type:
    • Verbose: One outcome is generated for each result matching the query. The total number of outcomes is limited per rule trigger.
    • Summary: One outcome is generated for all results matching the query. The total results included in the outcome are limited by the rule trigger.
    • Recommendation: Use Verbose for low-volume, high-severity detections where each event matters. Use Summary for high-volume scenarios to reduce alert noise.
  • Severity: Select the appropriate severity level for this detection. (Informational, Low, Medium, High, Critical).
    Recommendation: Align severity with risk and impact—use High/Critical for confirmed or high-confidence threats, and Medium/Low for suspicious or baseline activity.
  • MITRE ATT&CK Tactic & Technique: Select the checkbox and assign MITRE ATT&CK Tactic & Technique.
    Recommendation: Always map to MITRE when possible to improve detection context, reporting, and threat correlation.
  1. Select Start date and Start time, Search frequency, Search window, and Search offset based on your monitoring requirements.
  1. Select the Notification Method and set up the appropriate values for that method
  1. Click on Finish to create the correlation rule.

Note: You can change the Schedule Frequency and Time Range duration as per your needs.

Understanding the Output

The CQL query enriches every inbound source IP through the GreyNoise Lookup file, then applies progressive filters as follows:

  • Targets only inbound direction traffic across the Vendor.
  • Excludes all IPs GreyNoise recognizes as known internet scanners via filtering out common IPs.
  • Retains only IPs with 10 or more hits - eliminating low-frequency opportunistic noise.
  • Sorts by count descending - most active IPs surface first.

Result: What remains is a tightly focused list of inbound IPs that are unrecognized by GreyNoise's scanner intelligence yet repeatedly hitting your environment. Out of 16 raw events, only 1 IP survived with 11 hits - making them the highest priority candidates for immediate investigation.

Alert Volume Reduction

Filter / LogicWhat it RemovesImpact on Alert Volume
direction="inbound"Internal noise & standard outbound browsing traffic.High: Keeps analysts laser-focused on external threats, not internet noise.
!match()Removes common IPs that have already been identified by GreyNoise.Maximum: Eliminates known "internet background noise" that can mask real threats.
where count >= 10One-off port scans and opportunistic "drive-by" pings.High: Drops low-frequency anomalies; retains only persistent, targeted activity.
The Net Result15 out of 16 events dropped94% Reduction: Only 1 high-risk IP requires human investigation.

Results and Impact

Before vs After GreyNoise

Before GreyNoiseAfter GreyNoise
16 inbound events1 IP after filtering
Analysts must manually check all events across threat intel feeds.Analysts ignore known internet noise automatically.
0% suppression of known noise94% suppression of known noise
Manual investigation takes 30–45 minutes per shiftInvestigation time reduced to minutes with pre-ranked IPs

Benefits for the SOC Team

  • Significant Reduction in Event Volume: Known internet scanners, confirmed malicious actors, internal traffic, and single-event probes are automatically filtered before they reach the queue. Analysts are presented only with events that genuinely require human evaluation, preventing critical alerts from being buried.
  • Automated Triage and Investigation: Source IPs are automatically evaluated using threat intelligence. Routine classifications, such as benign cloud services, known proxy nodes, internal traffic, or low-priority scans, are resolved without human intervention. Only true anomalies are escalated to analysts.
  • Immediate Identification of Targeted Threats: By stripping away the background noise of the internet, the system automatically elevates stealthy, targeted reconnaissance that has no prior reputation. True anomalies are instantly spotlighted rather than being lost in a sea of routine internet traffic.
  • Structural Eradication of Alert Fatigue: The reduction in noise scales with the environment. As inbound traffic grows, the enrichment layer absorbs the volume. The analyst queue remains lean and focused, reducing analyst burnout and the risk of missing a real breach due to volume overload.

Conclusion

Embedding GreyNoise lookup matching within Falcon Next-Gen SIEM firewall searches turns a noisy inbound stream into a concise, high-value threat feed. With the Foundry workflow updating ti_greynoise_indicators.csv daily, analysts consistently suppress background internet noise and focus on the few IPs that genuinely warrant investigation.