Your SOC's UEBA tool flags a night-shift database administrator as high risk after logging in from another region during a scheduled maintenance window. The model's training data came mostly from office-hours staff. What should the analyst recognize?
Select an answer to reveal the explanation.
Short Explanation
Think of UEBA like a neighborhood watch that only learned daytime traffic. If you only watched 9-to-5 folks, a 2 a.m. plumber looks suspicious even though he's just doing his job. You don't need to ignore the alert; you need role- and region-aware baselines before you trust it.
Full Explanation
User and entity behavior analytics learns normal activity from historical telemetry, then scores deviations as risk. When the training population is skewed, the model mistakes legitimate diversity for anomaly: nonstandard shifts, geographic variation, or approved maintenance can look malicious because the learned baseline encodes the majority pattern. The correct response is to recognize baseline bias and separate legitimate role, shift, and regional patterns before risk scoring, often through peer-group baselines and contextual enrichment. A claim that UEBA cannot be used because it is machine learning confuses statistical detection with signature matching; UEBA is still valid when baselines are representative and tuned. Closing the alert without tuning ignores the underlying model deficiency and leaves future false positives unaddressed. Treating regional login differences as irrelevant contradicts behavioral analytics, because geography and normal work patterns are core context for accurate risk assessment. Exam caveat: bias is a data and design problem, not proof the alert is malicious or harmless. Operational check: compare the alerting account's role, shift, location, and approved change window against a peer group before scoring the event.