Your PHA and LOPA are already a cyber risk assessment in disguise

This is part 10 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 11, skills as the bottleneck.

Industrial cybersecurity is often presented to plant management as a tax on production: new tools, new consultants, a new methodology nobody on site has used before. On a chemical, pharmaceutical or continuous-process site, that framing is wrong. The site already runs a disciplined risk process. It identifies hazards, rates consequences, credits protection layers, manages change and audits itself on a fixed cycle. A good OT security programme reuses all of that and adds one question to it. Nobody on the HAZOP team has to learn a new trade.

The method below has four field steps. It fits within the ISA/IEC 62443 series, and in particular IEC 62443-3-2, the part that defines how to carry out a security risk assessment for a system under consideration and derive its zones, conduits and target security levels.

What your safety studies already contain, and what they don’t

A process hazard analysis (PHA, often a HAZOP) and a layer of protection analysis (LOPA) describe, scenario by scenario, what happens when the process leaves its safe envelope, how bad it gets and which safeguards stand in the way. Their consequence categories are the ones a cyber risk assessment needs: harm to people, harm to the environment, loss of production, regulatory non-compliance.

IEC 62443-3-2 is consequence-based in the same sense. Its initial, high-level risk assessment is a worst-case exercise: as the ISA Global Cybersecurity Alliance puts it, the likelihood is often expressed as a conditional probability equal to one, so the question becomes “how bad could it be?”. That is exactly the question the PHA has already answered, in the site’s own risk matrix and language. The same white paper draws existing PHAs and the corporate risk matrix as inputs to that initial assessment.

The shortcut has limits, and it is better to know them up front.

The LOPA point deserves attention. An attacker who reaches the control network can, in principle, manipulate the basic process control system and a programmable safety system in the same move, a common-mode failure that the independence assumed between protection layers does not cover. ISA-TR84.00.09, the ISA84 technical report on cybersecurity in the safety lifecycle, frames the cyber PHA around exactly this: identifying hazard scenarios in which the initiating event and all the control barriers are “hackable”.

Some safeguards are immune. A relief valve, a mechanical trip or a safety function built without programmable electronics cannot be reprogrammed from a network; the functional safety article in this journal explains why that property matters. Others need a second look before they keep their full credit. Structured “cyber PHA” or “cyber HAZOP” workshops exist precisely to run that second look with the same team and the same worksheets.

Step 1: map the environment and assess the risk

Define the system under consideration in full: every asset and every link, including the links nobody claims. Bring together automation engineers, instrument technicians, process engineers, safety specialists, IT and operations. Start from the existing PHA and LOPA data rather than from zero.

Then walk the unit. Have the team physically check what is really connected: the forgotten modem in a skid panel, the vendor laptop left on a maintenance port, the switch that was “temporary” three turnarounds ago. Drawings rarely tell the whole truth.

On a pharmaceutical site, the same exercise reads the GMP risk assessments alongside the process safety studies. A falsified temperature on a bioreactor may not hurt anyone, but it can cost a batch and put a patient at risk. Product quality and data integrity belong in the consequence scale next to people, environment and production.

Step 2: zones, conduits and target security levels

Partition the system into zones and conduits, and give each zone a target security level based on real risk. ISA/IEC 62443 defines four levels, from SL 1 (protection against casual or coincidental violation) to SL 4 (protection against intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation). A safety instrumented system usually warrants a high target; a historian rarely does.

A few partitioning rules carry most of the value, and IEC 62443-3-2 lists them among its zoning requirements:

• Separate business and control assets. Keep the business network out, typically through an industrial DMZ.
• Separate safety-related assets. Put safety instrumented systems in their own zone, apart from the process control system.
• Separate temporarily connected devices. Vendor and maintenance laptops belong in a zone of their own, not on the control network.
• Separate wireless and externally connected devices. Wireless equipment and anything reached through an external network, vendor remote access included, go through controlled conduits, not tolerated exceptions.

Start the zone mapping with the most hazardous reaction or storage areas. The PHA already names them, and that is where the fastest risk reduction lies. The article on zones and conduits describes the same order of work: consequence first, network design last.

