CNI system design: Secure Remote Access

This article will delve into NCSC’s recommendations, helping you to create and enhance a remote access framework tailored to operational technology setups. While the discussion presumes the networks are being designed from the ground up, I recognize this might not always be practical.

If you are tasked with integrating robust remote access into an existing system, use the essential principles outlined herein to identify and prioritize manageable projects that incrementally enhance security.

The initial step in any design initiative is to compile the system’s requirements. Here are some typical user stories:

• As a regular user, I need access to internal services.
• As a regular user, I need to access internet resources (such as websites and email).
• As a regular user, I need to access services from both corporate locations and my home.
• As an engineering user, I require remote access to operational technology networks, sensors, and actuators.
• As an administrator, I need to remotely configure actuator positions for updates, installations, and maintenance.
• As an operator, I must enable vendors and suppliers to extract efficiency and management data.

Security Necessities

In conjunction with the user stories, we must also integrate security requirements:

• Make compromise challenging (from the design principles).
• Make disruption difficult (from the design principles).
• Enhance detection of compromises (from the design principles).
• Minimize impact of compromises (from the design principles).
• Ensure the integrity of control system data.
• Guarantee confidentiality of control system data where applicable.
• Safeguard confidentiality of sensitive data (e.g., personal details or intellectual property) as necessary.
• Minimize the risk to operational activities from internet exposure.

These criteria collectively outline the essence of remote access and clarify related security needs. Next, we will examine the architecture that underpins such a system.

When constructing a remote access framework, begin by evaluating how the foundational architecture can fulfill the specified functional and security requirements.

Often, remote access needs are only addressed late in the design phase, leading to unnecessary redesigns.

Incorporating a remote access solution early in your overall design can address security and functionality needs without incurring additional cost or delay.

A remote access session should originate from a company-managed device held by an authorized employee, establishing a high level of trust. This device may be a phone, tablet, laptop, or desktop computer.

Regardless of device choice, security design principles remain consistent. The NCSC’s Mobile Device Guidance outlines essential security practices for various operating systems.

Devices employed for remote access are prime targets for attackers, as they provide entry points and credentials for accessing sensitive components and services.

Due to the risk of compromises through spear phishing and other targeted methods, it is vital to separate corporate functions, such as email, from engineering functions, like remote access.

This separation helps prevent the compromise of a single system component from impacting critical, sensitive components, whether through attack or misconfiguration.

If the consequences of a compromise would be significantly damaging, implementing a dedicated Privileged Access Workstation (PAW) is advisable. This allows for additional controls and measures, minimizing the attack vector.

The significance of achieving trust in management devices and the value of PAWs are comprehensively discussed in the Secure System Administration Guidance.

The structure supporting remote access is critical as it balances enabling access for legitimate users while safeguarding against unauthorized entry.

The infrastructure should facilitate the logical separation of distinct networks based on their functions. For instance, it’s generally unnecessary for your control network to have access to email or other internal services.

Incorporating Privileged Access Management (PAM) is advisable. For related information, refer to the NCSC blog ‘Protecting System Administration with PAM‘. Specifically, avoid the ‘Browse-Up’ construct, detailed in the NCSC’s Security Architecture Anti-Patterns Whitepaper.

New operational technology devices often boast features and capabilities similar to traditional IT systems. Hence, modern cipher suites and protocols are generally compatible with minimal configuration, as highlighted in the NCSC’s TLS Configuration or IPSec Configuration guidelines.

However, legacy devices may not meet these standards. The NCSC provides guidance regarding obsolete platforms.

Moreover, a crucial aspect often overlooked is the protection of management interfaces for configuring remote sensors and actuators. This consideration encompasses various protocols and technologies. For further exploration, consider reading the NCSC blog on Protection of Management Interfaces.

Taking into account the aforementioned architectural principles, let’s outline an example system. The following diagram showcases the key components of a generic use-case.

This diagram illustrates two data flows: one for engineering access, marked in orange, and another for access to internal corporate resources and the internet, marked in blue.

Devices for Remote Access

We have opted to provide personnel needing remote access with two devices, represented by the orange and blue laptops in the diagram. Daily corporate tasks can be completed using the blue laptop.

The orange device lacks internet access and corporate service capabilities, such as email, aimed at mitigating risks stemming from phishing attempts or watering hole attacks that could enable an attacker to infiltrate remote sensors and actuators.

Furthermore, the dedicated device should be securely locked down and hardened according to the principle of least privilege, ensuring that any unnecessary software is eliminated to avoid introducing legacy vulnerabilities.

While providing two separate devices may appear excessive or cumbersome, particularly if considering a hypervisor on a single machine to cater to each function, a second device establishes a robust defensive line against potential threats to control systems and networks.

Using two laptops may be less convenient, yet it offers the most reliable separation. If this option is unavailable, other alternatives should be explored.

Regardless of your choice, it is essential that standard methods of compromise used in enterprise IT do not easily extend to infiltrate OT systems. For instance, access to enterprise applications like email and web browsing could be allowed on a separate machine, or the two functions could be isolated on one hardware using virtual machines. In such cases, the more susceptible enterprise machine should be a guest, not the host.

The critical factor is the potential impact of any compromise within the control system.

Further guidance can be found in the NCSC’s network architectures for remote access, which also explores these architectural points from a Zero-Trust standpoint.

Direct access from a remote office or home to field sites is prohibited. Access can only be granted via a dedicated corporate network with appropriate protections in place, as demonstrated by the distinct flows from the management device to the field site through corporate networks.

