🎓 Lesson 14
D5
Baseline Development for Mining OT Protocol Anomalies
Baseline development is creating a 'normal behavior profile' for mining operational technology (OT) systems so we can spot unusual activity that might signal a cyberattack or equipment failure.
🎯 Learning Objectives
- ✓ Analyze Modbus/TCP and DNP3 packet captures to identify protocol-specific normal behaviors
- ✓ Design time-synchronized behavioral baselines incorporating mine cycle phases (drill–blast–muck–haul)
- ✓ Apply statistical divergence metrics (e.g., KL divergence, z-score thresholds) to quantify deviation from established baselines
- ✓ Explain how false positive rates change with baseline granularity (per-device vs. per-protocol vs. per-process)
- ✓ Apply NIST SP 800-82 Rev. 2 guidance to validate baseline coverage for critical blast initiation subsystems
📖 Why This Matters
In modern automated mines, a rogue command sent to a blast initiation system—or a delayed response from a haul truck’s proximity sensor—could cause catastrophic safety incidents or production loss. Unlike IT networks, OT anomalies often manifest as subtle timing shifts or malformed function codes—not malware signatures. Without an accurate baseline of 'what normal looks like' across your specific mine’s equipment, intrusion detection systems generate overwhelming false alarms—or worse, miss stealthy attacks that mimic routine operations. This lesson equips you to build defensible, operationally grounded baselines—not generic templates.
📘 Core Principles
Baseline development rests on three pillars: (1) Operational fidelity—capturing behavior during all valid mine states (idle, active drilling, pre-blast sequencing, post-blast ventilation); (2) Protocol awareness—understanding field semantics (e.g., Modbus Function Code 0x05 = force single coil; repeated toggling may indicate malicious cycling); and (3) Temporal rigor—modeling not just 'what packets occur' but 'when, how often, and in what order' they occur relative to physical events (e.g., blast delay timer expiration triggers a DNP3 Class 1 event). Advanced baselines integrate physics-informed constraints: e.g., a hydraulic drill’s pressure sensor cannot report >400 bar during normal operation—so any value beyond that bounds is a hard anomaly, regardless of protocol compliance.
📐 Statistical Baseline Deviation Threshold
This formula computes the adaptive z-score threshold for detecting outliers in protocol message inter-arrival times (IAT), a key indicator of compromised devices or DoS attempts. It uses rolling window statistics to accommodate shift changes and ore hardness variations.
Adaptive IAT Z-Score Threshold
IAT_threshold = μ_w + z_{α/2} × σ_wDynamic upper bound for inter-arrival time of protocol messages, updated per sliding window to handle operational variability.
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| μ_w | Rolling window mean IAT | ms | Average time between consecutive packets in current window |
| σ_w | Rolling window standard deviation of IAT | ms | Measure of IAT variability in current window |
| z_{α/2} | Standard normal quantile | dimensionless | Critical value for two-tailed test at significance level α (e.g., 2.576 for α=0.01) |
Typical Ranges:
Modbus/TCP on fiber backbone: 100 – 250 ms
DNP3 over legacy radio link: 800 – 3200 ms
💡 Worked Example
Problem: During a 72-hour capture of Modbus/TCP traffic from a primary crusher PLC, the mean IAT is 142 ms with standard deviation σ = 18.3 ms. Using a 30-minute sliding window and α = 0.01 significance level (zα/2 = 2.576), calculate the dynamic upper threshold for IAT at t=45h.
1.
Step 1: Confirm current window (t−30min to t) yields μ_window = 144.2 ms, σ_window = 19.1 ms
2.
Step 2: Compute threshold = μ_window + zα/2 × σ_window = 144.2 + 2.576 × 19.1
3.
Step 3: Calculate: 144.2 + 49.2 = 193.4 ms → round to 193 ms
4.
Step 4: Verify: 193 ms exceeds static threshold (142 + 2.576×18.3 = 189.1 ms), confirming adaptation to increased jitter
Answer:
The dynamic upper IAT threshold is 193 ms, reflecting increased network variability during night-shift crushing of harder ore bands.
🏗️ Real-World Application
At Newmont’s Boddington Mine (Western Australia), engineers developed a per-device baseline for blast initiation controllers using 14 days of pre-blast sequence telemetry. They discovered that legitimate 'arm' commands always occurred exactly 37±2 seconds after the final borehole survey confirmation message—and only during daylight hours (06:00–18:00 local). When a test intrusion attempted to arm the system at 02:17 via spoofed DNP3 Time Sync messages, the SIEM flagged it as a multi-dimensional anomaly: (1) temporal violation (outside allowed window), (2) missing prerequisite survey ACK, and (3) invalid source MAC (non-authorized engineering laptop). The baseline prevented accidental or malicious arming—meeting AS/NZS 4831:2022 Clause 7.3.2 requirements for fail-safe blast control integrity.
🔧 Interactive Calculator
🔧 Open Mine Automation Cybersecurity Framework Calculator📋 Case Connection
📋 Autonomous Haulage System (AHS) Cybersecurity Upgrade – Iron Ore Mine, Pilbara
Legacy CAN bus interfaces exposed to lateral movement; lack of secure firmware update mechanism
📋 IIoT Sensor Network Security for Tailings Monitoring – Copper Mine, Chile
Use of consumer-grade LoRaWAN gateways with default credentials; no sensor identity attestation
📋 Blasting Control System Zero Trust Pilot – Limestone Mine, Indiana
Single-factor authentication for blast engineers; no session timeout or command replay protection