Incident Classification

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

Order	Classification	Meaning	Color
1	True Positive	Confirmed malicious activity	Red
2	False Positive	The detection was wrong; no suspicious activity occurred	Orange
3	Benign Positive	Real activity that was confirmed benign, expected, or authorized	Green
4	Undetermined	No firm verdict was reached	Blue

This order and color scheme appear consistently across the close dialogs, the Incidents inbox classification column and filters, and the Command Center 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.

Classification	Valid reasons
True Positive	Multistage Attack, Malware, Malicious User Activity, Unwanted Software, Phishing, Compromised User, APT, Suspicious Activity, Other
False Positive	Not Malicious, Not Enough Data To Validate, Inaccurate Data, Incorrect Alert Logic, Other
Benign Positive	Security Testing, Confirmed User Activity, Line Of Business Application, Security Personnel, Suspicious But Expected, Other
Undetermined	Unknown, Other

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.

Canonical	Sentinel classification	Sentinel reason
True Positive (any reason)	TruePositive	SuspiciousActivity
False Positive + Inaccurate Data	FalsePositive	InaccurateData
False Positive + Incorrect Alert Logic	FalsePositive	IncorrectAlertLogic
False Positive (other reasons)	FalsePositive	InaccurateData
Benign Positive (any reason)	BenignPositive	SuspiciousButExpected
Undetermined	Undetermined	none

Microsoft Defender XDR

All fifteen Defender determinations are canonical ContraForce reasons, so most verdicts round-trip exactly.

Canonical	Defender classification	Defender determination
True Positive	TruePositive	The chosen reason (Multistage Attack, Malware, Malicious User Activity, Unwanted Software, Phishing, Compromised User, APT, Other)
False Positive	FalsePositive	The chosen reason (Not Malicious, Not Enough Data To Validate, Other)
Benign Positive	InformationalExpectedActivity	The chosen reason (Security Testing, Confirmed User Activity, Line Of Business Application, Security Personnel, Other)
Undetermined	Unknown	none

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.

Canonical	SentinelOne analyst verdict
True Positive	true_positive
False Positive	false_positive
Benign Positive	false_positive
Undetermined	undefined

When reading from SentinelOne, both suspicious and undefined map to Undetermined.

CrowdStrike Falcon

CrowdStrike’s unified Alerts API has no classification concept, so there is no vendor write-back. Classifications on CrowdStrike incidents live entirely in ContraForce: the full canonical taxonomy is available when closing, and the verdict, reason, and comment are stored and displayed by ContraForce.

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 API reference for the payload schema.

Historical data

Before this taxonomy unified, ContraForce carried vendor-specific classification values. Historical data is translated on read:

Legacy value	Canonical value
InformationalExpectedActivity	Benign Positive
Unknown	Undetermined
NonIssue	Benign Positive
PolicyViolation	Benign Positive
QradarFalsePositive	False Positive
Undefined	Undetermined
Suspicious	Undetermined

API consumers see canonical names in all responses; requests that still send legacy names are accepted and translated.

​Canonical classifications

​Classification reasons

​Per-module translation

​Microsoft Sentinel

​Microsoft Defender XDR

​SentinelOne

​CrowdStrike Falcon

​Closures made in the vendor’s portal

​Webhooks

​Historical data