Map the plant you already run

What happens if it stops

The Visibility program starts with a question that has nothing to do with networking: what does this plant actually control, and what happens if it stops? A boiler feed pump, a batching sequence, a conveyor interlock, each one exists because something downstream depends on it running. Before an operator draws a single line on a network diagram, the program has them name the process consequence first.

That ordering matters. A cyber inventory that starts from IP addresses treats every device as equally important. A plant does not work that way. A PLC that trips a safety interlock and a PLC that logs ambient temperature are both assets, but losing one stops production and losing the other does not. The program trains operators to rank what they are about to map by consequence, so the register they build afterward already carries the judgment of the people who run the line.

Only once that ranking exists does the unit turn to the assets themselves: controllers, HMIs, remote I/O, the engineering workstation someone keeps program backups on. The point is not a long list. It is a list where the first column answers the question that matters if something goes wrong.

How controllers actually talk

Once the operator knows what a device does, the next unit asks which controllers talk to which, and in what language. Most plant floors run more than one protocol at once. An HMI or SCADA server might poll PLCs over Modbus/TCP on port 502 or EtherNet/IP and CIP on ports 44818 and 2222. A PROFINET cell handles a packaging line on its own real-time schedule. An OPC UA link on port 4840 carries tags up to the historian. DNP3 shows up in utility and water applications, often on port 20000.

The program trains operators to read that traffic the way an engineer reads a P&ID: as a set of relationships, not a packet count. Which device polls, which device answers, how often, and what happens if the answer is late. Most of these protocols were built for a control loop on a trusted wire, not for a contested network, so they carry no authentication and little in the way of message integrity. A device that speaks Modbus/TCP will generally act on a write command from anyone who can reach it.

That is also why a broadcast storm is not just an IT nuisance here. A PLC waiting on a poll response inside a fixed scan cycle has no spare capacity for a flood of ARP or discovery traffic. The program has operators connect the protocol map to the timing the process needs, so a flat, chatty segment reads as a consequence, not just an inefficiency.

Building the register from what the plant already has

The Asset Inventory & Asset Registers unit asks the next question directly: what is actually out there, and who owns it? The program does not have operators buy a scanning tool and point it at the plant floor. It has them start from three sources the plant already owns, because those sources already exist, are already paid for, and do not risk knocking a controller offline the way an active scan can.

An engineering drawing or P&ID network sheet shows what was designed and installed, but drawings age. A connection added during a troubleshooting call five years ago may never have made it back onto the sheet. The historian or SCADA point database knows every tag that has ever reported a value, but it knows tags, not IP addresses or switch ports, so a tag alone does not tell you where the device physically sits. A passive capture from a switch SPAN port, or the switch's own MAC address and ARP tables, shows what is actually talking on the wire right now, but it knows ports and MAC addresses, not what a device is for.

None of these three sources is complete on its own, and none is reliable on its own. The program trains operators to reconcile them against each other: a device the capture sees on no drawing, a drawing entry nobody in the plant can locate, a historian tag with no corresponding host anyone can point to. Reconciliation is the real work of building a register, and only the people who run the line can finish it, because only they can walk out to a panel and confirm what a device is.

What an outsider can already learn

OSINT for Industrial Control Systems turns the same question outward: what can an outsider already learn about your plant without ever touching it? Vendor case studies name the client and describe the control system in enough detail to identify the PLC family in use. Job postings for a plant electrician or controls engineer routinely list the exact software and hardware the role will work with. Internet-facing scanning services that index exposed hosts regularly turn up remote-access gateways and HMIs that were never meant to be reachable from outside the plant.

None of this requires more than a search engine and public records. The program trains operators to look at their own plant the way that research would, not to build a security testing capability, but to feed the finding back into the same register: a remote-access path exposed in a public index belongs in the inventory as clearly as a connection the capture found on the switch.

Why OT is not IT

The unit on what OT is, and why it isn't IT, gives operators the language for a distinction they already feel on the job. Where does the process end and the network begin? In IT, confidentiality usually comes first and a compromised laptop can be reimaged in an afternoon. In OT, availability and safety come first, and a controller running a process cannot simply be taken down to be fixed.

Asset life is a large part of the difference. A laptop is replaced every few years. A PLC installed in 2009 may still be running the line it was commissioned for, on firmware nobody has updated since. You cannot scan a device like that the way you scan a laptop. An active scan built for IT hosts can crash a controller never tested against that kind of traffic, or interrupt a real-time cycle a downstream device depends on. That is one more reason the register comes from drawings, historian and passive capture first, and anything more intrusive gets the same care a site applies to any change on a running line.

Real-time traffic is the other half of it. An IT network tolerates a retransmitted packet without anyone noticing. An OT network built around a fixed scan cycle may not. The program has operators carry that difference with them into every later decision about what can be touched and when.

Why is this connection still here?

The layer's last unit asks the question the whole register has been building toward: who needs this link, and what breaks if it goes? A reconciled inventory will always turn up connections nobody can immediately explain, a path between two segments the current drawing shows as separate, a remote-access route a contractor set up for a project that finished years ago.

The discipline the program trains is to ask before removing anything. Who depends on this connection today. What process, report or remote support activity would stop working if it were gone. Who can confirm that. An unexplained connection is a finding, not yet a decision, and the operators who found it are the ones positioned to trace it back to a real dependency or confirm that none remains.

Any change that follows goes through the site's own change process and the people who own the line. The program does not train operators to disconnect anything themselves. It trains them to ask the question with enough precision that whoever does make the call is working from evidence instead of a guess.

What your operators have at the end

By the end of the program, your operators have a reconciled asset and connection register built from the plant's own drawings, historian and switch data, ranked by process consequence and checked against what is already visible to an outsider. Every discrepancy the sources revealed is recorded as a finding, with the questions still open about it, in your CMDB, your maintenance system and your drawing set, not in a separate tool.

That record is the starting point for the next layer, deciding what to harden and in what order.