Integrate your own threat intelligence feeds

Supported in:

This guide is for security engineers and detection engineers who want to integrate custom Indicators of Compromise (IoCs) and third-party threat intelligence feeds into Google Security Operations. It explains how to ingest threat feeds, normalize indicators into the Unified Data Model (UDM) Entity Context Graph (ECG), and correlate indicator entities with streaming event telemetry. By following this method, you automate threat detection across your environment and eliminate manual indicator lookups. Successful integration reduces alert triage times and strengthens your organization's security posture through real-time and retroactive threat detection.

Integrating custom threat intelligence feeds lets your security operations team combine external indicator streams (such as Malware Information Sharing Platform (MISP), STIX/TAXII, or commercial feeds) with your internal security telemetry. Once normalized into the ECG, threat entities support both automated indicator matching and custom multi-event YARA-L 2.0 correlation rules.

Key terminology

  • Entity Context Graph (ECG): The contextual storage layer in Google SecOps that maintains stateful entity records (such as assets, users, and threat indicators) for correlation with security event logs.
  • Unified Data Model (UDM): The standardized schema that Google SecOps uses to normalize raw event logs and contextual entity data.
  • Indicator lifecycle interval (metadata.interval): The time-bounded validity window (start_time and end_time) that defines when a threat indicator is active in the ECG.
  • Automatic IoC match: A system-generated finding created when an incoming security event matches an active indicator entity in the ECG, displayed on the IoC matches page.
  • YARA-L retrohunt: An on-demand historical search that executes a YARA-L 2.0 detection rule against up to 30 days of past security telemetry.

Common use cases

The following use cases show how bringing your own threat intelligence addresses common security operations objectives.

Automated real-time indicator matching

  • Objective: Automatically evaluate streaming security events against ingested third-party indicators without maintaining custom correlation rules.
  • Value: Eliminates manual rule maintenance for high-volume threat feeds and surfaces immediate matches on the IoC matches page.

Custom YARA-L correlation rules and retrohunting

  • Objective: Join threat intelligence entities in the ECG with multi-event telemetry and scan up to 30 days of historical data using retrohunts.
  • Value: Detects multi-stage attacks and uncovers historical compromises that occurred before an indicator was added to your threat feeds.

Before you begin

Before you begin, confirm that the following prerequisites are met:

  • Permissions: You must have Identity and Access Management permissions to manage data feeds and author detection rules in Google SecOps (for example, Chronicle API Admin or Chronicle API Editor). For details on required roles, see Configure feature access.
  • Environment check: Confirm that you have an active Google SecOps instance and valid API credentials or endpoint URLs for your external threat intelligence provider (such as MISP, STIX/TAXII, or Cloud Storage buckets).
  • Search versus rule functionality: UDM search lets you inspect raw entity records stored in the ECG regardless of their active window, whereas YARA-L detection rules and automatic matching only evaluate indicators whose metadata.interval encloses the event timestamp.
  • Dashboard and search field prefixes: When querying threat intelligence entities in UDM search, dashboards, or YARA-L rules, use the graph.entity. prefix for indicator values (such as graph.entity.ip) and the graph.metadata.threat. prefix for threat attribution fields.

Ingest threat intelligence indicators

Select and configure an ingestion mechanism to bring external indicator streams into Google SecOps.

Select a feed ingestion mechanism

You can ingest threat intelligence feeds using any of the following supported mechanisms:

  • Prebuilt default parsers: Google SecOps includes default parsers for many threat intelligence platforms. For a list of supported parsers categorized under IOC, see Supported log types and default parsers. Supported vendors include MISP, ThreatConnect, Intel471, and Cyjax.
  • Feed Management API: Configure feeds in the Google SecOps console or using the Feed Management API to periodically pull indicators from external HTTPS, Cloud Storage, or Amazon S3 endpoints.
  • Ingestion API: Send pre-structured entity payloads directly to Google SecOps using the Ingestion API.
  • Bindplane agent: Collect and forward indicator logs from on-premises or cloud environments using the Bindplane agent.
  • Cloud Run functions: Deploy serverless ingestion scripts using Cloud Run functions to fetch indicators from external APIs (such as STIX/TAXII or MISP) and stream them into Google SecOps. For details, see Use ingestion scripts deployed as Cloud Run functions.
  • Google SecOps response integrations: Ingest indicators through Content Hub connectors to synchronize threat lists as part of automated playbooks. For details, see Use the Content Hub.

