Where Does Building Security Start

The path to securing BMS assets

The BMS industry has been on a path to securing BMS assets and systems for many years. For Trend, this accelerated greatly when we introduced an Ethernet gateway to the proprietary Trend current loop network. This married the Trend BMS structure to the IT system in a significantly more prominent way than before, and this increased data speeds, simplified cabling, improved data access and allowed much greater connectivity across large and distributed estates. This was now more than 20 years ago, and just the first step to the globally accessible BMS infrastructure we commonly see now – all of which came about as a direct result of that first melding of the BMS and IT worlds. The prior focus was on preventing authorised users from performing unauthorised actions, such as adjusting something they should not, like temperature controls for physical areas outside their control, or changing critical control parameters. The focus changed the moment an RJ45 Ethernet lead was plugged into a formerly isolated BMS network.

The goal of preventing interference

Both in the IT and OT world, in such instances where a distinction is made between the two, the first defence is to prevent access for anyone, or anything, not allowed. For example, it would be highly unwise to allow a non-authorised person to access the point-of-sale system for a large department store.

There are many other layers of defence above that, where physical access to cabling is prevented for those not directly required to have access, or even disallowing access to an entire building for those people who have no business being there.

The goal has always been preventing malicious interference. Individuals, organisations and even governments could wish to gain unauthorised access to another’s BMS structure. They might want to make a building uncomfortably hot or cold, or they may want to shut down a critical piece of plant.

Malicious interference could even stretch to gathering information relating to a company’s financial health and occupancy data. Still, specifiers and installers often overlook how security actually applies to their chosen system.

Now, it would be unusual for data traffic between a supervisor like IQVISION and the controls network to be unencrypted, or “in the clear.” The connection between the Trend driver and IQ4 has been capable of encrypted communication for many years. Elsewhere, and in other systems, it’s not unknown for encryption to be absent.

BACnet now includes BACnet SC, which encrypts communications at the controller and supervisory level – but not necessarily at every other level or in every device. Prior to BACnet SC, the messages were readable and easy to intercept.

But what about the peer-to-peer communications between controllers? If sensitive information can be sniffed off a network with freely available software, then the protocols used for transmission can be intercepted and manipulated.

Encryption at the controller level

Encryption at the controller level is possible but usually entails an engineering and maintenance overhead in certificate handling – each controller must provide proof of identity, so encryption at this level is often missing and rarely insisted upon.

At the sharp end, where the controller does the actual business of driving outputs and reading sensor and meter data et al, we have expandable I/O modules. These are commonly connected using inexpensive wire and open protocols. BACnet MS/TP and Modbus are used mainly because they cost less to implement.

But they are completely open, unencrypted and easy to manipulate. Open-source BACnet tools are readily available, and given a simple RS485 gateway on a laptop, a malicious actor could take control over real physical outputs and override them however they might choose. Or they could subtly interfere with physical inputs, generate spurious meter readings, and perhaps even falsify fire alarm signals. Any of these malicious acts have the potential to negatively affect people and processes. These implications could range from the relatively minor but inconvenient, to very serious. For example, overly annoyed employees in a poorly controlled environment, or erroneous financial calculations from manipulated meter data, to building evacuation if a critical alarm is deliberately spoofed.

Trend’s remote I/O was developed differently. IQ3 and IQ4 first used Canbus, a technology borrowed from the high-end automotive industry, and now IQ5 uses T1L to communicate and drive its I/O. This new remote I/O bus in IQ5 is IP-based, facilitating high-speed communication and control, and encryption of all traffic – and it does all this without relying on expensive cabling.

Coupled with IQ5’s automated certification and user administration features, the remote I/O bus is simple and secure in use, easing the stress and effort of difficult or time-consuming tasks. We all have a responsibility to protect our buildings and their systems. At Trend, we take that responsibility very seriously.

________________________________________________________________________________________________________________________

Want to protect your building from harm? Our Partners can apply the optimum protection to your BEMS. 

Protect your building with IQ5

________________________________________________________________________________________________________________________