On the Purdue model: it remains an excellent backbone for this work, and IEC 62443 adds the security lens on top. For precision, “Purdue” is not a synonym for ISA-95. The level hierarchy comes from the Purdue Reference Model for computer-integrated manufacturing, published through ISA in 1989; Theodore J. Williams and the Industry–Purdue University Consortium extended it into the Purdue Enterprise Reference Architecture in the early 1990s. ISA-95, published from 2000 and adopted internationally as IEC 62264 (first edition 2003), is a standard for enterprise-control integration based upon that reference model.

Step 3: layer the controls and build the culture

ISA/IEC 62443 groups its technical requirements under seven foundational requirements, scaled to each zone’s target level in IEC 62443-3-3 (systems) and IEC 62443-4-2 (components). The controls that matter most on a plant map onto them directly.

For legacy equipment that can be neither patched nor replaced, compensating measures do the job, provided they are documented and reviewed.

The part that decides whether any of this lasts is less technical: fold cybersecurity into the processes the site already owns. Add a security impact check to management of change (MOC), put a cyber scenario in the next operator drill, and ask vendors for a software bill of materials (SBOM) when they deliver. The MOC change is the cheapest and often the most effective. A single line on the form, “and what about cyber?”, makes the engineer stop at the vendor’s remote support request or the new switch in the skid panel, at the moment the change can still be redesigned. No new tool, no new committee, and the form is one engineers already fill in.

Step 4: monitor, measure, adapt

Track indicators that mean something: mean time to detect and respond, zone coverage, status of patches and compensating measures, completeness of MOC security reviews. Reassess whenever the installation changes or the threat evolves.

EUCALEX recommends aligning the security audit cadence with the process-safety cycles the site already runs, so cyber reviews ride on existing governance instead of competing with it. In the United States, that means OSHA’s Process Safety Management standard (29 CFR 1910.119) and EPA’s Risk Management Program (40 CFR Part 68): PHAs updated and revalidated at least every five years, compliance audits at least every three. In the European Union, the equivalent anchor is the Seveso III Directive (2012/18/EU), under which upper-tier safety reports are reviewed at least every five years and upper-tier establishments are, as a rule, visited by the inspectorate at least once a year, unless the competent authority has set an inspection programme based on a systematic appraisal of the hazards.

A maturity model helps if it is used to plan the next step. Used to grade the site manager, it teaches people to hide gaps. The sites that keep progressing review their OT security indicators every quarter, in the same meeting and with the same discipline as their safety indicators.

Where to start

1. Pull the latest PHA and LOPA for the three most hazardous units. List the scenarios whose initiating event or safeguards involve a programmable device.
2. Run one cyber HAZOP session on one unit. Same facilitator, same worksheets, one extra guideword: “deliberately”.
3. Re-rate the credit of programmable layers. Mark each one as immune, reduced or to be confirmed, and record why.
4. Draw the first zones from the consequences. SIS, control, business, temporary devices, wireless, external connections.
5. Put the cyber review on the safety calendar. Next PHA revalidation, next audit, next inspection: the cyber questions go on the same agenda.

Five common mistakes

• Starting from a blank risk matrix. The site already has one, and management already trusts it.
• Keeping full credit for programmable layers. Two layers that one intruder can reach at once are not independent.
• Using the Purdue levels as the zones. The levels describe functions; zones come from consequences and security requirements.
• Treating the SIS like any other controller. It needs its own zone and usually the highest target level on the site.
• Running cyber reviews on their own calendar. A second governance cycle competes with the first and loses.

The cyber risk assessment adds one question to the safety studies, and presented that way it becomes part of the safety culture the plant is proud of.

References

• IEC 62443-3-2:2020, Security risk assessment for system design. webstore.iec.ch
• ISA Global Cybersecurity Alliance, Leveraging ISA 62443-3-2 for IACS Risk Assessment and Risk Related Strategies (white paper, May 2021). isa.org
• L. O’Brien and M. Duck, Cyber-related process hazard analysis, ISA InTech, January–February 2020. isa.org
• PERA, The Purdue Enterprise Reference Architecture. pera.net
• OSHA, 29 CFR 1910.119, paragraphs (e)(6) and (o)(1). osha.gov
• Directive 2012/18/EU (Seveso III), Articles 10 and 20. eur-lex.europa.eu