Visibility, Detection, and Response

Three Gaps, One Blast Furnace

In late 2014, a German steel mill issued what appeared to be a routine maintenance notice: a blast furnace would be offline for unscheduled repairs. Germany's Federal Office for Information Security confirmed in its annual report that the shutdown was caused by a cyberattack, making this one of a small number of documented cases where an intrusion caused confirmed physical damage to industrial equipment. Three detection capabilities were absent simultaneously: there was no behavioral monitoring on the business network that would have flagged the initial lateral movement, no visibility at the IT-to-OT boundary that would have caught the crossing from corporate systems into production controls, and no OT-specific incident response procedure that would have recognized the event as a cybersecurity incident rather than an equipment failure. When all three are absent at once, an attacker who enters through a phishing email can reach a blast furnace control system without triggering a single alert. This chapter covers the three disciplines that close those three gaps: asset visibility -- knowing what is on your network before you can protect it; detection -- identifying anomalous behavior against a known baseline; and incident response -- applying a decision process that accounts for what an OT shutdown actually does to a physical process. It also covers patch management in OT environments, where the standard IT workflow fails at its first step.

The Asset Visibility Gap

Industry monitoring data consistently shows between 15 and 30 percent of OT devices are not in any documentation maintained by the asset owner. No maintenance record, no procurement record, no network diagram. These are real devices, communicating with control systems in real time, and the organization has no record that they exist. The gap has a mechanical explanation. The Computerized Maintenance Management System -- the CMMS -- was built from purchase orders and installation records captured at the moment each device was documented. It recorded the sensor a contractor added to the network five years ago. It did not record the replacement module swapped in during a three-day turnaround that never generated a change order. It did not record the vendor laptop plugged in for a firmware update and left connected. It did not record the legacy PLC module swapped after a production failure in a maintenance window that no one documented. The CMMS tells you what you bought. It does not tell you what is running on your network today. The SANS 2025 State of ICS/OT Security survey, drawing responses from more than 330 practitioners, asked where organizations planned to invest in the coming year. Asset inventory and visibility ranked first, cited by 50 percent of respondents -- the most frequently named investment priority. The same survey found that only 12.6 percent of organizations have full visibility across the ICS Cyber Kill Chain. At Level 2 of the ISA99 model -- where SCADA servers and HMIs sit, the supervisory layer that gives operators control over the physical process -- that number drops to 10 percent. Nine out of ten organizations cannot fully see the network layer that controls the physical process they are responsible for.

Why Active Scanning Is Forbidden

The first instinct when you need to know what is on a network is to scan it. IT security tools like Nessus, OpenVAS, and Nmap discover devices by sending probe packets -- test requests -- to every address and recording what responds. A typical scanner sends thousands of probe packets per second. In an enterprise IT network, this creates a complete device inventory in minutes. In an OT network, the same tool can cause an uncontrolled process shutdown. Many PLCs, RTUs, and field controllers were designed in the 1980s and 1990s for serial communication protocols that assume a small number of messages per second from known, authorized sources. When an IT scanner floods a legacy PLC with unsolicited packets, the device's communication stack -- the software layer that handles network requests -- can overflow, fault, or freeze. A faulted PLC stops processing. If that PLC is controlling a live process, the process stops with it -- not in a controlled shutdown sequence, but abruptly. Active scanning in live OT environments has caused documented production outages. This is not a theoretical risk. The rule is absolute: no active scanning in any OT environment without written confirmation from the device vendor that the specific device model and firmware version has been tested and confirmed safe for scanning. Absent that confirmation, the only appropriate discovery method is passive monitoring.

Passive Monitoring: Listening Without Speaking

