The ICS Security Program

The Update That Destroyed 45,000 Machines

On June 27, 2017, a routine software update installed itself on the computers of approximately 80 percent of all businesses doing business in Ukraine. MeDoc is accounting software required by Ukrainian tax law, and the update looked identical to every previous patch. What it contained was a wiper -- code designed to permanently destroy data and render machines unbootable -- delivered through a channel no security filter had reason to question. Maersk, the world's largest container shipping company, lost 45,000 workstations and 4,000 servers within hours. Merck lost manufacturing systems with an estimated recovery cost of $870 million. Neither company was targeted specifically. Each had routine connections to Ukrainian operations, and those connections were enough. What determined whether an organization survived the attack intact was not the sophistication of any individual technical control. It was whether three routine security program disciplines were in place: network segmentation to stop lateral movement, patch management to close the Windows vulnerability the malware exploited, and credential controls to prevent harvested passwords from authenticating across the entire network. Organizations with those disciplines functioning saw the spread stop at zone boundaries. Organizations without them lost every machine connected to their corporate network. This chapter covers the structure that makes those disciplines systematic: the lifecycle that governs when security decisions must be made, the eight program elements that define what a security program must contain, the maturity model that measures how well it is functioning, the regulatory requirements that create legal obligations for specific sectors, and the supply chain controls that address the access category this incident made impossible to ignore.

The Lifecycle That Security Decisions Live In

Security for an industrial control system is not a one-time project completed at commissioning. IEC 62443 structures security activities across an eight-phase lifecycle spanning the full operational life of an IACS: Specification, Design, Implementation, Verification, Validation, Operation, Maintenance, and Decommissioning. These eight phases group into three functional cycles. The Assess cycle covers Specification and Design. The Develop cycle covers Implementation, Verification, and Validation. The Maintain cycle covers Operation, Maintenance, and Decommissioning. The most consequential insight from this structure is proportional: the earlier a security decision is made, the cheaper it is and the more options remain available. A requirement captured at Specification costs a design decision. The same requirement missed at Specification and discovered after commissioning costs a retrofit in an operational OT environment -- among the most expensive and operationally disruptive activities in the industry, requiring maintenance windows negotiated with operations and validated by vendors whose schedules are not aligned with the asset owner's urgency.

Specification is the single most important phase in the entire lifecycle. This is where the System Under Consideration is formally bounded, where each zone receives its Target Security Level, and where the security requirements that all subsequent phases must satisfy are documented. A Target Security Level is not a preference -- it is a formal commitment that determines which controls must be procured, installed, and maintained across the operating life of the system. Any requirement not captured at Specification must be engineered in later at significantly higher cost, or compensated for through additional controls that add operational complexity without fully resolving the underlying gap. The Design phase translates Specification outputs into concrete architecture: the zone and conduit layout, the component selection criteria, and the integration points between systems. Security requirements absent from the design will not appear in the finished system regardless of how carefully the build is executed. Implementation builds the design. Verification confirms the build matches the design. Validation -- the final step of the Develop cycle -- confirms the finished system meets the Target Security Levels committed to at Specification. Validation is the formal quality gate that closes the gap between what was specified and what was built. An organization that completes a genuine validation phase can demonstrate with documented evidence that the system achieves what was specified, not merely approximated.

The Maintain cycle is the most consistently under-resourced phase. Controls installed at commissioning degrade as the environment evolves: devices are added without documentation, network paths accumulate informal connections, vendor access credentials persist long after the project that created them ended, and patch cycles slip under operational pressure. Every material change to the system's security posture should trigger a loop back to Specification for that change. Security is not a state achieved at commissioning; it is a discipline sustained across the operating life of the system. The three role swimlanes established in Chapter 5 map directly onto this lifecycle structure. The Asset Owner holds accountability across all eight phases -- from initial Specification through final Decommissioning. The Integration Service Provider's formal security obligations begin at Design and run through Validation, covering the phases where the architecture is defined, built, and verified. The Maintenance Service Provider's obligations begin at Operation and continue through Decommissioning, covering the longest phase of the system's life and the one where most real-world security drift occurs. Each role's accountability is bounded by the phases it occupies, and decisions made in each phase carry consequences that the next accountable party inherits.

The Eight Security Program Elements

The 2024 edition of IEC 62443-2-1 restructured the Cyber Security Management System requirements into eight Security Program Elements (SPEs), aligning the standard with ISO 27001:2022. The alignment means controls that satisfy a requirement in one framework simultaneously satisfy the equivalent requirement in the other, reducing duplicated audit effort for organizations subject to both. The eight elements cover the full program: organizational governance, configuration discipline, network controls, component hardening, data protection, access management, incident handling, and system availability. No element is optional if the others are to function. Each depends on the others to close the gaps it cannot address alone -- a robust access control program built on an inaccurate asset inventory will protect accounts to systems the organization did not know existed.

