Knowing Your ICS Security Environment

The Foundation Before the Defenses

The most common reason ICS security programs fail is not a missing firewall rule or an unpatched PLC. It is a missing answer to two foundational questions: who is responsible for securing this system, and exactly what does the system contain? Defenses built without clear ownership dissolve into blame when something goes wrong. Controls designed without a complete asset inventory protect some assets and miss others -- often the ones most critical to the process. Chapter 4 established the threats and the frameworks. This chapter establishes the internal foundation that makes every subsequent security decision tractable: the people accountable for it, the roles defined by IEC 62443, the governance documents that create auditable accountability, and the asset model that tells you precisely what you are protecting. Without these, a security program is a collection of technical controls with no one to maintain them, applied to a system no one has fully mapped.

The Human Factor: Three Audiences, Three Threats

The Oldsmar operator caught an intrusion because a cursor moved across his screen at the moment he was watching. That is behavioral detection: a trained person noticing something that no security tool had flagged. IEC 62443-2-1 requires documented security awareness and training activities for all personnel who work with or near IACS systems -- not as optional good practice, but as a formal requirement of the security management system. The standard distinguishes awareness from training: awareness keeps all personnel broadly alert to threats; training builds role-specific skills. The critical insight is that one program cannot effectively serve three different audiences. Operators work closest to the physical process. Their threat surface is procedural and social: someone at the plant gate asking for system access without proper authorization, a USB drive left on a break room table. Their awareness training focuses on physical access procedures, credential handling, and reporting unexpected visitors or requests. Engineers hold technical and remote access -- direct connections to PLCs, programming environments, and vendor pathways. Their threat surface is the OT network and everything connected to it. They need to understand why an unfamiliar device appearing on a network segment is a security event and why bringing a personal laptop into the OT environment without authorization creates a crossing point. Executives don't touch the systems, but they control budgets, approve risk tolerance, and make decisions under pressure during an incident. Their training maps high-impact scenarios to financial and regulatory consequences so that when the incident happens, they have a frame of reference for decisions that cannot wait. The four activities that distinguish a genuinely effective program from a generic IT security course are: red team and blue team exercises using realistic simulations of the facility's OT environment; live demonstrations of known malware on actual industrial hardware, showing operators what an attack looks and sounds like in their specific environment; role-specific e-learning with assessment tied to job function; and board-level sessions that connect specific cyber scenarios to financial exposure and regulatory timelines. Behavior changes through repeated reinforcement, not a one-day session. The standard requires ongoing activities for exactly this reason.

The ISA99 Reference Model: Security at Every Level

Chapter 1 introduced the Purdue Model as the organizing framework for ICS architecture. The ISA99 reference model -- developed by the International Society of Automation's Standards Committee 99 and published internationally as IEC 62443 -- applies the same five-level hierarchy explicitly to security analysis. The distinction matters: the Purdue Model describes what each level does operationally; the ISA99 model describes the security profile of each level and the distinct risk that a compromise at each level carries. Level 0 is the physical process: sensors, actuators, and the equipment under control. A compromise at Level 0 is physical. A valve opens when it should close. A motor runs when it should stop. The consequence is not a data breach -- it is a physical event. Level 1 contains the PLCs, RTUs, and embedded controllers that read sensors and command actuators in milliseconds. A compromise at Level 1 means an attacker controls the physical process itself. Level 2 is the supervisory layer: HMIs, SCADA systems, and DCS operator workstations. A compromise here either gives operators a false picture of what is happening or removes their ability to intervene. Either outcome gives an attacker a significant head start. Level 3 contains manufacturing execution systems, batch management software, and production scheduling systems. The IACS boundary -- the dividing line between industrial control systems and enterprise IT -- sits between Levels 3 and 4. Everything below that line is IACS territory, with the security requirements IEC 62443 defines. Level 4 is enterprise IT: ERP systems, financial applications, and corporate infrastructure. The path from Level 4 to Level 3 is where most real-world breaches cross from IT into OT. Security decisions are level-specific for a concrete reason: the consequence of compromise escalates as you descend the stack. Patching a Level 4 ERP follows standard IT change management. Patching a Level 1 PLC requires a safety review, a maintenance window negotiated with operations, and often a vendor who must validate the patch against the specific hardware. Network monitoring at Level 2 uses passive traffic capture -- listening without sending probe packets -- because active scanners can crash legacy PLCs and RTUs. Knowing which level a device sits at tells you immediately what security procedures apply to it.

Who Is Responsible for What

Most ICS security failures originate not from missing technology but from missing clarity about ownership. The vendor assumed the asset owner would configure the device securely. The asset owner assumed the integrator would harden it during installation. The integrator assumed the vendor would ship it with secure defaults. IEC 62443 resolves this by defining four distinct roles, each with specific obligations. The Asset Owner operates the facility and carries the broadest accountability. They conduct risk assessments, establish the Cyber Security Management System -- the documented framework of policies, procedures, and responsibilities for managing ICS security -- and maintain security across the full operational lifecycle. When the regulatory inquiry comes after an incident, it lands with the asset owner. The Integration Service Provider designs and installs the IACS. Their security responsibilities begin at the design phase, not at commissioning. They plan system security, define the zones and conduits that structure the network architecture, select components that meet the required security levels, and hand over a system that matches the asset owner's documented security requirements. Security failures embedded at installation become the asset owner's operational problem for the life of the system. The Maintenance Service Provider delivers ongoing support. This is in practice the most exposed role from a security perspective: maintenance access is one of the most commonly exploited entry points in ICS environments. Remote vendor sessions, USB connections for diagnostics, and engineer laptops brought into the OT environment all introduce exposure. IEC 62443 requires maintenance providers to follow documented security procedures during every support activity. The Product Supplier manufactures hardware and software components: PLCs, HMIs, network devices, embedded controllers. They are accountable for secure development practices, documented security capabilities, vulnerability disclosure processes, and lifecycle support commitments. IEC 62443 Series 4 addresses product suppliers directly. When evaluating a PLC for purchase, Series 4 compliance is the measure of how seriously the manufacturer has treated security at the design and build stage. One organization can hold multiple roles simultaneously: a large contractor may act as both integrator and maintenance provider on the same project. The role framework clarifies which obligations apply to each party in each context, before a failure creates a dispute about accountability.

