Threat Detections

Threat Detections surfaces suspicious privileged-account behaviour detected in real time by OrbisID's rule-based engine and ML confidence model. Detections are raised when Windows Event Log activity collected by Endpoint Sensors matches a detection rule — for example, a new service being installed, audit policy being modified, or a non-privileged account adding itself to a privileged group.

Requires Enterprise edition — not available on Community.

Navigating to Threat Detections

Go to Alerts → Threat Detections in the left navigation menu.

Detection Statistics

The four cards at the top of the page give an at-a-glance summary:

Card	Description
Open	Detections that have not yet been actioned
Acknowledged	Detections under investigation
Confirmed	Detections confirmed as genuine incidents
Dismissed	Detections determined to be false positives

Filtering Detections

Use the Filter by Status dropdown to narrow the list:

• Open (default) — newly raised detections requiring attention
• Acknowledged — detections being investigated
• Confirmed — verified incidents
• Dismissed — closed false positives

Clustered View

Requires OrbisAI with the Threat Detection Clustering feature enabled.

A Clusters | All Alerts toggle appears next to the page title when this feature is on. Clusters group related detections for the same account within a short time window into a single incident card — showing the systems and detection rules involved, the highest confidence score, and a short AI-generated narrative explaining the pattern. Expand a cluster to see and action its individual detections exactly as in the classic list.

Clustering is a deterministic grouping, not a change to detection itself — it never alters which detections are raised or their confidence scores, only how related ones are presented together. If AI is briefly unreachable, clusters still form; only the narrative text is missing. Use the refresh icon to regenerate narratives on demand (distinct from re-running detection). Switching to All Alerts always shows the classic unclustered list below, unaffected by clustering.

Understanding Detection Columns

Column	Description
Account	The account the suspicious activity was observed on
System	The target system where the activity occurred
Reason	A human-readable explanation of why the detection was raised, including the triggering Event ID
Confidence	ML-adjusted confidence score (0–100%). Higher scores indicate stronger evidence
Status	Current detection status
Detected	When the detection was first raised

Confidence Score Colouring

Colour	Range	Interpretation
Red	80 – 100%	High confidence — strong anomaly signal
Orange	50 – 79%	Medium confidence — worth investigating
Green	0 – 49%	Low confidence — likely benign or from a known privileged account

How the Confidence Score Works

Each detection starts with a base confidence determined by the detection rule (e.g., 0.90 for audit policy changes, 0.70 for PowerShell script blocks). The score is then adjusted by:

1. Off-hours boost — +0.15 if the event occurred outside 08:00–18:00 on a weekday, or on a weekend
2. ML adjustment — a Naive Bayes model trained on your confirmed and dismissed detections adjusts the score based on account name, rule type, PAM risk level, account type (Human/Non-Human), and identity linkage. The model weight scales from 0 → 1 over the first 50 analyst decisions to prevent sparse data from dominating early.

Known privileged service accounts (NON_HUMAN type, HIGH/CRITICAL PAM risk) naturally accumulate false-positive signal, causing the model to lower confidence for expected privileged actions on those accounts over time.

Actioning Detections

For any Open detection, action buttons appear in the Actions column.

Acknowledge (✓)

Mark the detection as under investigation.

1. Click the yellow tick icon
2. Optionally add investigation notes
3. Click Acknowledge

Confirm (shield)

Mark the detection as a genuine incident.

1. Click the red shield icon
2. Add notes describing the confirmed threat
3. Click Confirm

Confirmed detections train the ML model (increasing confidence for similar future events on the same account) and contribute to KRI scoring.

Dismiss (✗)

Mark the detection as a false positive.

1. Click the grey X icon
2. Optionally explain why it is a false positive
3. Click Dismiss

Dismissed detections train the ML model (decreasing confidence for similar future events) and are retained for audit purposes.

Bulk Actions

When multiple detections are selected (using the checkbox column), a bulk action toolbar appears:

• Bulk Acknowledge — acknowledge all selected detections
• Bulk Dismiss — dismiss all selected detections as false positives
• Bulk Confirm — confirm all selected detections as genuine incidents

Bulk confirms and dismisses trigger an immediate ML model retrain.

Viewing Detection Details

Click the eye icon on any row to open the full detection detail dialog. This shows:

