Secure Remote Access to Insecure Systems
Saturday, August 24, 2019 at 06:35AM
Toby Considine in Cybersecurity, Intelligent Buildings, Security
p>I have written for years here that control systems are not designed for security, and that one needs to create a security architecture as part of connecting building systems to networks. Recently, I had to design a security architecture to allow remote access to several systems with no security built in. An example of such an architecture is below.

During renovations in a bioresearch facility, eleven cold rooms were installed or upgraded, each with its own HMI. An HMI, or Human Machine Interface, sound serious, but it means that each cold room had a touch screen that could be used configure and monitor its status.

The equipment that keeps each cold room cold was down the hall, isolated in a mechanical room on each floor. The maintenance staff had no way to interact with the HMI when working on the equipment. There was no way to lock out the system for safe maintenance. They asked for remote access to the HMI so they could do their jobs safely.

The subcontractor who had installed it had a solution that was quick, simple, effective, and horribly wrong.  It was wrong in that it compromised all networking in the building. And it was wrong because it had no security. In other words, it was like most networking solutions for controls systems.

The contractor’s proposal was to attach each HMI to a wireless router. The router recommended was sold as an access point for control systems, that is less configurable, less functional, and more expensive then you would put in your home.  Each cold room HMI would have its own wireless network, each network would be named with the room number of the cold room, and each would have no security. The contractor would add the remote access software VNC to each HMI to let maintenance staff see and interact with the HMI from any computer or tablet on the wireless network.

The first problem was it likely would not work. Wireless networks coexist by switching to different channels to avoid collisions. Channels that are too close to each other interfere with each other and lose data, which practically limits in-building networks to contesting for three channels. The building already and an engineered wireless mesh in place. In this case, engineered mesh means experienced people had already designed and tested the network so it would work. Without exploring all the details of a complex subject, suffice it that the proposed new networks would not only conflict with each other, but also would also degrade all the wireless networking supporting the occupants of the building.

The other problem was that even if the networking worked, and did not cause loss of other building services, the plan had no security. There was no way proposed to control who could connect to and control each HMI. There was no means for monitoring access or detecting malicious activity, or even the casual interactions of the curious. This is unacceptable for a building with many tenants and with public access.

Fortunately, there was already a robust building network in place, as well as a working and tested bastion access system established.

The word Bastion is an old one referring to an essential part of fortification design. A bastion is traditionally a projecting portion of a rampart or fortification that extends beyond the main fortification while attached at the base to the main work. A key attribute is that if a bastion is breached, the main fortifications are still not breached.

A bastion server is locked down server logically external to the core server infrastructure, well defended on its own, that projects into the wider network. In effect, bastion servers are stepping-stones that are allowed to access less secured systems en-route to contacting defined systems.

A good security policy does not allow unknown or un-managed systems to connect to internal systems. Similarly, if a system cannot be properly secured, only a trusted system may connect to it. A bastion architecture addresses these issues by defining well-protected systems in the middle that are used as stepping stones to protected internal systems.

The user of the Bastion Server has no rights to install or configure software on the bastion server. This is to prevent the user from taking control of the bastion server or eavesdropping on other users of the bastion server. A Bastion architecture does not solve all security issues, but bastions are part of a larger security architecture.

To provide secure access to the Cold Room controls, each HMI was connected to the wired corporate network. A secure virtual LAN (VLAN) was created holding only these 11 systems. No traffic in or out of the VLAN except for VNC communications from a defined set of bastion servers. Bastion users could only select defined links for each Cold Room and could not use VNC to try to connect to undefined points.

Access to these links on the Bastion Servers was restricted to solely the members of the refrigeration maintenance group; no one else was permitted remote access through the bastions. Members of that group could use any network, including the normal customer wireless in the building or even smart phones connecting from the cellular network to connect to the bastions. The bastions were configured to allow only a single user at a time to access each HMI.

Because all access was using corporate accounts, there are no shared passwords on the control systems that will not meet corporate standards. Existing processes to handle hiring and firing or personnel already deal with granting or removing rights to each user, so zombie accounts will not persist to give people unintended rights in the future.  

Article originally appeared on New Daedalus (http://www.newdaedalus.com/).
See website for complete article licensing information.