CISA Says Log Everything. OT Protocols Can't. Here's What Actually Works.

The Problem

CISA's March 2025 guidance on Living Off The Land (LOTL) detection tells defenders:

"Implement detailed logging and aggregate logs in an out-of-band, centralized location."

"Establish and continuously maintain baselines of network, user, administrative, and application activity."

"Build or acquire automation (such as machine learning models) to continually review all logs."

Solid advice. For IT networks.

For OT networks? Fundamentally broken.

Why CISA Guidance Fails in OT

1. OT Protocols Don't Log by Design

CISA assumes every protocol logs every action.

OT reality:

2. Baselining Requires Data You Don't Have

CISA guidance:

"Establish baselines of network, user, administrative, and application activity."

OT reality check:

Why defenders don't know:

1. No logging - Can't baseline what you don't measure
2. No monitoring - OT networks often have zero visibility tools
3. Legacy systems - Some PLCs been running 20+ years, nobody documented normal behavior
4. Vendor access - Remote support sessions happen ad-hoc, no central tracking

3. Logging Everything = Alert Fatigue (Unusable)

Let's do the math for a medium-sized facility:

4. Legitimate Tools = Attack Tools (Can't Distinguish)

CISA guidance focuses on IT LOLBins (PowerShell, WMI, PsExec).

OT equivalent: Every legitimate tool IS an attack tool.

What Actually Works (Given OT Protocol Limitations)

Since we CAN'T implement CISA guidance as written, here's what defenders CAN do:

1. Protocol-Level Anomaly Detection (Not Volume-Based)

# Example: Modbus anomaly detection (not volume logging)
IF write_command AND register IN read_only_list:
    ALERT("Write to read-only register")

IF logic_upload AND time NOT IN maintenance_window:
    ALERT("Logic upload outside maintenance window")

IF command_source_ip NOT IN whitelist:
    ALERT("Command from unknown source")
        

Result: 10-50 alerts/day (actionable) instead of 1,000+ (noise)

2. Asset-Level Baselining (Not Activity-Level)

# Allowlist-based detection (no baseline needed)
IF upload_command AND source_ip NOT IN engineering_workstation_list:
    ALERT("Logic upload from unauthorized source")

IF modbus_write AND source_ip NOT IN scada_workstation_list:
    ALERT("Write command from unauthorized source")
        

Result: Detects LOTL without needing "normal" activity baseline

3. Time-Based + Source-Based Detection

# Context-based detection
IF vendor_session AND time BETWEEN 00:00-05:00 AND no_maintenance_ticket:
    ALERT("Vendor access at unusual time without ticket")

IF vendor_session AND commands_per_minute > 50:
    ALERT("Automated command script detected")
        

Result: Catches LOTL abuse without flagging legitimate vendor work

4. Unidirectional Gateways for Historian/Monitoring

Why this works:

1. Attacker compromises historian (common LOTL target)
2. Attacker tries to pivot to production PLC
3. Unidirectional gateway blocks reverse traffic
4. Attack stops at historian layer

Result: LOTL lateral movement blocked by physics (not signatures)

5. Authentication ABOVE Protocol Layer

Why this works:

• Protocols still have zero auth (legacy compatibility preserved)
• But access to network requires MFA (LOTL attacker needs stolen VPN creds + 2FA)
• Session recording catches LOTL commands after the fact

Result: LOTL detection via access layer, not protocol layer

DIY LOTL Detection for OT (Practical Guide)

Step 1: Deploy Protocol-Aware Monitoring (30 days)

Step 2: Build Allowlists (Not Baselines) (7 days)

Document:

1. Which IPs are engineering workstations (may upload logic)
2. Which IPs are SCADA/HMI (may issue writes)
3. Which IPs are historians (may query registers)
4. Which IPs are vendors (remote access)

Store in CSV:

IP,Role,Allowed_Actions,Maintenance_Window
XXX.XXX.XX.10,engineering_ws,modbus_write|s7_upload,any
XXX.XXX.XX.20,scada_hmi,modbus_write,any
XXX.XXX.XX.30,historian,modbus_read,any
XXX.XXX.XXX.XX,vendor_remote,s7_upload,Mon-Fri 08:00-17:00
        

Goal: Know who SHOULD be doing what (not "normal" volume)

Step 3: Deploy Anomaly Alerts (Not Volume Alerts) (7 days)

Alert rules (Zeek/Suricata):

# Write from unknown source
alert modbus any any -> $OT_NETWORK any (
    msg:"Modbus write from unauthorized source";
    flow:to_server;
    modbus_func:write;
    !src_ip:$ALLOWED_WRITE_IPS;
    sid:1000001;
)

# Logic upload outside maintenance window
alert s7comm any any -> $OT_NETWORK any (
    msg:"S7 logic upload outside maintenance window";
    flow:to_server;
    s7_func:upload;
    time:!maintenance_window;
    sid:1000002;
)

# Rapid command sequence (automation/script)
alert modbus any any -> $OT_NETWORK any (
    msg:"Rapid Modbus commands detected (potential automation)";
    flow:to_server;
    threshold:type both,track by_src,count 50,seconds 60;
    sid:1000003;
)
        

Goal: Catch LOTL without alert fatigue

Step 4: Session Recording for Engineering Access (14 days)

Step 5: Unidirectional Gateway for Monitoring (30 days)

The Honest Assessment

What defenders need:

• Protocol-aware monitoring (not generic logging)
• Allowlist-based detection (not volume baselines)
• Context-based alerts (not signature-based)
• Physics-based segmentation (unidirectional gateways)

Key Takeaways

1. CISA says log everything → OT protocols log nothing by default
2. CISA says baseline normal activity → OT defenders don't know normal (no data)
3. CISA says alert on anomalies → OT logging everything = 13M alerts/day (unusable)
4. CISA says detect LOLBins → OT: every tool is a LOLBin (legitimate = attack)

CISA guidance + OT protocol reality = this article.

References

1. CISA Joint Guidance: Identifying and Mitigating Living Off the Land Techniques (March 2025)
   https://www.cisa.gov/sites/default/files/2025-03/Joint-Guidance-Identifying-and-Mitigating-LOTL508.pdf
2. Modbus Protocol Specification - No authentication, no logging by design
3. IEC 61850 / S7COMM - Optional logging, rarely enabled in practice
4. DNP3 Secure Authentication - Exists but rarely deployed (legacy compatibility)

Analysis by Jeff Gray, Cyborama OT Intelligence
Published: July 13, 2026
Basis: CISA Joint Guidance + OT Protocol Reality
For defensive use by OT security professionals.

← Back to Control Systems Security · Previous: The 2% Problem