SPE 1 -- Organizational Measures establishes the governance foundation: documented policies, personnel security processes, training and awareness programs, and the supply chain security requirements embedded in contracts with vendors and service providers. Without a functioning SPE 1, the other seven elements have no documented ownership and no auditable accountability. SPE 2 -- Configuration Management addresses the asset inventory, system architecture documentation, and change control processes that keep the organization's picture of its own network accurate. Every device addition, firmware update, and topology change must flow through change control and be reflected in the configuration record. Configuration management is what prevents the asset model from diverging from the actual running network. SPE 3 -- Network and Communication Security covers network segmentation, remote access controls, and wireless security -- the architectural layer that the zone and conduit model from Chapter 6 implements. The conduit allow-lists, jump server architecture, and Industrial DMZ design all belong under this element. SPE 3 is the element whose absence allowed NotPetya to reach every connected location across Maersk's 600-site global network. SPE 4 -- Component Security addresses endpoint hardening, patch management, malware protection, and portable media controls at the individual device level. Hardening means disabling unused ports and services, replacing default credentials, and establishing patching processes matched to the operational constraints of each specific device class. Patch management under SPE 4 is where the MS17-010 patch that would have blocked EternalBlue belongs.

SPE 5 -- Data Protection covers data classification, encryption for data in transit and at rest where justified by risk, key management, and integrity verification. Encryption decisions in OT environments require more careful risk analysis than in enterprise IT: some legacy field protocols cannot sustain the computational overhead, and timing-critical communication paths cannot tolerate the latency that cryptographic processing introduces. Risk-based selection is more appropriate than blanket application. SPE 6 -- User Access Control implements the identification, authentication, and authorization controls that determine who can reach which system, through which path, verified by which mechanism. Least privilege -- limiting each account to only the access the role genuinely requires -- reduces the consequence of any single credential compromise. Multi-factor authentication, session time limits, and periodic access reviews all belong under this element. The shared domain administrator credentials that Mimikatz harvested across Maersk's flat network were an SPE 6 failure: no least-privilege model and no credential compartmentalization gave a single compromised workstation authenticated access to every system on the network. SPE 7 -- Event and Incident Management covers detection capabilities, audit logging, incident response procedures, and vulnerability handling. Detection without logging creates incidents with no forensic trail. Logging without defined response procedures creates records that accumulate without action. SPE 8 -- System Integrity and Availability addresses business continuity planning, backup and recovery for OT systems, fail-safe state definitions, and the restoration procedures that return systems to operation after disruption. OT-specific requirements apply throughout: backup intervals must account for what a process safety system can tolerate losing, restoration procedures must be tested against actual hardware rather than assumed to work, and fail-safe states must move the physical process to a safe condition independent of software behavior during recovery.

Measuring Program Maturity

Having a security program document does not mean having a functioning security program. IEC 62443-2-1 defines four maturity levels that describe how developed a program actually is, calibrated by consistency, documentation, and measurability. Maturity Level 1 (ML1) is Initial: activities happen, but they are ad hoc, undocumented, and person-dependent. The program exists only to the extent that specific individuals know how to perform specific tasks, and it disappears when those individuals leave. ML2 is Managed: processes are documented, procedures exist, and training materials are in place. The organization can demonstrate that a policy covers each requirement and a procedure specifies how that policy is executed. ML2 is the threshold that matters most in practice -- the difference between a security program that can be audited and one that exists only in someone's head. ML3 is Defined and Practiced: the ML2 activities are executed consistently and repeatably across the entire IACS, not just at one site and not dependent on one individual. The program functions the same way regardless of who executes it, because the procedures are specific enough to leave no room for interpretation. ML4 is Improving: performance is measured with metrics and the organization can demonstrate improvement over time -- mean time to detect, patch coverage rates, training completion percentages, and similar operational indicators. Most organizations implementing a new security program start at ML1 and target ML2 as their first meaningful milestone, because ML2 is the threshold at which an auditor can verify the program exists independently of talking to the people who run it.

What auditors verify in either a self-assessment or a third-party conformity assessment is objective evidence: documents, configuration records, test results, training records, and architectural drawings that prove the controls exist and function as described. IEC 62443-2-1 Clause 5.2 defines twelve categories of acceptable evidence: configuration records, legal documents including contracts and signed personnel statements, organizational charts and personnel records, product documentation, screenshots of security settings, security assessment reports, test plans and results, service policies and procedures, training materials and attendance records, architecture drawings and test results, automated reports generated by the IACS itself, and user documentation. A complete evidence package does not guarantee a high maturity rating, but a missing evidence category removes the auditor's ability to verify that specific requirement. The audit observation that recurs across every ICS security engagement is not the absence of security activities -- it is the absence of documentation proving those activities took place consistently. "We do it, we just don't document it" has never satisfied a conformity assessment.

