Visibility in ICS: Why DPI Alone Isn't Enough
Industrial networks do not behave like office IT, and they do not forgive lazy assumptions. Deep packet inspection feels comforting because it parses frames, labels fields, and produces neat alerts. That comfort is fragile. To understand what is really happening between controllers, sensors, and operator workstations, you need a wider lens.
This piece explains why DPI cannot carry the full load in cybersecurity & cyberdefense, and what a practical visibility strategy looks like when safety, uptime, and physical consequences all share the stage.
The Trouble With Treating DPI As a Silver Bullet
DPI promises to read protocol conversations, decode commands, and flag anything odd. That is helpful, but it captures only one layer of truth. In plants and substations, the context that matters most often lives above and below the packet, in timing, configuration, physics, and human workflow.
If you trust DPI to explain everything, you risk missing the quiet drift that becomes a bad day. A good decoder is a microscope. You still need a map, a clock, and sometimes a thermometer.
What DPI Really Sees
At its best, DPI tells you who talked to whom, using which protocol verbs, with which fields set. It can notice unsafe service codes, strange function combinations, or broadcast storms. That visibility is technical and narrow, like looking through a keyhole.
You see a slice of the conversation, but not the reason it happened or the impact it had on a process value that operators watch with near parental concern. Packets rarely confess intent. They only describe syntax.
Blind Spots That Matter
DPI stumbles when traffic is encapsulated, when proprietary extensions appear, or when an OEM quietly updates a device. It also ignores changes that never touch the wire, such as a PLC logic tweak loaded from a laptop, or a maintenance window where a jumper moves and the topology shifts.
Problems often start in those corners, not in a glamorous packet signature. If you rely on inspection alone, you will catch the obvious and miss the slow, structural shifts that truly change risk.
The Nature of ICS Networks
Control environments prize determinism. They run old and new gear together, they tolerate oddities that would terrify an enterprise admin, and they measure success in uneventful shifts. Visibility should reflect that culture. You are not hunting novelty for its own sake. You are verifying that the system remains the system, day after day, with small, well understood deltas. Think of it as checking the heartbeat, not chasing butterflies.
Deterministic Traffic and Protocol Quirks
Polling cycles, scan rates, and sequence numbers create rhythms in the traffic. The shape of that rhythm tells you if a controller is healthy or if latency is creeping in. Many field protocols were designed for reliability and simplicity, not for verbose introspection.
They carry just enough detail to move values safely. DPI can decode them, but it cannot infer intent without help from process context and asset metadata. A message that looks harmless in isolation may be odd in timing or out of place for that unit’s role.
Safety Before Speed
When a change risks tripping a breaker or starving a pump, people prefer the slower, safer path. That shows up as strict change control, staged cutovers, and sometimes air gaps that are more ritual than reality. Visibility should respect that posture.
It should be passive first, careful with polling, and generous with historical baselines so that operators can compare today to the last known good state. Tools that ignore that rhythm either create noise or convince teams to turn them off.
Where DPI Falls Short in Practice
DPI tools do a lot, yet they carry assumptions from IT. Those assumptions become friction in facilities where a serial gateway still matters and downtime is counted in dollars per minute. Three gaps appear again and again, and each one erodes trust if you do not address it with more than packet parsing.
Proprietary Protocols and Odd Encodings
Some vendors guard their dialects. Others publish them, then ship field upgrades that outpace decoders. You end up with partial comprehension, where important bits are opaque. DPI then produces timid alerts, or worse, quiet acceptance.
Without a living map of versions and device specifics, you cannot trust what the parser claims you are seeing. The fix is not magical. Keep current profiles, track firmware families, and use context to decide whether a decoded command belongs on that asset at that moment.
Out of Band Assets and Shadow Segments
Temporary engineering workstations, wireless links, skid packages, and vendor remote connections often sit just outside the neat diagram. They appear for a day, or for five minutes at two in the morning. If you watch only mirrored packet streams, you will miss them, or you will see them once and never again.
That is not visibility. That is a postcard from a vacation you did not take. The answer is continuous discovery that correlates identity, location, and purpose, not a once per quarter headcount.
Timing Manipulation and Low and Slow Attacks
A clever adversary avoids loud packets and instead stretches intervals, nudges setpoints by tiny increments, or replays acceptable commands at inconvenient hours. The surface area is subtle. DPI can confirm that the commands were valid, which is not the same as deciding they were wise.
You need a sense of timing health and process sanity, not only syntactic legality. Treat time as a first class signal. If the rhythm drifts, the music changes, even when every note looks fine on paper.
Weak Spot | What’s Going On | Why DPI Isn’t Enough | What You Need in Addition |
|---|---|---|---|
Proprietary protocols & odd encodings | Vendors use custom or evolving protocol dialects; decoders only understand part of the traffic. | DPI may mis-parse or ignore critical fields, giving a false sense of “all clear” or only vague alerts. | Maintain live protocol/firmware profiles, track device roles, and use asset context to judge if a command belongs on that device at that time. |
Out-of-band assets & shadow segments | Temporary laptops, wireless links, skid packages, and vendor connections appear briefly or off-diagram. | If they bypass monitored links, DPI never sees them, or sees them once and then loses track of them. | Continuous asset discovery that ties identity, location, and purpose together—not just “snapshot” packet views. |
Timing manipulation & low-and-slow attacks | Attackers nudge scan rates, replay valid commands, or shift setpoints gradually to stay under the radar. | DPI sees syntactically valid traffic and can’t tell that the cadence or small changes are abnormal on their own. | Monitor timing health, process trends, and setpoint behavior as first-class signals, then correlate with DPI alerts for true intent. |
A Broader Visibility Stack That Actually Works
If DPI is one tool, what completes the set? The answer starts with asset truth and continues through change tracking, remote access oversight, and process understanding. None of this requires heroics. It demands discipline and a refusal to confuse pretty dashboards with real control. The goal is simple to say and hard to do. Know what you have, know how it should behave, and notice quickly when reality disagrees.
Passive Discovery and Asset Intelligence
Start by learning what is present, where it lives, and how it talks. Use taps and span ports to observe without touching. Correlate MACs, serial numbers, firmware versions, and roles. Build a naming scheme that operators can read without squinting.
When an unrecognized device appears, you want a clear, calm message, not a mystery icon that looks like a toaster. Asset truth creates the stage on which every packet plays, and it turns random alerts into coherent stories.
Secure Remote Access Monitoring
Most facilities depend on vendors and integrators. That is normal. What matters is visibility into who connects, when, and to what. Record sessions, track jump hosts, and alert on after hours activity. The goal is not to play police. The goal is to keep a clean trail so that root cause analysis starts with facts instead of guesses. If someone needs emergency access, fine. Just make it observable, auditable, and boring.
Firmware and Configuration Telemetry
Packets tell you about conversations. Configs tell you about intent. Pull running configurations on a schedule that respects the plant, compare them to golden versions, and flag drift. When a change is approved, annotate it like a ship’s log. Firmware checks are equally important.
Outdated modules do not just invite exploits; they produce weird behavior that looks like gremlins until someone checks the version string. A tiny line in a release note can save a week of head scratching.
Process Aware Analytics
Take the values that matter, even a small subset, and watch them for sanity. Rate of change, seasonal cycles, and expected ranges provide context that packets alone cannot. If your flow trends look like a fever chart after midnight every Sunday, that might be maintenance, or it might be someone experimenting. Either way, the story rarely lives in a decoder table. Tie alerts to the impact on the process, not only to a field that violates a spec sheet.
Designing for Resilience, Not Just Inspection
The best visibility programs do not sit apart from operations. They sit inside them. They assume that accidents happen, vendors vary, and people tire at three in the morning. Resilience comes from layers that tolerate small failures without turning them into big ones. The measure of success is not a dashboard full of green. It is a team that can explain what changed and why, without drama.
Network Architecture with Purpose
Segment by function, not by aesthetic. Place data diodes and firewalls where they match the process boundaries. Use allow lists that read like a grocery list, clear and finite. Mirror traffic from the right points, and accept that sometimes the right point is upstream of a dusty switch that still earns its keep.
Documentation should be good enough that a new engineer can trace a path with a pen and feel confident. When the map and the territory match, troubleshooting gets faster and calmer.
People, Runbooks, and Drill Practice
Visibility is a tool for people. Write runbooks that say exactly what to check, in which order, and why. Practice them when nothing is on fire. Let operators drive the rehearsal so the steps fit the reality of the room. Keep the tone calm and the language human. If a step says to check the trend for the last four hours, also say what a healthy trend looks like, and what to do if it does not.
Measure what matters, not vanity counts. Track means time to clarity, the interval between the first odd symptom and the moment the team understands the cause.
Putting It Together Without Breaking the Plant
None of this is flashy. That is the point. You build on what you have, you avoid surprises, and you favor clarity over cleverness. DPI remains in the toolbox, valuable and limited. Around it you add asset truth, change discipline, remote access records, and a light layer of process sense. The result is not omniscience. It is something better, a steady confidence that the system you run is the system you expect.
Conclusion
DPI is a sharp instrument, but it is not the whole workbench. Industrial visibility grows from quiet, steady habits that respect how these environments actually run. Combine packet insights with asset intelligence, configuration telemetry, monitored access, and process awareness. Put people and runbooks at the center. Then you will see enough to act, quickly and calmly, when it counts.
Trusted by the Web Community
See what we written lately
Request an invite
Get a front row seat to the newest in identity and access.















