Agilicus and Operational Technology

The Agilicus Zero Trust principle is that all user<->resource communications are individually authenticated (identity), authorized (firewall) and audited. 

It is the ultimate micro-segmentation.

In a typical environment, individual users (a person or a machine) can have multiple sources of identity attestation. This occurs when we have partners, contractors, and joint ventures.

Business risk management dictates that a given ‘blast radius’ be knowable and contained: an outage due to a cyber-security event should be constrained to the smallest area possible – it should not be global, it should not be an entire building.

The historical focus on Cyber Security in IIoT Digitisation has been around North-South threats (internet in) and has focused around ‘perimeter’ security (Firewall + VPN). This, coupled with the long-life-cycle nature of Industrial devices, where patch management is not as evolved as in the IT domain, gives rise to increased risk of one device being used to obtain access to another (lateral traversal).

Existing management systems and practices may rely on ‘flat addressability’, perhaps even globally across multiple facilities. Outsourced service complicates this problem:

• I partner with Vendor A, but which of their staff made Change B? Is there a shared password involved and someone has left?

Strategies around segmentation struggle to become fine-grained enough to matter: is it by equipment type? By assembly-line? By facility? By risk? In the end, we end up with a set of VPN + Firewall ACL’s which are not expressible. And, a VPN does not give us a fine-grained Audit record (we can merely see who had IP connectivity, not to what device they performed which action). Additionally, the segmentation does not usually handle egress firewalling. A proper egress firewall is a great defense in depth against Ransomware: if it can’t call home, it can’t activate. But cloud-hosted statistics, with large and varying IP ranges can make this egress firewall complex to configure.

Business desires might be expressed as:

• Resources (devices) cannot reach each other (no east-west allowed).
• A vendor may have individuals working for them with access granted to specific groups of resources for specific times
• e.g. Monday from 9 pm to 12 am EST Vendor A can upgrade the firmware in Resources in Factory 1, Bay 2, of type Z.
• Resources can reach out to push statistics.
• A vendor may monitor their own devices at any time (without write access).
• A management system can read/write specific subtrees of information.
• Company IT Management can access any device from anywhere.
• 100% of actions have an audit trail (who did what when from where to what).
• Devices cannot create outbound connections except to their own management systems.
• Multi-factor must be used for all users, regardless of Identity Source.

Agilicus Proposal Overview

1. Use existing Identity Provider for 100% of users (Azure, Google, Okta, …) → no new usernames or passwords, no shared accounts. Single Sign On with a second factor.
2. Make all connections be outbound. Agilicus Agent is the sole outbound connection. No public IP is required – Cellular or Satellite networks, NAT may be used.
3. Create arbitrary Resource Groups matching various Authorization groups.
   • Resources can be in multiple orthogonal groups (e.g. “PLC-Type-A”, “Robot Arms”, “Factory-1-Line-1”).
4. Create User Groups matching Roles (e.g. Vendor A, Admin, Monitoring-Co) and asign users appropriately. Groups may also be nested.
5. For web-based (e.g. Web Application or REST applications), use OpenID Connect authentication. No client software is needed.
6. For HMI-type systems, use Remote Desktop via Agilicus Gateway, enabling single-sign-on + authentication + authorization + audit.
7. For SSH-type systems, use Agilicus Gateway, enabling single-sign-on + authentication + authorization + audit.
8. For REST-style API, use Agilicus Identity-Aware Web Application Firewall to enable fine-grained authorisation.
   • (e.g. GET /* -> reader, PUT/POST/DELETE /config/* -> configuration-users, PUT/POST/DELETE /action/* -> restricted)
9. Enable Private VLAN (or AP Isolation) on L2 segments to prevent east-west connectivity systematically.
10. Run Agilicus Agent on machine on ‘trusted uplink’ of Private VLAN (optionally with local Edge Compute).

Agilicus Zero-Trust Philosophy

Agilicus adopts existing identity. Users sign-in with their natural identity provider (Corporate Azure or Google Workplace, personal Apple/Google account). This provides the ‘Who’.

The company owns the Authorisation. This provides the ‘What’.

Agilicus provides Access (the How).

Every single TCP flow individually runs through these 3 stages of the pipeline: 

1. Who are you? 
2. Are you allowed to do what you propose? 
3. Ok, allow it and create an Audit record.

Individual protocols have different depths of capabilities. The deepest are for HTTP (Web Applications, Mobile Applications, REST APIs) followed by Remote Desktop and SSH, followed by generic TCP connectivity and existing Fat clients.

The Authorisation rules in the firewall are exceptionally deep, allowing the ability to express things by regular expression, path, body, etc. 

• E.g. “Accounting admins can see any payroll record, End Users can see only payroll records where their user-id matches the one in the JSON record.”

Appendix: Use Cases

Vendor Monitoring

We have 3 machine types that are monitored by the manufacturer for impending failure or maintenance. In order to achieve this, the Vendor is able to, at all times, receive streamed measurements. In addition, the Vendor can interrogate the Monitoring tree on each of the controllers, on each of these machines.

The Vendor has a ‘service account’ which is used for the streamed measurements. For the Monitoring tree, these are individual staff members. The vendor manages their own team: we authorize the vendor, they authorize the people.

We wish to have a full audit log of which individual user performed which action on which machine.

To achieve the objective:

• Create a Resource for each machine instance
• Create a Resource Group, place all instances in the Group
• Create TCP Forwarder, destination == streamed measurement receiver (e.g. MQTT)
• Configure devices to use Agilicus Agent as ‘destination’
• Create Users for each person (or use Auto-Create for Identity Upstream)
• Create Group, place all users in Group
• Create Firewall Rules for ‘Monitoring’ (if possible, protocol dependent, for discussion)
• Give Group role ‘Monitoring’
• Observe audit trail for actions (either streamed, via REST api, via CLI, or via Admin web interface)

Vendor Upgrade

We have 10 of the same machine type in each plant. We have agreed on a 12-hour maintenance window on machine-1 in plant-1. We wish to ensure the Vendor is only talking to this device, and not any others.

• Create firewall rules for ‘configuration’ allowing all
• Apply permission ‘configuration’ to the Vendor, but only on the given Resource
• Remove permission when done (TBD: discussion on Access Token timeout time and per resource for auto-timeout)
• Observe Audit

Admin Staff

• Create ‘Administrators’ Group
• Put users in Group
• Create ‘All’ Resources group
• Create a Firewall rule on each Resource as ‘Admin’
• Assign ‘Administrators’ Group ‘Admin’ Role on ‘All Resources’

For components which are HTTP, use browser as-is, OpenID Connect (via Proxy in Agilicus).

For components which are REST API, create API key or service account (or integrate API).

For components which are SSH, use SSH ProxyCommand for direct access (use can ‘ssh me@device’ and it will globally find it and connect: No VPN, no inbound firewall rules. Uses Agilicus Agent locally (not as a service).

For components which are Remote Desktop (e.g. HMI) use Agilicus Profile to create RDP file for direct access.

For components which are direct TCP, use Forwarders.

For fat-client management software, use a Launcher.