Incident Classification Mapping Across Vendors

ContraForce records a closing classification on every classified incident using one canonical taxonomy, regardless of which detection module the incident came from. Analysts pick from the same four verdicts and the same reason list everywhere; ContraForce translates to each vendor’s native vocabulary behind the scenes.

​

Canonical classifications

This order and color scheme appear consistently across the close dialogs, the Incidents inbox classification column and filters, and the Command Dashboard Classification Trends widget.

​

Classification reasons

Each reason applies to specific classifications. The reason list shown when closing an incident is scoped to the classification you pick; it is the same list for every detection module. A reason is required whenever a classification is set. Your exact choice is always preserved in ContraForce, even when the vendor’s own vocabulary cannot store it (see the per-module tables below).

​

Per-module translation

ContraForce writes your verdict back to the vendor when the vendor supports it, translating to the nearest native value. The tables below show the write-back mapping per module.

​

Microsoft Sentinel

Sentinel’s classifications match the canonical four one to one. Its reason vocabulary is fixed per classification, so canonical reasons outside that set degrade to Sentinel’s default for the classification.

​

Microsoft Defender XDR

All fifteen Defender determinations are canonical ContraForce reasons, so most verdicts round-trip exactly. Reasons Defender cannot store for the mapped classification (for example a Sentinel-origin reason like Inaccurate Data) are written as Other; the canonical reason stays intact in ContraForce.

​

SentinelOne

SentinelOne records an analyst verdict and has no reason concept. Reasons are preserved in ContraForce only. When reading from SentinelOne, both suspicious and undefined map to Undetermined.

​

CrowdStrike Falcon

Closing a CrowdStrike incident in ContraForce closes it in Falcon too: ContraForce sets the alert’s status to closed (or the case’s, for incidents that are Falcon cases), so no one has to close it a second time in the Falcon console. The verdict itself stays in ContraForce, because CrowdStrike’s unified Alerts API has no classification field to write it to. The full canonical taxonomy is available when closing a CrowdStrike incident, and the verdict, reason, and comment appear on the incident in ContraForce and in the incident.closed.v1 webhook.

​

Closures made in the vendor’s portal

When an incident is closed in the vendor’s own console instead of through ContraForce, ContraForce reconciles the closure: the vendor’s classification is translated to the canonical taxonomy, an activity entry attributed to the upstream source is added to the incident’s audit trail, closure metrics are recorded, and the incident.closed.v1 webhook fires with closedBy.origin set to upstream.

​

Webhooks

The incident.closed.v1 webhook event carries the canonical classification and reason names, never raw vendor vocabulary. See the Webhook Event Reference for the payload schema.

​

Historical data

Before this taxonomy unified, ContraForce carried vendor-specific classification values. Historical data is translated on read: API consumers see canonical names in all responses; requests that still send legacy names are accepted and translated.

---

​

Related Guides