• Reason — full description of the triggering event and rule
• Evidence — key–value pairs of supporting data (Event ID, channel, timestamp, process name, object name, logon ID, and raw event data)
• Confidence Score — the current ML-adjusted score
• Endpoint Sensor — which sensor collected the underlying event data
• Notes — any notes added during acknowledgement, dismissal, or confirmation

Detection Lifecycle

Detection Rules

Rule Key	Event ID(s)	Base Confidence	Description
NEW_SERVICE	4697, 7045	0.90	Service installed
SCHEDULED_TASK	4698	0.85	Scheduled task created
GROUP_MEMBERSHIP	4728, 4732, 4756	0.80	Added to privileged group
AUDIT_POLICY	4719	0.90	Audit policy modified
POWERSHELL_SCRIPT	4104	0.70	PowerShell script block executed
WMI_ACTIVITY	5857, 5861	0.75	WMI persistence activity
ADMIN_PROCESS	4688	0.60	Admin process launched
SPECIAL_PRIVILEGES	4672	0.50	Special privileges assigned at logon
USER_CREATED	4720	0.85	User account created
USER_DELETED	4726	0.80	User account deleted
PASSWORD_RESET	4724	0.85	Password reset attempt
ACCOUNT_MODIFIED	4738	0.70	Account attributes changed
ACCOUNT_RENAMED	4781	0.75	Account name changed
ACCOUNT_ENABLED	4722	0.60	Disabled account re-enabled
ACCOUNT_LOCKOUT	4740	0.65	Account locked out (possible brute-force)
EXPLICIT_CREDENTIAL	4648	0.65	Logon with explicit credentials
PERMISSION_CHANGE	4670	0.75	Object permissions changed
NETWORK_SHARE_CREATED	5142	0.85	Network share created
NETWORK_SHARE_MODIFIED	5143	0.70	Network share modified
NETWORK_SHARE_DELETED	5144	0.80	Network share deleted

Alert Notifications

OrbisID can forward new high-confidence detections to external channels. Configure these in Administration → Settings under Threat Detection Notifications:

Channel	Setting	Default
Email	alert.notify.email.enabled	false
Email recipients	alert.notify.email.recipients	(comma-separated list)
Email min confidence	alert.notify.email.min_confidence	0.75
Syslog (CEF)	alert.notify.syslog.enabled	false
Syslog host	alert.notify.syslog.host	—
Syslog port	alert.notify.syslog.port	514
Syslog protocol	alert.notify.syslog.protocol	UDP
Syslog min confidence	alert.notify.syslog.min_confidence	0.60

CEF syslog output is compatible with Splunk, Microsoft Sentinel, IBM QRadar, Elastic SIEM, and any ArcSight CEF-compatible receiver.

Relationship to KRIs

Threat Detection activity is tracked by six dedicated KRIs in the Threat Detection category:

KRI	Description
Open Threat Detections	Total open detections
High-Confidence Threats	Open detections above 0.75 confidence
Accounts with Active Threats	Distinct accounts with open detections
Confirmed Threat Rate	% of detections confirmed as genuine
Unacknowledged High-Confidence	High-confidence detections not yet reviewed
Offline Endpoint Sensors	Sensors that have gone offline

Relationship to Gap Analysis

Confirmed Threat Detections and active Endpoint Sensors provide evidence for monitoring controls in the PAM Gap Analysis:

• NIST AU-2 — active sensors are cited as real-time alerting evidence; confirmed detections upgrade the finding
• NIST AC-6(9) — sensor-collected event logs count toward logging of privileged function use
• ISO A.8.15 — sensors contribute to the alerting dimension of the logging control
• SOx ITGC-OP-1 — confirmed detections satisfy the analyst-review evidence requirement for SOx monitoring

Tips

• Triage daily — keeping the Open count low by acknowledging or dismissing detections promptly also keeps the ML model well-trained
• Confirm genuine incidents — confirmed detections are the strongest training signal and raise confidence for similar future events on the same account
• Dismiss false positives for known privileged accounts — NON_HUMAN service accounts doing expected privileged actions should be dismissed; the ML model will lower their confidence automatically over time
• Use CEF syslog — forwarding detections to your SIEM closes the NIST AU-2 and ISO A.8.15 gap without requiring a separate toolchain