How to Comply with the Australian Cyber Security Centre Industrial Control System Remote Access Protocol
If you're here, you're probably a operational technology manager or IT security reader based in Australia looking to enable remote access to your environment while complying with the Australian Cyber Security Centre's (ACSC) cybersecurity protocols. It might be you're doing so for the very first time or looking to bring your organization into alignment with the the ACSC's guidance. Either way, what we'll do here is walk you through what the requirements are in the guidelines, and then how you can use Dispel to easily and automatically comply.
Dispel is a managed zero trust access (ZTA) platform designed specifically for OT/ICS environments. It combines multiple security modules around a secure access service edge (SASE) model to meet the cybersecurity control criteria. If you use Dispel, you'll automatically comply with most of the guidelines—a lot cheaper and certainly faster than having to buy several different products and put it together yourself.
What is the Australian Cyber Security Centre Industrial Control Systems Remote Access Protocol?
The Australian Cyber Security Centre's Industrial Control Systems Remote Access Protocol provides guidance for how critical infrastructure should enable remote access to their Operational Technology Environments (OTE).
Why is the ACSC putting this out?
Industrial automation and control system (IACS) organizations increasingly use commercial off-the-shelf (COTS) networked devices that are inexpensive, efficient, and highly automated. Control systems are also increasingly interconnected with non-IACS networks for valid business reasons. These devices, open networking technologies, and increased connectivity elevate the theoretical cyber risk of control system hardware and software. This, in turn, has raised concerns over Health, Safety and Environmental (HSE), financial, and/or reputational consequences from cyberattacks on deployed control systems.
The ACSC ICS Remote Access Protocol is not a prescriptive guide. The goal of the document is to provide a flexible framework that facilitates addressing current and future vulnerabilities in IACSs and applying necessary mitigations in a systematic, defensible manner.
How Dispel's ZTA architecture works in this model
Next we'll go through a brief architecture overview of Dispel Remote Access, then details how Dispel’s zero trust remote access solution meets and exceeds each design guideline put forth by the ACSC ICS Remote Access Protocol.
Purdue Model Diagram of Dispel Deployment
Dispel Wicket ESI
Bottom third of diagram, Layer 3.5 of Purdue Model (OT DMZ)
The Dispel Wicket ESI is an on-premises remote access gateway that can be deployed as either hardware or a virtual appliance. It contains two network interface cards: North, and South. North connects outbound-only through a single port to a single IP to establish a remote access pathway through the SD-WAN, and South is given routability to devices on the OT network. On-premise firewalls can control the North and South sides independently to maintain strict need-based access and network segmentation. The Wicket ESI is the only on-premise installation required, and enables secure remote access to any device permitted on the South side network.
Grey box on upper left, cloud-based core network
The Dispel SD-WAN is the main bridge enabling remote access. The Wicket ESI proactively connects from one side of the SD-WAN, and on the other side, the Virtual Desktops are automatically networked in. Each Dispel SD-WAN is single-tenant to each customer, meaning your traffic and another customer’s traffic will never traverse the same infrastructure. Additionally, Dispel SD-WANs are built with Moving Target Defense technology, enabling a shifting topology and increased resiliency.
Dispel VDIs (Virtual Desktops)
Top of diagram, cloud-based workstations
Dispel Virtual Desktops (VDIs) are single-use, time-limited workstations that users connect through to access the ICS network. Virtual desktops can be set to automatically cycle on an administrator-defined schedule. This ensures that each desktop is never used for more than 12 hours, and all valid credentials for remote access are cycled every 24 hours. Virtual desktops that connect to your ICS network will never connect to another network or another country. Lastly, virtual desktops will automatically build with the latest updates and patches to the day, and can be customized and imaged with your desired applications and security policies.
Dispel Logging and Recording
Blue boxes on the upper right, cloud-based add-ons
All access performed through Dispel is recorded in two ways:
Syslog traffic packets which contain the user, timestamp, what devices the user accessed, and through which protocol. Dispel can provide an integrated server to store these logs as part of the managed deployment, or the traffic can be forwarded to a customer’s existing SIEM (eg. Splunk).
Full video screen recordings of each Virtual Desktop session. Recordings can be watched in real-time, and are saved for playback. Videos can be retained for an administrator-defined period of time, stored permanently, or exported. Dispel can provide a recording storage server to enable this functionality with no additional hardware needed from the customer.
Point-by-Point Guideline Mapping
Design 1: By default, there should be no communication between the vendor and the critical infrastructure control system.
By default, there is no communication possibility between the vendor and critical infrastructure. Access credentials are refreshed from session to session, ensuring the prevention of lingering or unwanted communication is. This is enforced at multiple levels:
No direct access. All connections must go through a hardened virtual desktop acting as an intermediary.
Vendors start from a suspended-by-default state, and must complete a “Request Access Form” for their account to gain access to a single-tenant, locked-to-them virtual desktop. Access is granted only for the time window allowed by the administrator.
The remote access network may be destroyed when not in use.
Design 2: Networks should be segmented and segregated.
Dispel’s on-premises remote access gateway, which we call a “Wicket ESI” has two segmented network interfaces.
The North interface establishes an encrypted, outbound-only connection to the single-tenant Moving Target Defense (MTD) network, which we call a Dispel Enclave. This connection re-quires a single outbound-only firewall rule to a single IP address, through a single port.
The South interface provides gateway access to the OT environment.
The Wicket is deployed in the OT-DMZ between the internet facing firewall (for the North network interface) and the separate OT firewall (South network interface). No inbound firewall rules are needed from the Internet, and no devices on the control system need direct Internet access.
Design 3: Must be able to disconnect, revert, respond, and apply safety plans.
Dispel provides this functionality in a number of ways.
Dispel helps detect incidents through session recording and traffic logging/monitoring. These help a customer gain visibility into their environments.
- Administrators may instantly delete Virtual Desktops suspected of malicious behavior. This allows the rest of the network to function normally while severing an isolated virtual desktop and disconnecting an unwanted user from the control system instantly.
Administrators may destroy the MTD remote access network on-demand if necessary. This would remove any potential for external connectivity and return the OT environment to a fully offline state.
Administrators may destroy the Wicket Virtual Machine (if virtual appliance) or unplug the Wicket’s ethernet cables (if hardware appliance) as a secondary method of ensuring no possibility of external connectivity.
Design 4: Multi-factor authentication should be used.
Multi-factor authentication is enforceable at an organization level for all users on the Dispel platform. We support temporary one-time passwords (ToTP) or hardware tokens such as YubiKeys. We also have a number of SSO integrations with Active Directory, Microsoft, OAuth2.0 providers like Okta, and SAML.
Design 5: Login credentials must be unique to specific people.
All Dispel logins are created on a per-user basis, whether through our login process or SSO. Further Multi-factor Authentication is used to further associate a user to their account. Vendors must also fill out an access request form wherein they provide their identity, reason/scope for access, and the time window they need to complete the task. This request must be approved by an authorized party and the request + approver are documented for auditing purposes.
Design 6: Time limit the connection (e.g. to 24 hours or the length of a shift) and ensure the credentials are one-time-use credentials.
All virtual desktops are built with one-time-use credentials and Administrator-defined time intervals.
We recommend 12-hour shifts, and that any unused Virtual Desktops are automatically cycled every 24 hours. Thus, all active connections are limited to 12-hour sessions, and all unused desktop credentials expire after 24 hours automatically.
Design 7: If the connection is inactive for more than 30 minutes, the connection should be removed.
Virtual Desktops automatically time out after 15 minutes of inactivity. This time limit is admin configurable. Configuration customizations like this are documented and delivered to the customer.
Design 8: Ensure there is a procedure to acquire approval for connection of remote access by a senior officer of the organisation.
Dispel can be configured to require access requests for every session through a built-in Request Access Form.
The Request Access form automatically sends incoming requests to a defined list of senior officers / administrators. By default, only administrators of the remote access network and the relevant facility in question can approve Request Access Forms. In addition, an administrator may not approve their own request.
For specific jurisdictions, administrators may delegate approval responsibilities to others. That list of approvers is only editable by those with administrator permissions, and is documented within the console.
Design 9: Ensure the device used at the remote (vendor) end is used solely for the purpose of connecting to the Australian critical infrastructure organisation.
By using virtual desktops as disposable intermediate hosts, customers can ensure that:
The virtual desktop used to complete the work was built for the explicit purpose of connecting to only the one Australian critical infrastructure needed to complete that scope of work.
The same virtual desktop will never be used across multiple countries or organizations. Each virtual desktop is allowed to connect to only one ICS environment, ever.
Vendors are never directly connecting to the ICS environment. All desktops that connect to the ICS environment will only connect to this specific ICS environment in its lifetime.
Design 10: Apply ASD’s ‘Top Four’ to the highest maturity level, with the rest of the ‘Essential Eight’ where applicable on the computer at the remote end.
By using customer-controlled virtual desktops, they can ensure that:
- [Mitigation 1] Only allowed applications are on the virtual desktop image. No additional application downloads are permitted.
- [Mitigation 2] Applications on the virtual desktops are patched to their latest versions.
- [Mitigation 3] Virtual desktops and remote access infrastructure is automatically patched at build and during its lifetime.
- [Mitigation 4] Privileges are scoped only to the specific devices they need access to and administrative privileges are not available on the virtual desktops.
These mitigations comprise the ASD’s “Top Four”. In addition, Dispel helps customers with multi-factor authentication, controlled use of application and endpoint hardening, and regular backups/disaster recovery to round out the Essential Eight.
Design 11: Apply ASD’s ‘Essential Eight’ where applicable on all interim machines internal to the critical infrastructure organisation’s network that are not prevented from such measures for OT reasons.
Dispel’s remote access platform is fundamentally different in that the customer, not the end vendor, will control the virtual desktops. Therefore all applicable measures desired in the ASD’s ‘Essential Eight’ can be applied by default.
Design 12: ‘Bastion hosts’ (special-purpose computers on a network specifically designed and configured to withstand attacks) and interim machines should be turned off whenever possible.
Dispel employs disposable virtual infrastructure, which can be turned off when not in use to prevent attackers from acquiring a foothold. Further, these virtual desktops are cycled regularly and change on a daily basis, allowing connections for authorized users while preventing enemies from gaining footholds into the OT environment.
Dispel’s principle service is the orchestration and management of these virtual machines, so we will deliver a fully functional plan to customers during the deployment.
Design 13: To aid in mitigating the risk of supply chain attacks, critical infrastructure operators and vendors should put in place robust mechanisms to verify all software and tools used in the remote vendor access protocol process.
As the owner of the virtual desktop image, the customer may review all software and tools used in the remote access process.
Further, Dispel helps provide visibility by enacting port and protocol traffic monitoring, as well as full recording of virtual desktop sessions.
Design 14: Ensure contractually that any data viewed or acquired as part of the remote access is used only for the purpose of resolving the issue the remote access was granted for.
As all work is completed within the virtual desktop environment, so all associated data never needs to leave the controlled scope of the customer.
That said, we advise customers to include relevant language in their contracts.
Design 15: Ensure contractually that there is an ability to audit the organisation at the remote end to ensure each of the conditions is met.
Virtual desktops are programmatically scoped to only the organization, and are built from customized golden images to comply with Essential Eight rules. End-to-End encryption is provided using AES-256 with 4096 bit RSA.
Although Dispel mitigates these risks, we advise customers to include relevant language in their contracts to fulfill this design principle.
Design 16: Ensure contractually that there is ability to periodically red-team test the protocol at all parts of the protocol, including the remote vendor’s end.
Dispel undergoes periodic penetration testing from HackerOne, and customers are allowed to perform their own penetration testing under the appropriate instances.
Design 17: Ensure contractually that any connectivity and hosting requirements for the re-mote access infrastructure is specified.
Dispel has a number of procedures and policies in place to mitigate denial of services attacks.
The remote access network itself has all ports and protocols turned off, except for those explicitly allowed for individual components to work together.
Virtual Desktops allow RDP connections from only the approved user, and only after they’ve been granted an access window.
Dispel employs regional resiliency measures to quickly recover from data-center/cloud-level outage events.
The front-end console mitigates DDoS attacks with techniques including TCP Syn cookies and connection rate limit-ing. The console also maintains a multiple backbone connection architecture with internal bandwidth capacity that exceeds the internet carrier supplied bandwidth. In the event of a DDoS at-tack, our console hosting platform enables additional advanced DDoS mitigation controls where needed.
“If you are looking for a robust product for accessing OT assets securely and reliably, this is it.”
Book a demo with our team today to get yourself aligned with the ACSC's Industrial Control System Remote Access Protocol: