XDR Detection Findings

Overview

Cisco XDR produces OCSF 1.4–compliant bundles containing:

• Exactly 1 Detection Finding (class_uid: 2004)
• 0..N related Activities (e.g., Network, DNS, Process)

Before export, these bundles are parsed by XDR Automate Workflows, and each event is sent individually to external systems (e.g. Splunk, Microsoft Sentinel, Webhooks).

This means:

• Each exported record is a single valid OCSF object
• A single Detection Finding results in:
  • 1 Detection Finding event
  • 0..N Activity events

Workflows can be installed via the Cisco XDR Automate Exchange:
https://docs.xdr.security.cisco.com/Content/Automate/exchange.htm

They can be duplicated and customized to fit specific use cases.

Note: The Cisco XDR - Send Notifications for Detections workflow is an exception. It sends a notification for the bundle as a whole, containing metadata and a link, rather than full OCSF objects.

Export Model

Although data originates as a bundle (see below). This structure is not what downstream systems receive by default. Instead, each item in events[] is exported as an individual event.

{
  "count": <number>,
  "start_time": <epoch_ms>,
  "end_time": <epoch_ms>,
  "events": [ ... ]
}

Implications:

• No outer events[] array in exported payloads
• Each payload is one OCSF object
• Detection Finding and Activities must be correlated downstream (e.g., via observables and/or related event IDs)

Event Types

Detection Finding (Core Object)

"class_uid": 2004,
"class_name": "Detection Finding"

Core Fields

Activity Objects

All supporting telemetry is represented as OCSF Activities.

Each activity is a separate exported event.

Reference: https://schema.ocsf.io/1.4.0/categories

Key Nested Structures (Detection Finding)

finding_info

"finding_info": {
  "title": "...",
  "desc": "...",
  "uid": "...",
  "src_url": "...",
  "related_events": [...]
}

Primary identifier and display metadata.

observables

{
  "name": "device.ip",
  "type": "IP Address",
  "value": "10.90.15.22"
}

Used for:

• Correlation across events
• Linking Detection Findings and Activities downstream

enrichments

{
  "type": "device",
  "provider": "Device Insights",
  "data": { ... }
}

Contains contextual data such as:

• Hostname
• OS
• MAC
• Asset intelligence

unmapped

"unmapped": {
  "alert_name": "...",
  "alert_description": "...",
  "detection_id": "..."
}

Non-OCSF extensions. Schema may evolve.

Parsing Strategy

1. Identify Event Type

if event.class_uid == 2004:
    type = "finding"
else:
    type = "activity"

2. Handle Detection Findings

Extract:

• finding_info.uid (primary identifier)
• finding_info.title
• finding_info.related_events[...]
• severity
• observables
• time

3. Handle Activities

For each activity:

• Identify via class_uid

• Extract relevant fields (IP, process, domain, etc.)

• Link back using:

  • Shared observables
  • Device identifiers
  • Time proximity

Export Considerations

Workflow-Based Export

• Powered by XDR Automate Workflows

• Supports:

  • Webhooks
  • SIEM ingestion
  • XDR Notifications (in-app, email, Webex, Slack)

Customization

Data Handling

• Treat events as independent records
• Do not assume ordering
• Expect partial context per event

Correlation

• Use finding_info.uid and finding_info.related_events[...].uid when available
• Combine with time-based and/or observable-based grouping if needed

Schema Handling

• Always rely on class_uid
• Expect optional fields
• Preserve unmapped