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.
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
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:
- Off-hours boost — +0.15 if the event occurred outside 08:00–18:00 on a weekday, or on a weekend
- 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.
- Click the yellow tick icon
- Optionally add investigation notes
- Click Acknowledge
Confirm (shield)
Mark the detection as a genuine incident.
- Click the red shield icon
- Add notes describing the confirmed threat
- 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.
- Click the grey X icon
- Optionally explain why it is a false positive
- 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 |
|---|---|---|
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