A More Practical View of OT Cyber Security

Over the past few months, I have spent more time working with industrial cyber security: reading IEC 62443, reviewing system architectures, looking at network segmentation, and thinking about how cyber security fits into systems integration.

The biggest change has been how I frame the problem.

It is easy to think of OT cyber security primarily in terms of technical controls: firewalls, VLANs, passwords, patching and remote access.

Those controls matter, but they are not the starting point.

The starting point is understanding the system, the consequences of failure or compromise, and the security requirements that follow from that risk.

Questions such as these come first:

• What system are we protecting?
• Which functions are critical?
• What happens if control, communications or visibility are lost?
• Which systems genuinely need to communicate?
• Who needs access, and for what purpose?
• What threats and vulnerabilities are relevant?
• What security requirements follow from the risk?

Only then does it make sense to decide which technical controls are required.

The controls should follow from an understanding of the system and its risk, rather than being the starting point.

Purdue is not the security architecture

One distinction that becomes increasingly useful is the difference between the Purdue Model and IEC 62443 zones and conduits.

The Purdue Model provides a useful way of describing the functional hierarchy of an industrial control system.

Zones and conduits answer a different question.

They describe how assets are logically grouped from a security perspective and how communication is permitted between those groups.

A useful distinction is:

Purdue helps describe where functions sit within the industrial control hierarchy.

Zones and conduits help define security boundaries and the communication that crosses them.

The two can complement each other, but they should not be treated as interchangeable.

The functional architecture provides context. The security architecture should then be justified by risk and required communication.

A firewall is only part of the design

Placing a firewall between two networks does not automatically create meaningful segmentation.

The important question is:

What should actually be allowed through it?

Answering that requires an understanding of:

• which devices need to communicate;
• which protocols and services are required;
• which direction communication needs to flow;
• which ports are actually necessary;
• whether engineering, historian, remote-access or management traffic needs to cross the boundary.

This is where principles such as deny by default become engineering decisions rather than abstract security statements.

If the required communication is not understood, it is difficult to design a restrictive firewall policy without either breaking the system or allowing far more traffic than necessary.

Networking knowledge matters

OT cyber security exposes gaps in networking knowledge very quickly.

Terms such as switches, routers, VLANs, TCP, UDP, ports, subnets and gateways can become familiar long before their practical implications are properly understood.

That becomes a problem when designing or reviewing segmented industrial networks.

There is a significant difference between saying:

The HMI communicates with the PLC.

and being able to say:

The HMI communicates with the PLC using these required services, across this network path, through this security boundary.

The second description is much more useful when designing firewall rules, defining conduits, troubleshooting communications or reviewing whether a connection should exist at all.

The deeper I get into OT cyber security, the clearer it becomes that good networking knowledge is not optional.

Zones need an engineering justification

A zone should not simply be a coloured box added to a network drawing.

Assets should be grouped because they share relevant security characteristics: function, criticality, trust, access requirements, exposure or consequence of compromise.

The useful question is therefore not:

How many zones should this system have?

It is:

What security boundaries are justified by the system and its risk?

That produces a much more defensible architecture.

It also means that two systems that look similar from a control perspective may legitimately have different zone structures because their risks, dependencies or operational requirements are different.

IEC 62443 becomes clearer when the parts have a purpose

The IEC 62443 series becomes easier to understand when the individual parts are related to the engineering activities they support.

For a systems integrator, three parts are particularly useful to distinguish:

IEC 62443-2-4 is concerned with the security capabilities and processes of organisations providing integration and maintenance services.

IEC 62443-3-2 addresses security risk assessment for system design. This is where the system under consideration, zones and conduits, risk assessment, target security levels and security requirements come together.

IEC 62443-3-3 defines system security requirements and security levels that can then be applied to the system and its zones and conduits.

In simplified terms:

2-4 — how the integrator works.

3-2 — how the system risk and security architecture are established.

3-3 — what security capabilities the system needs to provide.

Looking at the standards this way makes the relationship between process, risk and technical design much clearer.

Cyber security needs to start early

Many cyber security problems become difficult to solve simply because they are discovered too late.

If the architecture has already been fixed, equipment purchased, communication paths established and remote access agreed, many important security decisions have effectively already been made.

A better engineering sequence is:

Security should influence the architecture while it is being developed, not simply review it once the design is complete.

Security is also about maintainability

Another useful lesson is that OT cyber security overlaps heavily with reliability, maintainability and normal engineering discipline.

A backup is only useful if the system can actually be restored from it.

A patch cannot be treated purely as an IT update if it could affect communications, redundancy, control behaviour, vendor support or system availability.

An asset inventory is not useful if it becomes obsolete as soon as the system changes.

The same applies to network diagrams, firewall rules, software baselines, user accounts and recovery procedures.

These are not simply pieces of audit evidence.

They are part of making the system understandable, recoverable and supportable throughout its lifecycle.

The systems integrator has a significant role

Systems integrators have considerable influence over the eventual security of an industrial system.

They frequently determine or influence:

• system architecture;
• network topology;
• equipment selection;
• network and firewall configuration;
• user access;
• remote support arrangements;
• system testing;
• commissioning;
• backup and recovery arrangements;
• documentation.

Each of those decisions can affect cyber security.

That is why treating cyber security as a separate specialist activity added near the end of a project is problematic.

The people designing and integrating the control system are already making security-relevant decisions, whether those decisions are explicitly labelled as cyber security or not.

A different way of looking at the architecture

The biggest change in my own thinking is therefore not a particular technology or standard.

It is the questions I ask when looking at an industrial system.

Rather than simply asking what is connected, I increasingly want to know:

Why are these assets grouped together?

What communication crosses this boundary?

Why is that communication required?

What would happen if it were compromised or unavailable?

Who should be able to access it?

What requirement is the control satisfying?

How will we demonstrate that it works?

Those questions lead naturally from the control-system architecture to risk, security requirements, technical controls and testing.

That is probably the most useful lesson so far.

OT cyber security makes far more sense when it is treated as part of control-system engineering, rather than something applied to the control system afterwards.