Passive monitoring places a network sensor on a copy of the network traffic and observes the conversations already in progress. The sensor never sends a packet. It reads source and destination addresses, protocol types, function codes, and communication timing from traffic that the network devices are already generating. From those readings it builds a device inventory -- every IP address, MAC address, and hostname that has appeared in network traffic -- and maps the communication patterns between devices. No device on the network ever knows the sensor exists. Passive monitoring is the only safe discovery method in operational OT environments without vendor confirmation that active scanning is safe. Two physical methods connect a passive sensor to network traffic. A network TAP -- a hardware device inserted inline on a cable -- creates a hardware copy of every packet on that link and sends the copy to the monitoring sensor. TAPs never drop packets regardless of network load. A SPAN port -- a software configuration on a managed switch -- mirrors traffic from selected switch ports to a monitoring port. SPAN ports require no additional hardware, but switches deprioritize SPAN traffic under load. In a busy OT network, SPAN ports can drop packets, which means missed devices and gaps in the communication baseline. For OT monitoring where completeness matters, network TAPs at critical conduit points are the preferred connection method. The most informative placement is at the conduit between Level 2 (the control layer where HMIs and engineering workstations sit) and Level 3 (the operations layer with historians and SCADA servers), where all traffic crossing that boundary passes through the sensor's view.

Monitoring Platforms: Commercial and Open-Source

Four commercial platforms dominate the OT passive monitoring market, each with distinct strengths. Dragos Platform supports over 600 industrial protocols and is built around threat intelligence from named industrial adversary groups -- each detection in the platform is tied to documented adversary behavior rather than generic anomaly signatures. Claroty covers 450 protocols and is strongest in converged IT-OT environments where assets span both sides of the boundary; its querying capability provides a passive discovery option that goes deeper than pure traffic observation for devices that respond to safe protocol-native queries. Nozomi Networks includes wireless OT monitoring -- a capability relevant for sites using WirelessHART or ISA-100.11a field sensors -- alongside AI-driven anomaly detection across 500-plus protocols. Tenable OT Security combines passive monitoring with an integrated vulnerability database that scores discovered devices against known CVEs without requiring active scanning. All four carry enterprise licensing costs that reflect the scope and intelligence they provide, and all four require significant organizational expertise to operate effectively. Organizations without the budget for commercial platforms have two well-maintained open-source alternatives. Malcolm is a network traffic analysis platform developed by CISA and Idaho National Laboratory. It runs on a standard Linux host, connects to the network via TAP or SPAN port, and bundles Zeek (a protocol-aware packet analysis engine), Arkime (full packet capture and indexing), and OpenSearch (search and visualization) into a browser-accessible interface. Malcolm surfaces an asset list from observed traffic, flags new devices by first-seen timestamp, and builds a communication graph that shows which devices talk to which and at what frequency. ICSNPP -- the ICS Network Protocols Parsers project, also from CISA and Idaho National Lab -- extends Zeek with parsers for industrial protocols including Modbus, DNP3, EtherNet/IP, and S7Comm, enabling protocol-level traffic analysis within Malcolm's interface. Both tools are actively maintained, free, and fully functional in production OT environments. They require comfort with Linux command-line tools and configuration files to deploy, but every organization with a managed switch or the ability to install a hardware TAP can run them.

MITRE ATT&CK for ICS: Mapping the Kill Chain

MITRE ATT&CK for ICS is a knowledge base of adversary tactics and techniques observed specifically in attacks against industrial control systems. It documents 12 tactics and 79 techniques drawn from real ICS incidents. The framework extends the Enterprise ATT&CK matrix -- which covers IT attack patterns -- into OT. Real ICS attacks traverse both matrices in sequence: the attacker enters through IT systems using Enterprise techniques, then pivots into OT for impact using ICS-specific techniques. Understanding where a tactic sits in the kill chain tells you what monitoring signal to look for at that stage. The first nine tactics cover the approach phase: Initial Access, Execution, Persistence, Privilege Escalation, Evasion, Discovery, Lateral Movement, Collection, and Command and Control. These describe the attacker's movement from initial entry through establishing control. They appear in IT environments as well; detecting them in OT requires monitoring that covers both the business network and the IT-to-OT boundary, not just the control network itself. The final three tactics -- Inhibit Response Function, Impair Process Control, and Impact -- have no equivalent in the Enterprise ATT&CK matrix. These three describe the OT-specific end phase of an attack: disabling alarms and safety systems before the attacker manipulates the physical process, then executing the final destructive or disruptive goal. Stuxnet, covered in Chapter 4, used Modify Parameter (T0836) to alter centrifuge operating speeds while simultaneously using Spoof Reporting Message (T0856) to hide the changes from operators -- one technique in Impair Process Control, one in Inhibit Response Function, running in parallel. Industroyer's grid impact used Loss of Control (T0827) and Manipulation of Control (T0831) to issue legitimate-format IEC 104 circuit breaker commands while simultaneously blinding the supervisory layer. Understanding which tactic a detected behavior maps to tells you how far through the kill chain the attacker has progressed and how much time remains before a physical consequence.