The Regulatory Floor: What Is Actually Mandatory

Most ICS practitioners work with three types of document simultaneously without always distinguishing between them. A standard is a consensus document created by bodies like ISO, IEC, and ISA. The word "shall" in a standard is normative -- it defines what is required if the standard applies -- but applying the standard is a choice unless a regulator or a contract requires it. A regulation is a legal instrument enforced by a government authority, carrying penalties that can reach operational restrictions or criminal liability. A framework is structured voluntary guidance with no enforcement mechanism. The distinction matters because it defines where the legal floor sits and where professional discretion begins. Mandatory regulations in many sectors cite IEC 62443 and NIST as the technical implementation standards they expect operators to use -- which means satisfying the technical requirements of the standard while meeting the legal obligations of the regulation simultaneously.

For operators of the North American Bulk Electric System, the mandatory floor is NERC CIP -- the Critical Infrastructure Protection standards issued by the North American Electric Reliability Corporation under Federal Energy Regulatory Commission authority. Non-compliance carries penalties reaching one million dollars per violation per day. CIP-002 requires classifying every BES Cyber System -- the hardware and software components whose loss would materially affect grid reliability -- as High, Medium, or Low Impact based on the operational consequence of failure or compromise. That classification determines which controls apply. High and Medium Impact systems carry the full set of CIP requirements; Low Impact systems carry a subset. CIP-005 defines the Electronic Security Perimeter: the logical network boundary around High and Medium Impact systems, the access points and communication paths that cross it, and the controls governing remote interactive access from outside the perimeter. CIP-007 hardens individual systems inside that boundary, specifying 35-day patch evaluation cycles -- each identified vulnerability must be assessed within 35 days of publication -- port management to disable unused network services, malware prevention appropriate to the operating environment, and event logging with defined retention periods. NERC CIP and IEC 62443 are used together in most mature grid programs: the IEC standard provides engineering methodology and technical requirements; the NERC standard provides the mandatory compliance framework and the audit process that enforces it.

In Europe, NIS2 -- the Network and Information Systems Directive 2 -- extended mandatory cybersecurity obligations from 7 sectors to 18. Annex I covers Essential Entities in high-criticality sectors: energy, transport, banking, health, drinking water, and digital infrastructure. These entities face proactive regulatory supervision, meaning authorities can conduct audit and enforcement activity before any incident occurs. Annex II covers Important Entities including manufacturing, chemicals, and food production. These face reactive oversight, meaning regulatory action follows an incident rather than a scheduled audit cycle. For an OT engineer at a manufacturing facility or a chemical plant, the Annex II designation changes the enforcement model, not the substantive requirements. Article 21 defines ten mandatory security measures, six of which apply directly to OT environments: risk analysis and information system security policies, incident handling, business continuity including backup management and crisis management, supply chain security including security-related aspects of relationships between entities and their suppliers and service providers, security in network and information system acquisition, and the use of cryptography and encryption where appropriate. Article 23 establishes a three-stage incident reporting timeline: a 24-hour early warning to the relevant national authority, a 72-hour notification including an initial severity assessment and indicators of compromise, and a one-month final report covering threat analysis, root cause assessment, and mitigation measures taken. NIS2 entered force across the EU in October 2024, though individual member state transposition and enforcement timelines varied through mid-2025.

Following the Colonial Pipeline incident in 2021, the Transportation Security Administration issued cybersecurity directives for pipeline, rail, and aviation operators -- the first mandatory cybersecurity requirements in those sectors. The directives are performance-based: operators submit implementation plans describing how they will achieve specific security outcomes, rather than checking compliance against a fixed control list. Current pipeline directives require IT-to-OT network segmentation, multi-factor authentication for all remote access to OT systems, and continuous monitoring of OT network environments for cybersecurity threats. They also require risk-based patch management, annual penetration testing of OT systems, and independent third-party security assessments on a recurring schedule. Any significant cybersecurity incident -- a confirmed intrusion, ransomware affecting operational systems, or any event causing or likely to cause operational disruption -- must be reported to CISA within 12 hours of detection. Rail and aviation sectors carry equivalent directives with the same core OT requirements. All three sectors' directives explicitly cite IEC 62443 and NIST SP 800-82 as the technical standards operators are expected to implement. The path from the voluntary standard to the mandatory regulation is now direct in the transportation sector.

Supply Chain Security: The Risk That Arrives With the Vendor