Onboard threat intelligence feeds

To ingest indicator logs from your threat intelligence provider into Google SecOps:

  1. Follow the onboarding procedure for your specific threat feed format or provider:

  2. Assign the corresponding IoC log type (such as STIX, MISP_IOC, CSV_CUSTOM_IOC, or THREATCONNECT_IOC) to the incoming feed data so the default parser extracts indicator attributes into UDM entity fields.

  3. Open the Data ingestion dashboard and verify that incoming log entries appear without unparsed log errors.

Populate and validate the Entity Context Graph

When threat indicators enter Google SecOps, the parsing pipeline normalizes them into UDM entity records and populates the ECG. For details on how entity enrichment works, see How Google SecOps enriches event and entity data.

Structured versus unstructured data mapping

Depending on how you send threat intelligence data to Google SecOps, follow the appropriate field mapping workflow:

  • Structured data ingestion: When sending pre-structured UDM entity records directly using the Ingestion API, format each payload according to the UDM Entity schema before ingestion.
  • Unstructured and semi-structured data ingestion: When sending raw logs (such as CSV, JSON, STIX, or CEF) using feeds, the Bindplane agent, or forwarders, assign a prebuilt default parser or create custom field mappings using parser extensions to extract indicator values and map them to required UDM entity fields.

What makes an entity an IoC

For an entity record in the ECG to be recognized as an actionable IoC by automatic matching and detection rules, the parser or API payload must populate the following five UDM field groups:

  • Entity type (metadata.entity_type): The supported indicator entity type, such as DOMAIN_NAME, IP_ADDRESS, FILE, or URL.
  • Source type (metadata.source_type): The data source classification, which must be set to ENTITY_CONTEXT for customer-ingested threat intelligence feeds.
  • Artifact identifier (entity.*): The indicator value itself, such as graph.entity.ip, graph.entity.hostname, graph.entity.domain.name, graph.entity.file.sha256 (or md5 and sha1), or graph.entity.url.
  • Threat metadata (metadata.threat): Contextual attributes describing the threat, including threat_feed_name, threat_name, category, severity, and confidence.

  • Lifecycle interval (metadata.interval):

    • metadata.interval.start_time: The timestamp when the indicator becomes active.
    • metadata.interval.end_time: The timestamp when the indicator expires.

For schema definitions, see the UDM field list for Entity and EntityMetadata.

Indicators typically become searchable in UDM search within 2 to 5 minutes after ingestion and parsing. Verify that your indicators populate the ECG by running a UDM search:

  1. In the Google SecOps navigation menu, select Investigation > Search.

  2. In the search field, enter a query targeting the entity graph for an ingested indicator value:

    • IP address:

      graph.entity.ip = "<var>IP_ADDRESS</var>"

    • Domain:

      graph.entity.hostname = "<var>DOMAIN_NAME</var>"

    • File hash (SHA-256):

      graph.entity.file.sha256 = "<var>SHA256_HASH</var>"

    • Source product:

      graph.metadata.source_product = "<var>SOURCE_PRODUCT_NAME</var>"

  3. Click Search or press Enter.

  4. Click the returned entity card and confirm that the threat and interval fields contain your expected metadata and active timestamps.

Correlate telemetry and detect threats

After your threat indicators populate the ECG, correlate them with incoming and historical security events.

Enable automatic IoC matching

Google SecOps includes an automated matching engine that operates independently of custom detection rules. When event telemetry matches an active indicator in the ECG:

  • System-generated matches: The platform creates an IoC match record automatically without requiring custom rule maintenance.
  • Estimated post-ingestion timing (ballpark estimation):
    • Streaming events: Once an indicator populates the ECG (typically 5 to 15 minutes after ingestion), Google SecOps evaluates incoming streaming events and surfaces matches on the IoC matches page within 5 to 15 minutes.
    • Historical events: The automated matching engine also evaluates newly ingested indicators retroactively against historical telemetry in batch cycles, with initial matches typically appearing within 1 to 4 hours (and full historical correlation completing within 24 hours).
  • Interval enforcement: The matching engine evaluates events strictly against active indicators where the event timestamp falls within metadata.interval.