Behavioral Detection: How Anomalies Surface

Signature-based intrusion detection -- matching network traffic against a database of known malicious patterns -- fails in OT environments for three structural reasons. Most PLCs and field controllers have no operating system that can run monitoring software; detection cannot happen at the device level. IT signature databases are calibrated against IT attack patterns, and normal OT traffic patterns trigger constant false alarms against those signatures. And an attack targeting a specific process and written for specific hardware will not match any existing signature the first time it is used. Detection in OT requires a fundamentally different approach built on the one structural advantage OT environments have over IT: the traffic is extraordinarily predictable. A PLC polls the same registers, at the same cadence, from the same source, every day. A historian writes its update on the same interval. An engineering workstation connects to its PLC cluster only during documented maintenance windows. That predictability is a detection asset. Behavioral baselining means recording what is normal -- which device talks to which, using which protocol, with which function codes, at what frequency -- and alerting when something deviates from that established pattern. Passive monitoring tools perform this baselining automatically as they accumulate traffic observations. Once a baseline is stable, four categories of anomaly carry the strongest detection signal in OT environments. A write command to a register or coil that has only ever been read is not a normal operational event -- it indicates something on the network has issued a control command it has never issued before. A new device IP or MAC address appearing without a corresponding change record requires immediate verification: it may be an authorized addition with poor documentation discipline, or it may be an attacker's implant. A workstation on the IT network communicating directly to a PLC -- bypassing the HMI layer that the zone and conduit model from Chapter 6 requires all such communication to pass through -- indicates either a segmentation failure or active lateral movement. And an engineering workstation accessing a PLC outside its documented maintenance schedule is anomalous in any well-operated facility, because legitimate engineering access is planned and predictable. None of these indicators requires sophisticated analysis. Each is a specific deviation from a known baseline, detectable from the first day a passive monitor is connected.

Patch Management Without Stopping Production

OT patch management requires one step that IT patch management does not: OEM validation. SCADA platforms, historian applications, and HMI software run on commercial operating systems -- Windows Server, standard Linux distributions -- but the ICS application and the OS are tightly coupled. A Windows patch that modifies kernel behavior or network stack timing can alter SCADA polling rates, break historian connectivity, or cause HMI rendering failures. Before any operating system patch reaches a production OT system, the ICS vendor must confirm that the patch does not break their certified application. That validation process takes weeks to months. During that window, the vulnerability is public, the patch exists, and the system remains unpatched. This is not negligence -- it is the architecture of a system where the ICS application was certified against a specific OS behavior and any change to that OS requires re-certification. IEC 62443-2-3 provides guidance for IACS patch management as a five-phase process: Identification (monitor vendor security bulletins and cross-reference the asset inventory to determine which patches apply to which systems), Prioritization (evaluate risk based on exploitability, asset criticality, and operational impact), Testing (validate in a non-production lab environment before touching production), Deployment (execute through formal change management with a rollback plan and a scheduled maintenance window), and Verification (confirm the patch applied correctly and the system operates normally after deployment). NERC CIP-007, described in Chapter 7, sets a 35-day evaluation clock that begins from OEM-validated availability -- not from the date the original vendor released the patch -- reflecting exactly this constraint.