Most ICS security programs focus on what enters the network through unauthorized paths. Supply chain security addresses a structurally different problem: the risk that enters through authorized, trusted channels as part of normal operations. Four categories of third-party actor create distinct access paths into OT environments, each requiring a different defensive approach. Product suppliers manufacture PLCs, sensors, firmware, and safety systems. Vulnerabilities embedded in their development process ship with the product and persist across every installation it serves, updated and undetected, for the operational life of the hardware. Integration service providers design, install, and commission the IACS. They leave with detailed architectural knowledge of the system -- zone layouts, device addresses, communication paths -- and frequently with remote access credentials created during commissioning that were never subsequently removed. Maintenance service providers hold ongoing support contracts that include standing remote access, often shared across the vendor's entire support team and rarely reviewed by the asset owner after the initial setup. Software vendors supply SCADA platforms, historians, HMI software, and engineering workstation applications. Their update channels are trusted pathways into every installation they serve, and those channels carry the same trust on day 1,500 of the relationship as they did on day one, regardless of how the vendor's security posture has changed in the interval.

Third-party access in OT environments carries a structural characteristic that distinguishes it from enterprise IT access management: it is rarely session-based. In enterprise IT, remote access is typically granted on request, authenticated against current credentials, time-limited, and revoked at session end. In OT environments, credentials created by an integrator at commissioning often remain active for years. They are shared across the vendor's team rather than assigned to named individuals, which means no individual is accountable for any specific action taken with them. The remote access tools installed by those integrators frequently bypass the asset owner's monitoring systems, because they were set up outside the owner's toolset and never registered with it. Administrative permissions are routinely scoped to cover far more systems than any specific maintenance task requires. In 2026, coordinated attacks against US water treatment facilities across multiple systems identified persistent, over-scoped vendor access as a primary contributing factor. The common element was not a novel exploitation technique. It was standing credentials to OT systems that no one in the asset owner organization was actively managing. The question that defines whether supply chain access is controlled or merely assumed is specific: do you know every third party with current remote access to your OT systems, when each account was last used, and can you revoke any of them within one hour?

IEC 62443-2-4 defines the security program requirements that integration service providers working on IACS on behalf of asset owners must meet: risk management processes for integration projects, personnel security, secure engineering practices, and remote access controls for ongoing maintenance. Service providers can achieve formal certification against this standard through accredited certification bodies, and asset owners can make that certification a condition of procurement before an integrator touches the network. ISA maintains a public registry of certified providers. A contract that does not reference 62443-2-4 compliance has no enforceable security standard attached to it -- a vendor's assurance that they "follow security best practices" carries no audit value without a defined standard to measure against. IEC 62443-4-1 addresses product vendors, defining the secure development process requirements that manufacturers of PLCs, field devices, and embedded systems must follow: security requirements definition, secure design practices, secure coding guidelines, defect management, patch delivery across the product's operational lifetime, and end-of-life processes that do not leave installations without updates silently. A product certified to 62443-4-1 demonstrates that the manufacturer's development process can maintain security assurance as the product evolves -- not just at the point of purchase, but across the five to fifteen year operational life typical of OT hardware. The 2024 edition of IEC 62443-2-1 elevated supply chain security from a contract consideration to a named component of SPE 1, making it a formal, auditable element of the security program. The standard explicitly states that accountability stays with the asset owner even when implementation involves service providers and product suppliers. Security requirements can be passed to vendors through contracts and enforced through compliance verification -- but the obligation for the system's security posture remains with the organization that operates it.

What's Next

Chapter 7 has covered the program structure: the lifecycle governing when security decisions must be made, the eight elements defining what the program must contain, the maturity model measuring how well it is functioning, the regulatory obligations creating legal requirements for specific sectors, and the supply chain disciplines addressing the most consistently underestimated risk category in OT environments. Chapter 8 moves to the operational question: once the program is in place and the architecture is built, how do you know when something is wrong? Visibility, detection, and response -- the disciplines that determine whether an organization can identify an intrusion, understand its scope, and act before the attacker's objective is achieved.

Reflect

• The lifecycle places Specification as the most consequential phase because Target Security Levels are committed to there. For the most critical zone in your environment -- the SCADA zone, the safety instrumented system zone, or whichever carries the highest consequence of compromise -- do you have a documented Target Security Level with a recorded rationale, or was the security level implied by whatever controls happened to be purchased at installation?
• SPE 2 (Configuration Management) requires that every device addition, firmware update, and network topology change flows through a change control process and is reflected in the current asset inventory. In your environment, does the change process cover vendor-performed changes, or only changes made by the asset owner's own staff -- and is there a record of every device currently on the network matched to the device that was originally installed?
• The maturity model identifies ML2 as the threshold at which a security program can be independently verified. For the most important security activity in your environment -- whether that is incident response, patch management, or remote access authorization -- does a documented policy and a matching procedure exist, and do records confirm that procedure has been followed consistently across the past 12 months?
• The supply chain section identifies standing, over-scoped vendor credentials as the most consistently underestimated risk category in OT security. For your environment: do you know the identity of every third party with current remote access to OT systems, when each account was last used, and could you revoke any specific account within one hour if required?