The Governance Layer: Policies, Procedures, and Guidelines

Every ICS facility has safety procedures everyone follows. Startup sequences. Emergency shutdown steps. Lockout/tagout for maintenance. Those documents exist because someone decided that inconsistency created unacceptable risk. The same discipline applies to cybersecurity, but most facilities have not applied it. Ask for the cybersecurity remote access policy and most operators cannot produce a current version. The governance layer rests on three distinct document types, each with a specific function. A policy establishes what the organization is committed to and what is mandatory. It uses mandatory language: "Employees shall report suspected security incidents within one hour." "Remote access to OT systems requires prior authorization from the site security manager." The policy is the standard against which auditors measure compliance -- if it is not in writing, it does not exist in an audit context. A procedure defines step-by-step how a policy requirement is carried out, with enough specificity that no interpretation is needed. The policy says remote access must be authorized and logged. The procedure specifies: which ticketing system to use, that credentials must be time-limited, which VPN gateway is approved, and that a session log entry is required before connection begins. Each procedure traces to a specific policy requirement. Change the policy and every linked procedure requires review. A guideline describes a recommended approach for situations where a procedure would be too rigid. It is advisory and cannot be audited for compliance -- but it provides valuable direction for situations the procedure does not specifically address. The single most important distinction is auditability: policies and procedures can be audited, guidelines cannot. That difference determines whether a document creates accountability or merely provides guidance. The practical urgency is regulatory: NERC CIP governs power utilities in North America, NIS2 applies to operators of essential services in Europe, and sector-specific cybersecurity requirements are expanding globally. Most ICS operators face some compliance documentation requirement. In every case, the auditor's questions follow the same pattern: does a documented policy exist, does the procedure match the policy, and do records confirm the procedure was followed? Governance documents are what remain auditable when the technical controls are uncertain. Start with a remote access policy -- it is the most common finding in ICS security audits and addresses the most immediate operational risk.

Building the Asset Inventory

Every structured security activity in an ICS environment depends on one prerequisite: a complete picture of what is on the network. Risk assessment needs a list of what exists and what risks each asset carries. Zone design requires knowing which assets belong together. Security level selection -- covered in Chapter 6 -- depends on how critical each asset is to the process. Patch management only functions when you know which firmware versions are running and on which devices. Without an accurate asset inventory, every downstream decision rests on assumptions. An asset model is a structured record of every asset in the IACS, covering both physical assets (PLCs, RTUs, HMIs, engineering workstations, network devices, sensors, actuators) and logical assets (software applications, configuration files, network connections, and access credentials). Useful asset records capture more than name and location: process function, criticality to operations, physical location, network connections, and current software and firmware version. One attribute consistently overlooked is lifecycle status. Knowing whether a device is operational, approaching end-of-maintenance, or already past the vendor's end-of-support date changes every decision about it. A PLC running firmware the vendor no longer patches cannot be secured through software updates. The response is compensating controls -- network isolation, enhanced monitoring, replacement planning -- and those responses require a known device with a documented status. Gathering this network data in OT environments requires passive monitoring or a manual site walkdown. Active scanning, which floods devices with probe packets to identify them, can crash legacy PLCs and RTUs that were never designed to handle unsolicited network traffic. The asset model must be assigned to a named role with clear update obligations, integrated into every change procedure in the facility. A device added during a maintenance window without a change record, a field device swapped without updating the register, a firmware update not reflected in the inventory -- each of these makes the model less accurate and every security decision less reliable. The moment an asset model stops being maintained, it starts misrepresenting the network it is supposed to describe.

What's Next

With ownership defined, the governance layer in place, and the asset inventory established, Chapter 6 moves to the architectural question: how do you organize those assets into zones, design the conduits that connect them, and assign security levels that match the risk each zone carries? The zones-and-conduits model is the primary ICS network security architecture tool in IEC 62443, and it builds directly on the asset model this chapter describes.

Reflect

• The IEC 62443 role framework identifies four distinct roles: asset owner, integration service provider, maintenance service provider, and product supplier. In your environment, which role holds each set of obligations -- and are those obligations explicitly assigned, or implicitly assumed?
• The governance section distinguishes policies (mandatory, auditable) from procedures (mandatory how-to) from guidelines (advisory, not auditable). Review one security-related process in your environment -- remote access, for example. Does a policy exist? Does a procedure match it? Are records maintained that confirm the procedure is followed?
• The asset model must capture lifecycle status for every device, not just name and location. For the most critical PLCs and RTUs in your environment, do you know which are past vendor end-of-support? If a device cannot be patched, is there a documented compensating control?
• Industroyer entered through a dual-homed device that bridged IT and OT networks without documentation or a policy preventing it. Are there devices in your OT environment that connect to both the corporate and control networks simultaneously -- and does your asset inventory reflect those connections?