Three situations make patching impossible even with a validated patch available: no OEM-validated version exists yet, the next maintenance window is months away, or the system has reached end-of-life and will never receive another patch. Both Windows XP (end-of-support 2014) and Windows 7 (end-of-support 2020) are still running in operational ICS environments, because the ICS applications they host were certified against those specific OS versions and the vendor never produced a recertification for a newer OS. For these systems, four compensating controls replace patching. Micro-segmentation restricts which network addresses and protocols can reach the vulnerable device, reducing the attack surface available to any exploit targeting the known vulnerability. Application whitelisting -- as introduced in Chapter 4 -- permits only approved executables to run on the host, blocking exploit payloads even if the vulnerability is present and reachable. Disabling unused network services removes the attack vectors that specific CVEs require; many exploits target services that are running but not needed. Virtual patching deploys a network security device that inspects traffic bound for the vulnerable host and blocks traffic matching the known exploit pattern before it reaches the target. Compensating controls are not equivalent to patching. They reduce the exploitability of a known vulnerability while the patch process runs its course -- or, for end-of-life systems, as the permanent security posture until replacement planning is complete and funded.

When Normal Incident Response Rules Don't Apply

If your IT security team wrote your incident response plan, that plan will give actively wrong guidance the moment an OT system is involved. IT incident response's first action is isolation: disconnect the compromised system from the network to stop further damage and contain the intrusion. In IT, this is correct. In OT, the compromised system may be the PLC controlling a chemical reactor or a conveyor line that feeds a production process. Isolating that PLC does not protect the process -- it may stop the process without a controlled shutdown sequence, potentially creating conditions more dangerous than the compromise itself. OT incident response runs on three rules that IT incident response does not share. The first is safety before containment: before any containment action is taken, the question is whether the physical process is currently safe. If not, activating the safe state or initiating an emergency shutdown takes priority over security response. If the process is safe and the threat is not actively manipulating it, maintaining operations under monitoring may be safer than a shutdown. The second rule is that operations, engineering, and environmental health and safety are decision-makers from the first minute -- not advisors. No security team can make a containment decision about an OT system without understanding what that decision does to the physical process, and that knowledge lives in operations. The third rule is forensics without disruption: standard IT forensics takes systems offline to image hard drives. In OT, that halts production. OT forensics uses passive network traffic capture and, for Windows-based OT hosts, memory acquisition tools that work without shutdown. PLCs and RTUs generally lack a standard interface for forensic acquisition, making network traffic the primary evidence source.

An OT incident response plan must address five elements that IT plans never include. The safe-state decision matrix defines, for each critical system, the specific conditions under which the system should continue operating under monitoring versus activate its safe state -- and identifies who has the authority to make that call. Operations must approve any containment action that stops a process. The OT-specific notification list specifies the regulatory reporting requirement for the organization's sector and geography: TSA pipeline directives require reporting significant cybersecurity incidents to CISA within 12 hours; NERC CIP-008 defines the reporting obligations for bulk electric system operators. "Notify the CISO" is not a notification plan. Evidence collection procedures must be adapted for OT: passive network capture replaces drive imaging, and memory acquisition is limited to Windows-based OT hosts. The multi-team command structure assigns specific roles to each team -- incident commander, operations lead, EHS, IT security, OT engineering -- because security does not own OT incident response. Finally, the vendor contact tree provides emergency contacts for each critical system's vendor and integrator, documented in advance rather than searched for at 2 a.m. when a system is faulted. The Colonial Pipeline incident in May 2021, covered in Chapter 6 for its zone architecture failures, provides an important IR lesson: CISA did not learn about the attack from Colonial Pipeline -- it learned from the FBI. Colonial had no documented procedure for regulatory notification in that scenario. A plan without pre-defined notification steps means the regulator finds out from a third party. The most effective way to find every gap in an OT IR plan before a real incident is a tabletop exercise with an OT-specific scenario. Run the exercise against your actual zone architecture and your actual systems. Every gap the exercise surfaces is a documented plan gap you can close before it becomes an operational failure.

