Industrial Zero-Trust Micro-Segmentation

Executive Overview

A best practice in Industral Automation Control System Cyber Security is Zones and Conduits. These are complex to implement without strong identity and an identity-based firewall. Merging the best practices of a Zero-Trust Network Architecture with the ISA/IEC-62443 Zones and Conduits model improves security due to simpler implementation and greater control and audit.

If you would like to discuss this live, please feel free to Book a Meeting, or have us Contact you. The Chat icon in the lower left is also answered by our domain experts directly.

Overview

Protecting Industrial Automation Control Systems (IACS) from cyberthreats is top of mind for industrial organisations. Segmenting the network to limit the blast-radius is a best-practice of a Defense In Depth strategy, a best-practice easier said than done.

Complex, under-documented data flow requirements, legacy equipment that interacts poorly with next-generation firewalls leads rise to impossible to manage VLAN and ACL rules on network switches and the risk of breaking the core mission of the equipment. Once finished, little has been achieved since the exceptions outweigh the restrictions.

The International Society of Automation (ISA) publishes the ISA99 set of standards and technical reports, cross-published as The International Electrotechnical Commission (IEC) standards ISA/IEC-62443. The ISA/IEC-62443 standards are arranged in four groups, corresponding to different focuses and audiences. Part 3-3 defines system security requirements and security capability levels to build and operate a safe, secure ICS network. It gives IT and operations teams common terminology to build industrial infrastructures that are effectively protected against both network threats and accidental events. Operational Technology meets IT security.

A Zero-Trust Network Architecture operates on the principle of assuming nothing of security from location or network connection. Of leveraging identity and posture of each actor to determine connectivity. By using the pairwise-identity of source and destination to determine connectivity, rather than network interconnect and VLAN, we can implement the ISA/IEC Zones and Conduits without the operational and configuration complexity.

ISA/IEC 62443-3-3 Security Principles

Least Privilege

Each system, or user, should only have the minimum rights to perform their work. This slows an attack when an account or system is compromised.

Rather than on/off access (e.g. a VPN), user-based role-based access controls are required.

Defense In Depth

A good defense has multiple layers. It slows down an attacker at each layer, it provides ongoing visibility. It gives the defender time to respond. Network segmentation is a tool in Defense In Depth.

Rather than ‘the industrial network’ zone, the nirvana of Defense In Depth segmentation is per-endpoint micro-segmentation, giving perfect visibility and control individually.

Risk Analysis

Industrial systems have high downside impact when risks are realised. They might injure people, pollute the environment, take down production capacity. ISA/IEC-62443-3-2 has a risk assessment framework, but Agilicus recommends the NIST family of risk assessment and analysis tools.

Compensating Security Measures

One of the central tenets of Defense In Depth: each layer will be breached, have a fallback. In an Industrial Control system this means automatic compensation. What if a system does not have the intrinsic ability to be secure? Compensating security measures include moving the security to a layer outside the device.

This means a fine-grained authorisation model, one which is not just an on/off allow/deny, but instead can look at the intrinsic protocol, understand the user role, and decide if the intended action is allowed.

Consider a simple industrial controller with a single user, single password, offered over an un-encrypted channel. This would be challenging to secure from a least-privilege, from a defense-in-depth. The compensating security measure might be a gateway that maps multiple users on one side to specific privileges and access on teh device side.

Zones and Conduits

Based on the above principles, ISA/IEC-62443 proposes a “Purdue” reference model from ISA95. It suggests creating ‘zones’ (called levels) which contain specific types of messaging. It further proposes ‘conduits’ which are essentially check-valves betwee the levels. They have grouped the equipment by common security requirements: all like process control is in a like zone.

The underlying assumption is that there is no need for east-west security within a level, and that there is no need to traverse more than one level vertically. In a simple industrial system, this may be true. As they become larger there are isolated pools of need within the same conceptual level (e.g. the painting system might be completely independent of the stamping system).

For a conduit to provide secure connectivity between zones, it must understand the levels and their needs. In practice, it becomes a way to communicate a single level, with no concept of privilege or user. All things in the ‘Enterprise’ network can talk to all things in the ‘Industrial’ network DMZ.

An implementor, once realising that there is more to be achieved, now starts thinking about how to restrict further, so that only some users, operating some things, in some levels, can perform operations on some things in another level. And here the implementation breaks down, the switches and firewalls cannot cope with the complexity, they do not have the fine grained authorisation, they do not have the user identity. So they become effectively “if you can connect to network X, you can then do operations on network Y”.

Implementation Challenges: Theory Meets Practice

The clean, simple hierarchical model outlined above and in ISA/IEC-62443 does not match the messy implementation of most Industrial Control System environments. Common challenges include:

• “My users are not uniform”. — A vendor needs access for maintenance, they have a rotating staff of people.
• “Message flows span levels”. — We are using a cloud-based big-data system which uses a messaging bus to ingest all data a from all levels.
• “I have equipment on fixed ports and insufficient IPv4 to create a DMZ”. — Port-forwarding from a DMZ for access is impossible to make precise.
• “Device A allows a single IP gateway, how can I use routing to have multiple segments”?
• “Device B has no audit or logging capability, how can I know who did what, when?”
• “I need to ensure the vendor is updating line-1, not line-2, starting only at 6-pm. How can my VPN enforce this?”
• “VLANS’s are flat, my rules are hierarchical, this causes a combinatorial explosion in number”.
• “My edge switches only support 16 VLAN’s”
• “Suddenly I am asked to provide multi-factor authentication to a device that has a compiled in password.”

How can we simplify, maintain the simple separation principles of ISA/IEC 62443 Zones and Conduits, but do so in a practical fashion?

Imagine a hypothetical industrial plant. This plant has two unlike systems, with different user user’s and different roles. For simplicity we will assume the roles are Full (Allowed) and Read-Only. One of the user consituents is a vendor, with a rotating staff of users.

In the theoretical model shown above, a VPN-based DMZ is usually used. A user, once in the DMZ, can go anywhere, and do any action (control vs read-only). No enforcement is present.

In addition to the lack of controls present, there are 2 sets of network flows possible which are undesirable: an east-west flow of network traffic is possible between the unlike control systems. This gives rise to a challenge of lateral traversal: if one system is compromised (perhaps due to a local compromise, a user opening a file from a USB key), the other can become compromised as well. Additionally, there is the possibility of network observation or transfer between the users through the DMZ.

Not discussed is the risk of exfiltration: the firewall does not block outbound.

As we explore the gaps between the conceptual ‘zones and conduits’ with the actual implementation, we find the challenge of implementing network ACL’s in the DMZ through a VPN, mapped to users. In the conceptual model, a separate subnet per unique user/role set is required. Implementing rules like ‘The vendor support can modify manufacturing line 6 after 9pm on tuesday’ become impossible: the subnet/ACL set would be too dynamic, too large.

Implementing restrictions east-west between the devices is also challenging: the existing switches at this part of the network have very simplistic rulesets, they are not advanced firewalls.

Not discussed but worrisome: the vendor shown has a rotating set of staff. Does this mean there is a shared password to the VPN? How is multi-factor authentication performed if so, is there a shared SMS reflector or code-extraction from the authentication-code generator? If the password is shared, what is the strategy to manage staff-turn over in the vendor? Is it rotated per use?

With even this very simple network and role set we have found implementation challenges in the zone/conduit model. It does not mean the model is wrong, it just means we need a better implementation mechanism.

Identity-Aware Zero-Trust Firewall Micro-Segmentation

The Agilicus AnyX platform provides for a unified authentication. Each user uses existing single-sign-on. This strong source of identity means that:

• Users at the vendor do not require a new login
• Multi-factor can be universally enforced, per user, not per company
• An audit trail is present per person, not per company
• Existing password rules are enforced, no password fatique

All inbound traffic is presented to the Agilicus AnyX platform first. This means that Geo-IP restriction rules, anti-DDoS, etc are possible and universal. Each network transaction is an individually encrypted flow, using WebSocket over HTTPS. It is impossible for any user to observe or affect the traffic of another.

Precise authorisation rules allow enforcing read-only versus full-control, time-of-day based rules. These include the User, the Role, the Resource. These rules are individually enforced without limitations associated with subnets and ACL’s in network appliances.

Conclusions

By leveraging user identity, coupled with role-based, resourced-based authorisation, we have implemented the Zones and Conduits conceptual model of ISA/IEC-62443. We have done so in a manner that is simpler, and, dramatically more secure. We now have perfect fine-grained audit per user per transaction. We have eliminated the undesirable east-west flows that could cause lateral traversal. We have removed the challenges associated with shared accounts in third-party vendors.

User efficiency is increased: no VPN per customer to install, no breakage of local applications. No separate password to remember.

The security principles of ISA/IEC 62443 are implemented:

1. Least Privilege. A user can only do what they need
2. Defense in Depth. Lateral traversal is prevented. A normalising web-application firewall and proxy prevents direct IP connectivity. Strong, modern encryption is uniform.
3. Risk Analysis. A perfect audit trail is present, per user, per transaction.
4. Compensating Security Measure. Individual paths, transactions can be allowed/denied, individual users are used rather than shared, built-in accounts.

By leveraging user identity, coupled with role-based, resourced-based authorisation, we have implemented the Zones and Conduits conceptual model of ISA/IEC-62443. We have done so in a manner that is simpler, and, dramatically more secure. We now have perfect fine-grained audit per user per transaction. We have eliminated the undesirable east-west flows that could cause lateral traversal. We have removed the challenges associated with shared accounts in third-party vendors.