Part 1 documented how a trusted IT Administrator planted a destructive WORM inside a classified aerospace firm and walked away while it executed. Every action was logged. Nothing fired.
This article covers what should have been in place. The failure was not one bad alert or one missed admin action. It was the absence of joined-up governance between HR, security operations, access management, monitoring, and change control. The environment produced the evidence. The organisation failed to convert that evidence into intervention.
In insider sabotage cases, the decisive issue is rarely whether data existed. The decisive issue is whether ownership, escalation, and monitoring logic existed before the grievance turned operational.
1. Offboarding Was Not a Security Process
DuplicateVikingVenga's credentials, admin privileges, and VPN access stayed fully active through his notice period. Seven years of privileged access — domain controllers, backup systems, research servers, deployment pipeline — remained open because offboarding was treated as an HR completion task, not a security-controlled risk event.
For privileged users departing under adverse circumstances, the baseline control position should be much tighter. Resignation acceptance should trigger an immediate access review. Infrastructure-wide administrator rights should either be removed or reduced to tightly monitored, time-bound access. Final revocation should be verified, evidenced, and closed on the last working day. Where the departure follows a denied promotion, grievance, disciplinary event, or other adverse employment trigger, the monitoring posture should be elevated across the entire notice period.
| Section | Failure | What Should Have Been in Place | Control Outcome |
|---|---|---|---|
| Offboarding | No security-controlled offboarding existed for privileged users. | Security-owned offboarding workflow, immediate privileged access review on resignation, monitored-access-only model during notice period, final revocation with evidence-based sign-off. | Trust no longer substitutes for process. Privileged users cannot retain broad, unreviewed access while exiting the organisation. |
2. Insider Threat Was Not a Modelled Risk
The conditions were visible before the resignation was submitted. A long-tenured employee with privileged access had been passed over for promotion under circumstances he considered unjust. In insider threat management, that is not background noise. It is a recognised pre-incident profile: elevated access, adverse employment event, perceived grievance.
The organisation had no insider threat programme and no structured linkage between HR events and security monitoring. HR and security operated as separate administrative tracks. That separation meant the one business function that understood employment context never translated it into operational risk handling.
Once that promotion decision was made, monitoring on his account should have changed. Off-hours access, new administrative activity, unusual server touchpoints, scripted changes, and atypical VPN behaviour should have moved from passive logging to active review.
| Section | Failure | What Should Have Been in Place | Control Outcome |
|---|---|---|---|
| Insider Threat | HR events with security implications were never communicated to the security function. | Insider risk programme, HR-to-security escalation criteria, adverse event triggers, enhanced monitoring playbooks, and named accountability for risk elevation decisions. | A grievance-linked privileged user enters heightened monitoring before sabotage activity escalates. |
3. UEBA — The Control That Changes This Entirely
UEBA builds a behavioural baseline for each user over time. It learns normal login hours, usual systems, common administrative actions, data access patterns, and command behaviour. It does not ask only whether an action is permitted. It asks whether the action is consistent with how that specific user historically behaves.
Against DuplicateVikingVenga's activity, the anomalies were strong enough to stand out early. Six off-hours VPN sessions after seven years of no meaningful off-hours pattern should have triggered immediate anomaly scoring. Production script modification outside a change window, with no linked ticket, should have raised the score further. Lateral propagation traffic between internal servers should have materially deviated from his normal east-west activity profile. High-volume backup catalog writes at 03:00am, outside scheduled windows, should have been scored as critical.
In isolation, a single event might be explainable. In sequence, over days, for a user already within an elevated risk context, the score should have crossed the threshold for analyst review well before the ten-day timer expired.
| Section | Failure | What Should Have Been in Place | Control Outcome |
|---|---|---|---|
| UEBA | UEBA was not deployed in a classified environment where insider threat is a foreseeable risk category. | Per-user baselining, anomaly scoring, risk-weighting using HR and access context, automated escalation thresholds, and analyst review for repeated off-hours or high-risk deviations. | The WORM preparation pattern is surfaced within days, not after execution. |
4. SIEM Correlation — The Signal Was Already There
The SIEM was running. Every event was logged. The breakdown was not in telemetry collection. It was in correlation design. The organisation collected data but did not engineer detection logic capable of understanding the sequence as an attack chain.
A properly tuned SIEM in this environment should have correlated privileged off-hours access during a notice period, script changes without corresponding change tickets, abnormal lateral movement, and suspicious backup catalog writes. The attack did not live inside one event. It lived inside the sequence.
| Section | Failure | What Should Have Been in Place | Control Outcome |
|---|---|---|---|
| SIEM Correlation | SIEM tuning treated individual events as the unit of detection. The attack lived in the pattern. | Risk-based SIEM use cases, HR-linked enrichment, change-ticket correlation, baseline-aware east-west traffic rules, and chain-based detection logic spanning multiple event types over time. | Logged activity becomes actionable intelligence. The sequence is identified as malicious before detonation. |
What Should Have Existed End-to-End
- Security-owned offboarding for privileged users
- HR-to-security escalation for adverse employment events
- A formal insider threat model with defined triggers
- UEBA for behavioural anomaly detection
- Risk-based SIEM correlation across authentication, change, network, and backup events
- Change management enforcement tied to monitoring
- Monitored access restrictions during privileged notice periods
- Named ownership for escalation, review, and final revocation
The core lesson is simple. User behaviour does not lie. In this case, the user behaviour changed first. The company had the logs, the systems, and the opportunity to act. What it lacked was governance tight enough to turn observable behaviour into a decision.