Building an ICS Security Career

The combination of process knowledge and cybersecurity awareness is genuinely rare in the industry. Most cybersecurity professionals have no direct experience with PLC programming, DCS architecture, or process safety. Most OT engineers and automation technicians have no formal security training. The intersection is where the industry needs people, and it is where a focused certification path builds demonstrable, verifiable competence. Three paths lead to that intersection, starting from different backgrounds. OT engineers and automation technicians already hold the most valuable asset: direct knowledge of how industrial processes work. The entry point for this group is ISA IC32 -- the Cybersecurity Fundamentals Specialist certificate from ISA -- which frames security concepts entirely in the language of IEC 62443 and IACS operations. IC32 has no formal prerequisites and maps to the knowledge structures practitioners already use. From IC32, the path continues through IC33 (risk assessment methodology), IC34 (security design and implementation), and IC37 (maintenance and ongoing management) toward the ISA/IEC 62443 Cybersecurity Expert designation. The GICSP -- the Global Industrial Cyber Security Professional credential administered by GIAC -- is available at any stage for those who want a vendor-neutral, broadly recognized practitioner credential. IT security professionals transitioning to OT have the reverse starting point: solid security foundations and limited OT experience. SANS ICS410 is the primary entry point -- a six-day course covering OT architecture, industrial protocols, attack surface, and foundational security controls, leading directly to the GICSP exam. ICS410 is designed to bridge the IT-to-OT knowledge gap in a single intensive course. The follow-on for practitioners who want depth in detection and response is SANS ICS515, which prepares for the GRID credential -- the GIAC Response and Industrial Defense certification -- covering OT threat hunting, detection methodology, and incident response. For those building toward a dedicated ICS security practitioner role, the ICS410-to-GICSP path followed by ICS515 and GRID is the industry-standard progression. CompTIA announced the Security OT+ certification (SOT-001) during 2026, with the beta exam closing in August and a full launch scheduled for December 2026. Once launched, it will offer a vendor-neutral pathway at lower cost than GIAC credentials and with the broad corporate recognition CompTIA certifications carry. The ICS security discipline has a documented skills shortage. The industry does not lack interest -- it lacks practitioners who combine operational technology familiarity with formal security training. Either starting point, OT background or IT background, is a legitimate entry into the field.

What's Next

Chapter 8 has covered the three operational disciplines that give a security program real-time reach: asset visibility through passive monitoring, threat detection through behavioral baselining and ATT&CK-aligned analysis, and incident response adapted for environments where containment decisions carry physical consequences. Chapter 9 moves to the architectural devices that enforce the zone and conduit model at the network level -- the switches, firewalls, data diodes, and DMZ designs that translate the policy decisions of Chapter 6 into physical network controls.

Reflect

• The visibility gap section states that 15 to 30 percent of OT devices are typically absent from any documentation. For the most critical segment in your environment -- the network zone containing the PLCs or RTUs that directly control the physical process -- do you have a passive monitoring tool in place? If not, what is the first step required to deploy one?
• The MITRE ATT&CK for ICS framework places three tactics (Inhibit Response Function, Impair Process Control, and Impact) at the end of the kill chain as ICS-only behaviors. For each of the three, what specific observable signal in your OT network would indicate an attacker has reached that tactic? Is any of those signals currently monitored?
• The OT patch management section identifies OEM validation as the step that distinguishes OT patching from IT patching. For the most critical OT system in your environment, do you have a process for receiving and tracking OEM-validated patch releases, separate from the standard IT patch cycle? If a critical CVE were published today, how long would it take to know whether a validated patch exists?
• The incident response comparison distinguishes safe-state decisions from IT containment decisions. For the most critical system in your environment, has the safe state been formally defined and documented -- the specific pre-planned condition the process can hold without full control system access -- and is the authority for activating it explicitly assigned to a named role?