Author YARA-L 2.0 correlation rules

Write YARA-L 2.0 detection rules to join event telemetry (such as network connections, DNS queries, or process launches) with indicator entities in the ECG. Custom rules let you combine indicator matches with behavioral thresholds, asset context, and exclusion lists:

  1. In the Google SecOps navigation menu, select Detection > Rules & Detections, and then click New.
  2. In the events: section of your rule, define a placeholder variable to join a UDM event field (such as $net.target.ip = $ip) with the corresponding ECG entity field (such as $ioc.graph.entity.ip = $ip).

  3. Filter the entity variable by threat attributes (such as $ioc.graph.metadata.threat.category) and specify a correlation time window in the match: section (for example, $ip over 5m).

  4. Click Save New Rule.

Run a retrohunt to detect historical compromises

Threat intelligence feeds often contain indicators that adversaries used days or weeks before your organization ingested the feed. While live rules evaluate new incoming telemetry, a YARA-L retrohunt applies your rule logic retroactively against up to 30 days of historical security events:

  1. In the Google SecOps navigation menu, select Detection > Rules & Detections.
  2. Locate your custom threat intelligence rule in the rules list.
  3. Click for more rule options and select YARA-L Retrohunt.
  4. In the YARA-L Retrohunt dialog, select the start and end times for your historical search. Make sure the selected date range is greater than or equal to the match window specified in your rule.
  5. Click Run.

  6. Open the Detections tab for the rule to monitor progress and inspect historical matches.

For more details, see Run a rule against historical data.

Investigate matches and alerts

Review findings generated by automatic matching and custom correlation rules across dedicated views in Google SecOps.

Review automatic hits on the IoC matches page

To investigate automatic indicator matches:

  1. In the Google SecOps navigation menu, select Detection > IoC matches.
  2. Use the filter controls to scope findings by indicator type (domains, IP addresses, file hashes, or URLs).
  3. Click any indicator row to open the match details panel, which displays:
    • Associated internal assets and usernames.
    • First seen and last seen event timestamps.
    • Threat intelligence feed source and confidence attribution.
  4. Click View in UDM Search to inspect all raw telemetry events associated with the indicator.

For more details, see View IoCs using Applied Threat Intelligence.

Triage rule hits on the Alerts and Detections pages

Detections generated by custom YARA-L rules appear on the Alerts and Detections pages:

  1. In the Google SecOps navigation menu, select Detection > Alerts & IoCs to view prioritized rule alerts.
  2. Click an alert name to open the Alert details page and inspect the Detections table, which lists correlated event rows and ECG entity attributes.
  3. For silent rules (where alerting is disabled) or completed retrohunts, open Detection > Rules & Detections, click the rule name, and inspect the Detections tab.

Correlate custom indicators with the Emerging Threats Center

You can also use the Emerging Threats Center to investigate how your custom IoC matches relate to broader adversary campaigns and malware families:

  1. In the Google SecOps navigation menu, select Detection > Emerging Threats.
  2. Review active threat campaigns and advisories, and pivot to UDM search to check whether indicators from your custom threat feeds overlap with observed campaign activity.

For more details, see Emerging Threats Center overview.

Access advanced assets and references

Use the following YARA-L 2.0 snippets and reference resources when building custom threat intelligence rules.

Outbound network connection matching a malicious IP address

This rule correlates outbound NETWORK_CONNECTION events with active IP indicators in the ECG:

rule custom_ioc_network_connection {
  meta:
    author = "Security Operations"
    description = "Detects connections to IPs matching custom threat intel"
    severity = "HIGH"
    priority = "HIGH"

  events:
    $net.metadata.event_type = "NETWORK_CONNECTION"
    $net.target.ip = $ip

    $ioc.graph.entity.ip = $ip
    $ioc.graph.metadata.threat.category = "SUSPICIOUS_NETWORK"

  match:
    $ip over 5m

  outcome:
    $risk_score = max(85)
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $principal_hostname = array_distinct($net.principal.asset.hostname)

  condition:
    $net and $ioc
}

