Skip to main content

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.

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:

CardDescription
OpenDetections that have not yet been actioned
AcknowledgedDetections under investigation
ConfirmedDetections confirmed as genuine incidents
DismissedDetections 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

ColumnDescription
AccountThe account the suspicious activity was observed on
SystemThe target system where the activity occurred
ReasonA human-readable explanation of why the detection was raised, including the triggering Event ID
ConfidenceML-adjusted confidence score (0–100%). Higher scores indicate stronger evidence
StatusCurrent detection status
DetectedWhen the detection was first raised

Confidence Score Colouring

ColourRangeInterpretation
Red80 – 100%High confidence — strong anomaly signal
Orange50 – 79%Medium confidence — worth investigating
Green0 – 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 KeyEvent ID(s)Base ConfidenceDescription
NEW_SERVICE4697, 70450.90Service installed
SCHEDULED_TASK46980.85Scheduled task created
GROUP_MEMBERSHIP4728, 4732, 47560.80Added to privileged group
AUDIT_POLICY47190.90Audit policy modified
POWERSHELL_SCRIPT41040.70PowerShell script block executed
WMI_ACTIVITY5857, 58610.75WMI persistence activity
ADMIN_PROCESS46880.60Admin process launched
SPECIAL_PRIVILEGES46720.50Special privileges assigned at logon
USER_CREATED47200.85User account created
USER_DELETED47260.80User account deleted
PASSWORD_RESET47240.85Password reset attempt
ACCOUNT_MODIFIED47380.70Account attributes changed
ACCOUNT_RENAMED47810.75Account name changed
ACCOUNT_ENABLED47220.60Disabled account re-enabled
ACCOUNT_LOCKOUT47400.65Account locked out (possible brute-force)
EXPLICIT_CREDENTIAL46480.65Logon with explicit credentials
PERMISSION_CHANGE46700.75Object permissions changed
NETWORK_SHARE_CREATED51420.85Network share created
NETWORK_SHARE_MODIFIED51430.70Network share modified
NETWORK_SHARE_DELETED51440.80Network share deleted

Alert Notifications

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

ChannelSettingDefault
Emailalert.notify.email.enabledfalse
Email recipientsalert.notify.email.recipients(comma-separated list)
Email min confidencealert.notify.email.min_confidence0.75
Syslog (CEF)alert.notify.syslog.enabledfalse
Syslog hostalert.notify.syslog.host
Syslog portalert.notify.syslog.port514
Syslog protocolalert.notify.syslog.protocolUDP
Syslog min confidencealert.notify.syslog.min_confidence0.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:

KRIDescription
Open Threat DetectionsTotal open detections
High-Confidence ThreatsOpen detections above 0.75 confidence
Accounts with Active ThreatsDistinct accounts with open detections
Confirmed Threat Rate% of detections confirmed as genuine
Unacknowledged High-ConfidenceHigh-confidence detections not yet reviewed
Offline Endpoint SensorsSensors 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