Industrial Air Gap – A Tale Of 2 Users

Devices on industrial control system networks are ill-equipped for the hardships associated with the Internet and remote access. Low-speed processors, infrequent firmware upgrades, spotty security research, Common Vulnerabilities and Exposures (CVE) publishing, etc.

Traditional wisdom says that industrial control networks should be entirely air-gapped: be attached via a short wire to use/modify the device. However, this gives a long mean-time-to-repair cycle, leading to customer complaints. Additionally, the travel time associated with staff visiting particular sites does not yield the best return on investment: other billable hours of higher value exist.

Teams requiring access to industrial devices are often external vendors under contract rather than staff of the operator. This leads to a natural conflict: the operator is responsible for the security, and they are not willing to sacrifice security for accessibility since their business and reputation is at stake. The vendor wants the opposite – to have the least constraints and the most simplicity across their customer base.

Imperfect and insecure compromises are often implemented without considering, or without full knowledge of, the risk involved. These might include remote PC access technologies like TeamViewer, LogMeIn, or other various VPN technologies.

Remote PC access technologies are risky. They usually involve a shared password, rarely changed, and direct access to a PC that may not be entirely up to date or secure – itself acting as a launch-pad for malware.

The VPN technologies are both complex as well as risky. Complex since they require shared routing tables in both directions: the industrial devices require a route back, the incoming PC requires a forward route. Complex since each operator a vendor supports uses a different VPN or version. Risky since VPN’s imply full layer-3 reachability of the entire industrial network. Risky since there is no per-user attribution and audit of actions, no fine-grained access control nor audit.

Is there a better way? One that meets the security requirements of the operator’s IT department as well as the access requirements of the vendors?

Yes: a Zero-Trust Network Architecture.

Virtual Air Gap: Zero-Trust Industrial Network Architecture

The central tenets of Zero-Trust:

1. Identity.
   • Each actor is individually known, authenticated.
2. Authorisation.
   • Each transaction is individually authorised based on who (identity) is trying what action on what Resource
3. Access.
   • The transaction is routed to the destination, and only the destination resource.

In the diagram below, we contrast the VPN world (red) with the Zero Trust world (blue).

VPN Case

On the VPN side, the user (e.g. vendor accessing) must: 

1. Install multiple VPN software vendors and versions (one for each customer/site). 

Must have some shared-passwords written down (passwords.xlsx!) for each customer. Once the VPN is connected, they must manually add routes to the ultimate destination, or accept an ‘all route’ that moves all traffic through. In the former case, collisions can occur, this is error prone and tedious. In the latter case, we break video conferencing and other productivity tools. The VPN user has complete access to all devices, running the risk of a maintenance operation affecting the wrong system. It can be difficult to know which underlying user did which action: auditing is very fuzzy. Worse, the reliability issues. When you need it most, this VPN can fail you. Overall, VPNs are difficult for everyone. VPN protocols are commonly blocked in hotel or airport networks typically not NAT-friendly, meaning a single concurrent user might be possible, but not 2, within a given network.

Agilicus AnyX: Zero Trust Case

Contrast the Zero Trust approach. A dual-homed device straddles, but does not route, across the two networks. This device can be an industrial PC, a private-VLAN-enabled switch, etc. There are economical 5-port ARM-based SBC that exist and are DIN-mountable which can fulfil this role and as a result, would run both the Agilicus Agent Connector as well as provide connectivity in one compact unit. 

In the zero-trust model, outbound-only connections are made, using only HTTPS and traversing all firewalls. Being outbound-only, no firewall configuration changes are needed, and if one were to do a penetration test on the network – no open ports would show. 

User authentication is done via existing Single-Sign-On: each person uses their own employer’s identity system (Azure Active Directory, Google G Suite, Okta, etc) and you can enforce a second factor. Each action through the Agilicus AnyX platform is always attributed to a single individual. No lateral traversal is possible – connections are to individual resources, not the entire network.

Conclusion

In this new model we have achieved several objectives:

1. End-user (vendor) efficiency
   • No software to install or maintain
   • No searching for passwords and credentials
   • Connect to multiple sites as once
   • Firewall changes do not impact access
   • Works on any mobile device (tablet, PC, phone, etc.)
   • Works on any network: hotel, wifi, cellular
   • Works the same for all customers

2. Operator security
   • Multi-factor authentication can be enforced, even on 3rd parties
   • Multi-factor prevents credential sharing
   • Per-user, per-resource, per-action audit available
   • No lateral traversal across industrial network
   • Creates an air-gap to your most secure networks
   • No outbound access possible from industrial network
   • No inbound holes in firewall
   • Simplified user management owing to single identity

We have solved the dichotomy between the operator and the vendor: security with simplicity.