Introduction to Custom Security Events
In Cisco XDR, Incidents represent a consolidated view of a potential security breach, based on the correlation of multiple Detection Findings. These Detections, also known as Security Events, are collected from various Detection Sources and evaluated together in real time. Cisco XDR’s correlation engine analyzes relationships between Detections, such as shared observables, overlapping timelines, or related attack patterns, to determine whether they represent parts of the same threat. When a set of Detection Findings is determined to be related, they are grouped, enriched with other Threat Intelligence, and presented as Incident in Cisco XDR.
Prior to Custom Security Events, Cisco XDR could only ingest Security Events from Cisco Managed Detection Sources, identified and supported by Cisco’s XDR engineering team. Examples of these Detection Sources:
| Category | Examples |
|---|---|
| Endpoint Detection Sources | CrowdStrike, Microsoft Defender for Endpoint, Cisco Secure Endpoint, SentinelOne, ... |
| Email Detection Sources | Microsoft Defender for O365, Proofpoint, Cisco Email Threat Defense, ... |
| Network Detection Sources | Cisco Secure Access, ... |
With this new ingestion method, customers themselves can identify and support additional Detection Sources that Cisco may have no plans to support. It is important to call out that some Detection Sources offer different levels of information:
| Level | Notes | XDR Ingests? |
|---|---|---|
| Incidents | May represent grouped threats or cases. | No |
| Security Events | Represent individual detections or findings. | Yes |
| Activities (Base Telemetry) | Raw event or behavior data. | No |
Note: Detection Sources may use different terms, such as Alerts, Alarms, Detections, or Behaviors. It is important to focus on Security Events conceptually for this feature, whatever they may be called by the source.
Ingestion: What You Should Know
To successfully integrate a Detection Source and bring new Security Events into XDR, you need to understand these key concepts of the ingestion pipeline:
| Attribute | Description |
|---|---|
| 7x24 Operation | Continuous operation without scheduled downtime. |
| Near Real-time | Events ingested as quickly as possible after occurrence. |
| Steady Rate | Event ingestion avoids excessive bursts. |
| Data Loss Handling | Ensures no events are lost, even in case of temporary outages. |
API-based Ingestion Process
Most Detection Sources offer an API to request Security Events created or updated in the past n minutes. To retrieve these systematically, perform the steps below:
- API calls typically occur every n minutes (n ≤ 5), producing a steady event stream.
- The number of events returned per call may vary depending on activity levels.
- Overlapping windows may be used (e.g., request past 5.5 minutes every 5 minutes) to avoid missing Security Events.
- XDR de-duplicates overlapping events, as long as you are able to use the same Detection ID to refer to the same event.
- Outage recovery is handled by requesting the time window missed, avoiding excessive bulk ingestion. For example: API failure for 3 hours → request past 3 hours of Security Events after recovery.
Push-based Ingestion Process
Some Detection Sources use a push model instead of, or in addition to, an API pull model (e.g. via Webhooks). In most cases, this method is preferred over API-based ingestion, as it is usually more efficient, and more real-time. Below are some considerations for this process:
| Consideration | Action |
|---|---|
| Steady Real-time Delivery | Ensure constant ingestion flow. |
| Data Loss Prevention | Monitor successful delivery and capture missed events. |
| Outage Recovery | Resume and backfill any gaps after downtime. |
Why This Design Matters
Incoming Security Events feed Incident Correlation in XDR. This roughly follows the below process:
| Step | Purpose |
|---|---|
| Correlate Security Events with one another | Identify patterns and relationships. |
| Correlate with XDR Native Detections | Combine different detection types for a holistic threat view. |
| Time-sensitive analysis | Late-arriving events are excluded from correlation. |
Cisco’s Typical Integration Steps
When Cisco integrates a Detection Source, the majority of the work is to:
| Step | Description |
|---|---|
| 1 | Identify the API (or method) for 7x24 Security Event ingestion without data loss, near real-time. |
| 2 | Understand the Security Event data provided by the source. |
| 3 | Map source data to a single, normalized format. |
Final note: When adding your own Detection Sources, you are responsible for completing the three integration steps described above. See the guide in the next section to create a Custom Security Events integration.