The ‘corporate’ device, indicated by the blue laptop, utilized for accessing email and the internet functions on a separate corporate network.

Network boundary devices (denoted by orange hatched boxes) are responsible for managing data flows in and out of various physical locations.

Legacy Considerations

Each sensor and actuator within field sites is accessed through various methods and exhibits different levels of compatibility with current cryptographic controls that ensure integrity and confidentiality of communication.

If a sensor or actuator lacks robust integrity or confidentiality, employing a Virtual Private Network (VPN) can bridge that gap.

Browse-Down Principles

This design has eliminated access to remote sensor networks through standard corporate devices.

It should be presumed that devices exposed to the internet carry a lower trust level than target devices and networks. Enabling these low-trust devices to connect with operational devices follows a ‘browse-up’ approach, which we are actively avoiding in favor of a ‘browse-down’ strategy.

Avoiding Jump Boxes

Utilizing jump boxes or bastion hosts has also been dismissed due to their tendency to complicate processes without significantly enhancing the security posture of remote access. It is prudent to expect that malicious software can traverse through intermediary hosts similarly to legitimate users.

Having established how to connect to remote sensors or actuators, it is crucial to define the intended use of these connections.

The NCSC has recently introduced its Secure System Administration guidelines, which comprise a comprehensive set of recommendations on administering services and systems with security in mind. This guidance clarifies how these concepts apply specifically to CNI organizations.

We have investigated architectural concerns and how to conduct administration effectively; however, additional factors must be accounted for to guarantee systemic hygiene.

The NCSC provides extensive resources to support basic cybersecurity practices, including secure design principles and risk management guidance. While we will not reiterate them here, several key considerations will be addressed when securing remote access to operational technology networks.

Implementing Multifactor Authentication

The benefits of utilizing a second factor when accessing services are emphasized in the NCSC’s guidance on two-factor authentication (2FA). Although applicable to personal use and online services, the advantages extend to critical national services and operational networks.

The introduction of a second authentication factor can be depicted in the attached diagram, where the user is fulfilled with a second mechanism—a token, which can either be physical or generated through a time-based one-time passcode (TOTP).

Credentials granting remote access to operational technology systems are highly coveted by attackers. Incorporating multifactor authentication into your solution greatly complicates an attacker’s efforts to gain remote access should a password for an account be compromised. For further details, see the NCSC’s resources on password use and password managers.

At times, it may be necessary to grant hardware vendors access to sensor networks. While this access is essential, it should not equate to unrestricted access at all times.

You could implement an access request process—such as enabling or disabling accounts as needed, or requiring the vendor to obtain a time-based, one-time passcode (TOTP) for access.

Guest access and associated activities should be logged and scrutinized as appropriate.

Understanding how third parties access your environment, specifically whether they utilize a shared host for multiple customers, is critical. Confidence in the security maturity of your suppliers is as important as your own measures.

Understanding the assets within an IT estate is crucial for identifying potential vulnerabilities.

As hardware and software reach the end of their support lifecycle, maintaining an updated inventory of physical and digital assets allows for efficient planning regarding replacement initiatives and rapid response if critical vulnerabilities arise. Reducing response time following a vulnerability disclosure minimizes opportunities for attackers to exploit weak points.

For example, an internet-facing firewall is integral to any network security strategy. Awareness of both short- and long-term roadmaps for the products you utilize is vital for ensuring ongoing network security. Short-term roadmaps offer insight into anticipated update schedules, while long-term roadmaps clarify vendor support strategies and obsolescence management.

The principles of vulnerability management apply equally to technologies related to provided services or devices, such as leased VPN equipment or firewalls. Recently, the NCSC issued a warning about vulnerabilities in VPNs affecting systems globally.

Configuration files are often neglected as digital assets. Implementing version control for configurations can assist in tracking changes, establishing a reliable baseline, and helping to avert unauthorized alterations.

The NCSC’s Secure Development and Deployment guidance highlights the advantages of managing software assets.

Operational technology devices and networks may be managed by distinct teams compared to traditional network devices, leading to a division often referred to as OT vs IT. This may result in friction stemming from differing priorities.

For instance, security policies may prevent insecure services like Telnet from being enabled by default on desktop IT products, but these policies may not extend to OT, resulting in some components being left with such services enabled during initial configuration but never disabled. Additionally, logging and monitoring may only cover IT events, leaving OT activities unchecked.

It’s clear that IT and OT domains possess distinct characteristics, risks, threats, vulnerabilities, and countermeasures.

Nevertheless, it is vital for operators to ensure that both IT and OT systems receive equal consideration within their risk management framework. Neglecting one domain could lead to inconsistencies and weaknesses in cybersecurity policies and risk management across an organization’s IT and OT environments.

This does not necessarily imply altering team dynamics, roles, or responsibilities but rather harmonizing the language and processes used for risk management across the entire organization. This approach fosters effective cybersecurity risk management and cohesive decision-making.

Successful operators minimize friction between OT and IT teams, applying a unified risk management approach across both environments.

This blog post has sought to demonstrate that the NCSC’s recommendations on remote access apply to the critical national infrastructure sector.

The remote access architectural model presented here is one of various methods that can be employed. Other solutions, such as cloud-based orchestration services, were not covered; however, the foundational principles and documentation noted here alongside the cloud security principles can assist with your critical appraisal of these services.