IT security and data

01Why this has become a subject

The Danish building regulations now require building automation in buildings above a certain size. For buildings with a design heating or cooling demand above 290 kW, the systems must be monitored and controlled, and operational data must be collected at a resolution of at most five minutes and kept for at least 60 weeks.

The requirement to collect and keep the data is there. The requirement to protect it is not.

The result is buildings where a technical network has grown system by system, without anyone holding the overall responsibility. That is the situation Technical network is about putting right.

02The protocols are not secure in themselves

The protocols building automation rests on were developed for closed networks, where the physical separation was the security.

Modbus dates from 1979 and checks neither who is asking nor whether the answer is genuine. BACnet was designed for isolated networks and does not encrypt. Whoever can reach the network can in practice both read and write. A secured version of BACnet does exist, but most systems you meet do not run on it.

The consequence can be measured. A survey from January 2024 found around 110,000 industrial control devices directly reachable on the internet. Modbus accounted for close to a third of them.

And it is not theoretical. A breach at Target in 2013 began with stolen credentials from a supplier of refrigeration and ventilation equipment. Since 2021, lighting control systems have been locked permanently through a weakness that is still being exploited.

You do not secure BACnet. You secure the network around it.

04Securing the network in practice

The division is a decision. What enforces it is the switches. A managed switch is therefore not a comfort choice on a technical network, but the place where most of the security actually sits.

Close what is not in use

Network sockets that are not used should be switched off at the switch. A socket in a meeting room that still belongs to the technical network is an open door nobody has noticed.

Tie the socket to what is plugged into it

A switch can remember which device sits on each port and object if a different one suddenly appears.

It is not a lock. A device can pretend to be another one, and a determined attacker gets past it. What it does catch is what happens far more often than attacks: the laptop a technician plugged into a spare port, or the small switch someone hung on because a socket was missing.

Where the equipment can manage it, there is proper access control at port level. A large part of the field equipment in a building cannot, and that will remain so for many years.

Switch on the protections the switch already has

Most managed switches can do a number of things that are rarely switched on. Four of them make a real difference on a technical network:

• only the correct device may hand out addresses, so nobody can make themselves the signpost for the whole network
• false replies are rejected, so nobody can place themselves between the building management system and a controller and listen in or change things on the way
• a random switch someone brings along cannot take over control of the network
• a single device cannot fill everything, so one fault does not bring down a whole segment

They are called DHCP snooping, ARP inspection, BPDU guard and storm control, if someone needs to look them up.

Fixed addresses and a list of what is plugged in

Controllers and gateways should have fixed addresses. An address that moves after a power cut becomes a piece of fault finding nobody connects with the network.

And there has to be a list: what sits where, and with which address. It is both operations and security, because it is the precondition for being able to see that something new has appeared.

Note that when the network is divided, BACnet's automatic search for devices stops working across the segments. That has a known solution, but it belongs in the design and not in a piece of fault finding afterwards.

Access and monitoring

Access to the switches should be personal, and factory passwords should be changed at commissioning. Shared logins cannot be closed when a contractor is finished, and they cannot be attributed to anyone afterwards.

The switch should also send its log somewhere that someone looks. Three things are worth being told about, because they are rarely innocent: a socket changing state without anyone having reported work, a new device on a port that usually has a different one, and a device appearing somewhere it is not on the list.

Finally, the switch configuration belongs in the backup, and plant rooms and cabinets have to be locked. A network where you can walk up to a socket and plug something in is not divided, whatever the configuration says.

05Encryption and backup

Encryption solves one problem: that someone reads or alters data in transit or on a stolen medium. It does not solve someone holding a valid access they should not have.

In practice it means that connections out of the building are encrypted, that backups are too, and that the technical network inside is protected by its division, because the protocols there cannot encrypt themselves.

A backup sitting next to the machine protects against a disk failure and nothing else. The common rule of thumb is three copies, on two kinds of media, one of which is somewhere else. But the important thing is not the number of copies. It is whether they work.

The question is not whether backups are taken. It is when one was last restored.

07When building data is personal data

Operational data is about systems, not about people. But that does not always hold.

Data becomes personal data when it can be attributed to a person who can be identified. That does not depend on what was intended, but on the resolution. An occupancy sensor in a large canteen says something about the building. The same sensor in an office with one user says when that person was at work.

The same goes for access control and alarm arming, which show who came and went when, and for consumption measured per tenancy. The Danish Data Protection Agency has monitoring of employees as a focus area and explicitly mentions the recording of working hours through alarm arming and access cards.

That does not mean you should avoid measuring. It means the purpose has to be decided in advance, the resolution should be no finer than the purpose requires, and the legal basis, the information given and the retention period have to be in order.

If a supplier processes personal data on behalf of the building owner, the General Data Protection Regulation requires a written data processing agreement, setting out among other things the purpose, the instructions, the security measures, the sub-processors and what happens on termination.

Note too that the building documentation itself can be sensitive for other reasons. Network diagrams and point lists with access details should be treated as confidential material, whether or not they contain personal data.

08What to require of a supplier

A short list to take into a tender or to a meeting:

• A documented network design. Which zones, which connections between them, and a requirement that no ports are opened inwards towards the building.
• A configuration that can be handed over as a file. What sits where, which sockets are in use, what is switched on, and which are closed. Not as an assurance, but as documentation.
• A declared support period and a described process for how vulnerabilities are handled and reported.
• Personal access and logged remote access that the building owner can cut off.
• Data ownership and export. Who owns the measurement data, in what format can it be pulled out, and what happens on termination?
• A backup that has been restored as a test, and where the network equipment's configuration is included.
• A list of what is not secured. Existing systems without protection should be stated in the delivery as a known limitation, not hidden.

The last one matters most. A supplier who can account for what is not secured has looked at it.