DNS query matching a malicious domain

This rule identifies NETWORK_DNS lookups for domains flagged as malicious in your ingested threat feeds:

rule custom_ioc_malicious_domain_query {
  meta:
    author = "Security Operations"
    description = "Detects DNS queries for domains matching threat intel"
    severity = "MEDIUM"
    priority = "MEDIUM"

  events:
    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name = $domain

    $ioc.graph.entity.hostname = $domain

  match:
    $domain over 10m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $client_ip = array_distinct($dns.principal.ip)

  condition:
    $dns and $ioc
}

Process execution matching a malicious SHA-256 file hash

This rule triggers when a PROCESS_LAUNCH event matches a known malicious SHA-256 file hash stored in the ECG:

rule custom_ioc_malicious_file_execution {
  meta:
    author = "Security Operations"
    description = "Detects process launches matching malicious file hashes"
    severity = "CRITICAL"
    priority = "HIGH"

  events:
    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.target.process.file.sha256 = $sha256

    $ioc.graph.entity.file.sha256 = $sha256

  match:
    $sha256 over 5m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $file_path = array_distinct($process.target.process.file.full_path)
    $hostname = array_distinct($process.principal.asset.hostname)
    $user = array_distinct($process.principal.user.userid)

  condition:
    $process and $ioc
}

Community blogs and additional resources

For additional examples on authoring YARA-L rules and correlating custom threat intelligence feeds, see the following Google Cloud Community resources:

Troubleshooting

Use this section to manage performance expectations and resolve common issues when onboarding threat intelligence feeds and building correlation rules.

Latency, service quota, and limits

  • Ingestion and UDM search indexing: Newly ingested indicators typically appear in UDM search within 2 to 5 minutes. Wait at least 5 minutes after feed ingestion before troubleshooting missing entity records.
  • Automatic IoC matching latency: Once an indicator populates the ECG, matches against incoming streaming events appear on the IoC matches page within 5 to 15 minutes. Retroactive batch matching against historical events typically takes 1 to 4 hours (and up to 24 hours for full historical correlation).
  • Entity Context Graph correlation window: Automatic IoC matching and YARA-L correlation rules evaluate indicators strictly within their active metadata.interval window. Indicators with expired end_time values don't generate matches.
  • Retrohunt search window: YARA-L retrohunts scan up to 30 days of historical telemetry per execution. Completion time depends on rule complexity and system resource availability.

Error remediation

Use this table to diagnose and resolve issues during threat intelligence onboarding and detection rule authoring.

Issue Issue description Fix
Unparsed IoC logs Feed status shows incoming data, but logs fail to parse into UDM entities. Confirm that the feed log type matches your parser (for example, STIX, MISP_IOC, or CSV_CUSTOM_IOC). Check the Data ingestion dashboard for raw schema errors.
Missing UDM search results Indicator logs parse without errors, but UDM search returns no entity records. Verify that your query targets graph.entity.* fields (such as graph.entity.ip) rather than udm.principal.* event fields.
Rule fails to trigger on known indicator Both the event and indicator exist in UDM search, but the YARA-L rule produces no detections. Confirm that metadata.interval.start_time and metadata.interval.end_time on the indicator enclose the event timestamp.
Alert flood during retrohunt Running a retrohunt creates hundreds of duplicate SOAR cases and alerts. Turn off the rule's alerting toggle before starting a retrohunt. Review detections on the Detections page before re-enabling live alerting.
High volume of false positives Noisy indicators trigger detections on benign internal scanners or administrative hosts. Add a reference list exclusion to your rule (for example, not $net.principal.ip in %benign_scanner_ips) and require behavioral event context.

Validation and testing

Before enabling a custom threat intelligence rule in live alerting mode, verify its logic using the built-in Test rule feature:

  1. Open Detection > Rules & Detections and click your rule to open the Rules Editor.
  2. Click Test rule in the lower panel to evaluate the rule against recent historical event data and active ECG entities without generating alerts or SOAR cases.
  3. Inspect returned test detections to confirm that outcome variables (such as $threat_name and $source_feed) populate as expected.

What's next

Need more help? Get answers from Community members and Google SecOps professionals.