September 2019 |
[an error occurred while processing this directive] |
Gaining
a Backbone, Bolting on Security This month, I describe how I put systems that are insecure-by-design on the corporate backbone and then enabling remote access. |
|
Articles |
Interviews |
Releases |
New Products |
Reviews |
[an error occurred while processing this directive] |
Editorial |
Events |
Sponsors |
Site Search |
Newsletters |
[an error occurred while processing this directive] |
Archives |
Past Issues |
Home |
Editors |
eDucation |
[an error occurred while processing this directive] |
Training |
Links |
Software |
Subscribe |
[an error occurred while processing this directive] |
This month’s topic, Building Backbones, or more generally, shared communications infrastructure, is one I have lived for two decades. For it to work without catastrophic failures, you need to commit to a shared cybersecurity infrastructure as well. Even the IT guys don’t want to talk to the Cybersecurity guys, so the challenges are greater than that of merely introducing the IT and OT. This month, I describe how I put systems that are insecure-by-design on the corporate backbone and then enabling remote access.
Recently, I had to design a security
architecture to allow remote access to several systems with no security
built-in. During renovations in a bioresearch facility, eleven cold
rooms were installed or upgraded, each with its own HMI. An HMI, or
Human Machine Interface, sounds 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 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 can be seen by external systems to access and interact in specifically defined ways with protected systems.
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.
[an error occurred while processing this directive]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 is 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 smartphones 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 in giving people
unintended rights in the future.
Aside from a very few suppliers, systems
in our world, that of Automated Buildings, are never secure when
delivered. Big busses and shared infrastructure are a fine vision, but
it takes some work and some creativity to securely place these systems
on the big bus.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]