As reported by Dark Reading, operational technology environments suffer from a fundamental visibility gap: after an attack, defenders often find no logs, no telemetry, and no forensic trail. The article argues that cyber deception is a necessary corrective, and Shield53 agrees — but the reasoning deserves deeper examination.
The OT Visibility Problem Is Structural
Most OT networks were designed for reliability and determinism, not observability. Legacy PLCs, RTUs, and HMIs rarely generate security-relevant logs. Many cannot authenticate users at all. Network traffic is often flat, unsegmented, and unmonitored at the process level. When an attacker traverses these environments, they move through systems that were never instrumented to record their presence.
This isn't a patching problem or a tooling gap — it's an architectural deficit. Traditional IT security stacks assume logs exist and can be centralized. OT stacks assume the network is trusted. Deception works because it doesn't depend on the existing instrumentation being adequate. It creates new, purpose-built signals.
Why Deception Succeeds Where Detection Fails
Deception technology deploys fabricated assets — fake PLCs, decoy engineering workstations, counterfeit historian databases — that have no legitimate business purpose. Any interaction with them is inherently suspicious. This produces several critical advantages in OT contexts:
The core insight: deception doesn't try to make OT environments more observable. It makes attackers more observable by giving them something to interact with that defenders fully control.
Deployment Realities Defenders Must Understand
Deception in OT is not plug-and-play. Poorly placed decoys can themselves become attack vectors if they expose real network topology or if they're configured with credentials that overlap with production systems. Effective deployment requires:
- Accurate network mapping to identify high-value asset clusters and likely ingress points
- Decoy fidelity that matches the environment — a fake Siemens S7-1500 in a Rockwell-centric plant is itself an indicator something is wrong
- Isolation guarantees ensuring compromised decoys cannot bridge to production segments
- Integration with the SOC's existing alerting and incident response workflows, not yet another standalone console
Shield53 Recommendations
- Map before you deceive: Conduct a full asset inventory and network topology review before deploying decoys. Placement matters more than quantity.
- Start with credential decoys: Honey credentials and honey tokens are the lowest-risk, highest-signal starting point. If an attacker uses fabricated credentials, you have immediate, unambiguous detection.
- Align decoys to attacker TTPs: Study MITRE ATT&CK for ICS. Place decoys along the techniques most relevant to your environment — engineering workstation spoofing, fake historian databases, counterfeit file shares.
- Ensure decoy isolation: Decoys must sit on isolated segments with strict egress controls. A compromised decoy should never be able to reach a production controller.
- Integrate, don't isolate: Pipe deception alerts into your SIEM or SOAR alongside existing detections. Deception is most powerful when it corroborates or triggers existing playbooks, not when it lives in a separate pane.
- Tabletop the response: Run exercises that simulate a decoy alert. If your team can't act on it within minutes, the technology's value is halved.
Deception won't replace network monitoring, segmentation, or patch management in OT environments. But it addresses the one problem those controls collectively fail to solve: giving defenders a trail when the underlying systems were never built to provide one.
