UEBA Noise After an Acquisition and Contractor Onboarding
Helio Systems has 2,400 employees and recently acquired a 300-person company. The acquired staff use a different email domain, a separate HR feed, and contractor badges. After onboarding, UEBA generated 1,100 first-time and unusual-access alerts in three days. Executives traveling to Asia trigger impossible-travel; 180 service accounts show interactive logons because of a legacy backup tool; night-shift warehouse staff trigger after-hours access. Analysts are closing alerts without review, and the insider-threat lead is worried about missing a real data-exfiltration case. The platform has six peer groups, but none reflect the acquired company or contractors. Risk scores are on default thresholds. The CISO asks for a 30-day plan to reduce noise by 60% without suppressing genuine anomalies.
1. How would you triage the 1,100 alerts to separate model gaps from real risk? What evidence would you sample?
Read the worked answer
Segment the 1,100 alerts by anomaly type and data source before touching thresholds. Many will cluster into a few causes: new HR feed identities, contractor badge access, service-account interactive logons, and travel. Pull a sample of 50 to 100 alerts, label them true, false, or unknown, and look for missing context rather than assuming the model is wrong. Real risk indicators include first-seen access to sensitive repositories followed by mass download, new accounts with privileged group additions, and access from unusual ASNs not explained by VPN. Model gaps include missing peer groups, stale identity attributes, and service accounts modeled as human users. Do not globally lower risk scores; fix identity data and peer groups first, then tune specific models. Preserve genuinely suspicious cases in a separate queue for the insider-threat lead.
2. Design peer groups, watchlists, and service-account handling for the acquired company and contractors. What should be time-bound?
Read the worked answer
Build peer groups by role, department, location, and employment type, and create a separate contractor group. Add the acquired company's users to groups based on HR attributes, not email domain alone. Use watchlists for executives, frequent travelers, and high-risk roles so travel is evaluated against expected patterns; do not suppress travel entirely. Model service accounts as service accounts: remove interactive logon expectations, tag them, and create a narrow watchlist for privilege use. For the legacy backup tool, either fix the logon type at the source or create a time-bound suppression with an expiry and owner. Every suppression should have a reason, scope, and review date. Re-baseline for 14 to 30 days after the HR and peer-group changes, and compare alert volume by model.
3. How would you measure whether the tuning actually reduced noise without hiding real threats?
Read the worked answer
Measure before and after: alerts per day, percentage closed without review, true-positive rate from sampled review, time to triage, and number of suppressions. A 60% noise reduction is only valid if sampled true positives do not fall and known insider-threat scenarios still surface. Run a tabletop or replay of a known exfiltration scenario before and after tuning. Add a weekly review of new suppressions and peer-group changes, and a monthly review with the insider-threat lead. Document model changes in the change log with owner and rollback. If analysts are closing without review, that is a process failure as much as a tuning failure; require disposition codes and audit a sample. Report residual risk to the CISO rather than claiming zero noise.