en
cz

Network security at building control systems

Building control systems and networks

Building control systems are highly underestimated regarding network security. There are several reasons for this: Suppliers are companies whose core business is far away from IT security, like construction companies, HVAC suppliers, plumbers, and the like; at the time the system is designed it is not clear how it will be connected to the Internet; and the control system designers do not have the IT background necessary, anyway. Ten to fifteen years ago, it was not common to have a BMS system connected to the Internet at all. End users do not care much for IT security either, unless the technological network is part of their standard IT security policy.

The attacks on the building management systems are not originated by frustrated (ex-)employees or malicious hackers only. There are programs on the Internet which scan the networks automatically, and search for open ports and services which could be used to penetrate the internal networks. The programs are relentless, operating with high performance 24 hours a day. Because of intense deployment of IT standards, standard communication protocols, and web services, the probability of being attacked gets higher. An unprotected device connected to a public IP address usually registers an attack attempt within several hours or even minutes.

If the building managers are asked why the BMS security is neglected in such a large scale, we learn that „this is not a nuclear power plant“, „everybody is doing it like this“, or that there is no money for security improvements; mostly the managers are even not aware of the risks. Network security measures also complicate the remote access a bit, and remote access should be as easy as possible. Another issue is the long lifetime of the BMS, which may reach up to 15 or 20 years. In its course, the PC together with its operating system is upgraded several times, SCADA must be reinstalled, and updates are installed on the PC which may spoil the functionality of some program modules. This brings along service costs. The workstation must be restarted with the hotfixes, the average uptime decreases, and there may be gaps in trend data. The operators then try to avoid the updates, claiming „If it works, don’t touch it“. Moreover, they want to have the simplest remote access possible, e.g. without having to log into a VPN; and there are client platforms where the required VPN clients are not available anyway.

Process stations

Lately, there have been reported attacks not only to the SCADA PCs, but also to the automation stations, or PLCs. The process stations are mostly devices which have been designed to another purpose than to resist network attacks; in simple words, the Ethernet interface is typically able to process a small load of connections and may be easily congested by frequent connection and disconnection attempts. The process station then keeps on controlling the plant, but it can not connect to SCADA or other PLCs in the network.

It is not always possible to protect the PLC directly, as PLCs tend to have limited computing resources. For example, the Saia PCD process stations offer at least simple measures, such as IP address filtering (communication follows only with the IP addresses which are listed in a table in the PLC). Enhanced security only can be achieved using external IT components, such as VPN and firewalls. Port forwarding is considered dangerous. Siemens recommends industrial security routers (Scalance) priced € 500 and above. Other costs are qualified setup and router maintenance.

Some communication protocols used in BMSs and their security

Modbus TCP

Modbus is a favourite communication protocol because of its simplicity. The price for its easy implementation is, however, the Modbus register table completely open for reading and writing just by definition. If the attacker finds the TCP port 502 open, he or she can read and write values in the device without any autentification. It is not difficult to imagine the consequences. The suppliers tend to protect Modbus devices against incidental writing for example by implementing a rule which says that if the write command has to be accepted, it must be preceded by writing a particular value into a particular register. It is clear that with security, as we need it, this has not very much in common. Modbus devices therefore must not be NATed directly on the Internet. Even port forwarding and using another TCP port than the default 502 does not help. I had a discussion with a customer who brought a Modbus TCP room thermostat 1:1 to a public IP address and enjoyed comfortable web access as well as possibility of thermostat setup over a Modbus-based configuration program. This is an extreme case, comparable to unhanging one’s front door – I do not have to search for keys in my pocket when I return home.

BACnet

BACnet gets more and more popular because it is often implemented in the PLCs, it is easy to integrate, and supports even more complex entities, like alarms, time schedulers, etc. The BACnet standard in its original form did not support security at all, its specification being enhanced with security functions in 2008. However, the security functions are still not implemented widely in 2015, e.g. Siemens intends to implement them in 2016, offering a proxy service and VPN-based central hosting service today. Another problem is that BACnet does not use TCP/IP for data transfer (it is based on UDP/IP, exceptionally even on BACnet/Ethernet – addressing using MAC addresses), so trying to secure BACnet using standard IT firewalls which control TCP traffic does not make much sense. Everything is open in a BACnet network, a list of objects can be read from a PLC, and the values of the objects can be changed using standard tools, like various BACnet browsers, Domat BACnet Tool etc. In [1], four examples of BACnet attacks are described together with the ways how to detect them. So far, the only reasonable way how to protect BACnet-based devices is to operate them in a closed technological network which is accessible only over a VPN under circumstances below.

Other protocols

Ideally, the technological or customer network is considered as potentially dangerous, and even the data transfer between the PLCs and clients (such as SCADA or development environment) should be secured. The entire communication should then be secured at a level which corresponds with a public network (the Internet). Security in general deals with two issues:

  • to encode the information so that it can not be read by a 3rd party – this meets for example the implementation of the SSCP protocol at Domat mark320 process stations,
  • to make sure that the other party is who it claims to be, or verify it. Digital certificates are used which expire after a certain time, so there is a risk of communication loss „all of a sudden“ after a certificate has expired. This is why verification is usually not implemented.

Low computing power of a PLC which is not able to process the encryption algorithms may also be a problem. For example, the communication between a Domat PLC to a proxy server and Merbon DB database uses authentication, but it is not encrypted. Most of the proprietary protocols of world’s leading PLC manufacturers expect that the PLCs operate in closed networks or VPNs and therefore do not deal with security at all (e.g. Buderus, Linde, Daikin), others use just username and password to define user access rights level rather than to protect the communication as such. Encryption using keys is supported e.g. by Honeywell in communication between Galaxy security control panel and 3rd party programs, stating that „…the algorithm is a compromise between reasonable security degree and implementation at less powerful hardware platforms (8-bit microcontrollers)“.

SCADA

The computer with the process visualisation software is apparently the most critical spot in the system because of following reasons:

  • it is a PC usually running Microsoft Windows which is the primary target of network attacks
  • it is mostly used as a workstation of the building engineer, including Internet access
  • as a supply of the general contractor it may be out of the central IT management, and thus not updated regularly
  • the building engineers use the workstation also for private purposes, tend to install other software etc.
  • it may be available for remote access over the Internet for service purposes using some of the remote access programs (remote desktop, TeamViewer, UltraVNC,…)
  • or it even hosts the web server for remote web access to the SCADA

The protection of the workstation consists of several basic rules:

  • using a proven antivirus software updated on a regular basis, the PC is protected against viruses from the Internet or exchangeable media (CD, USB)
  • the Windows firewall must be enabled after finishing all the commissioning and tests, and rules for correct functions of all programs have to be set. The rule is that only necessary services are enabled, all others are disabled by default
  • minimize the number of ports forwarded from public IP addresses, forwarding should only be configured where necessary
  • if possible, rules on the firewall shall be defined, such as access from certain IP addresses only; one of the best approaches is to use VPN for remote access.
  • if a web server is running on a PC, check its security settings in the web server configuration
  • use reasonable password policy – see below.

Cooperation with customer’s IT department

If the technological network is part of the building or company IT infrastructure, as it is for example at department store chains, there is a close cooperation between BMS supplier and suppliers of other technologies, like access and fire protection system, chillers, commercial cooling, etc. The IT department then sets the rules for network communication, assigns IP address ranges to the subcontractors, and is responsible for network security according to company standards. The situation is easier for the BMS supplier then, it is only necessary to agree on rules for device exchange, extensions, and service. It happens that after a new IT guy comes, the easiest way for him is to delete all the routing rules, wait who calls, and then enable the services on demand only. This may result in broken communication lasting for days, and data loss (e.g. temperature records from cooling boxes for the sanitary supervision).

As BMS suppliers, we have to fully comply with the IT rules. Incoming network connections using port forwarding may be banned completely. Then, a VPN, or proxy service (not to be confused with a proxy server as a security interface for separating of two networks and filtering of traffic or data analysis between them) may help, where a PLC or a special router establishes an outgoing conection from the customer’s network to the Internet to a proxy server, and transfers data to the company which provides facility management or BMS service. The ways depend on the IT policy of the customer, but also on the personality of the IT responsible.

Protection by user name and password

User name and password are the basic means of user access control, but also for some communication protocols between the PLCs (e.g. Domat SoftPLC Link). It is worth to use it. Changing the administrator password from the default one to another helps also against system seizure by competitor or when arguing who damaged the system by misconfiguration. It is not a bad idea to follow these rules:

  • change all default usernames and passwords, change the administrator password
  • use strong passwords (even if the control systems do not force you to)
  • check the user list regularly (at service inspections), remove unused user accounts
  • where available, check the user login records against anomalies.


This hint list, however, has a slight problem: unlike at strictly individual services like e-banking, e-mail etc., BMS servicing employs more people using the same resources. Passwords, if changed at all, are recorded in the service documentation or companies store them on the Intranet in a single file. Leak of this document, of course, is an extreme security issue.

Routers and port forwarding

Forwarding of TCP or UDP ports from a public IP address to the internal network is the most frequent way how to access a PLC from the Internet for a SCADA in a facility management company or for the BMS service. Unfortunately, the forwarded ports are clear target of network attacks. Let’s try to limit forwarding to a minimum, and protect the forwarded ports by another means like PLC password other than default, or IP address whitelist in the router. Do not forget to secure the router itself; it is surprising how many routers do have default usernames and passwords set, and how often a technological network is available over a WiFi connection.

Fig.1: Port forwarding (NAT). The remote computer connects to the public IP address of the router over different ports: VNC client to the SCADA PC to control remotely, SoftPLC development environment to the PLC runtime to change parameters and monitor all variables, and web client to the web server in the PLC.

VPN

A VPN, virtual private network, is a secured tunnel which connects a remote computer and the internal (technological) network. After a connection has been established, the remote computer appears so as if it was connected directly in the technological network. The communication between the remote computer and the network is encrypted, so the data transferred between the remote computer and the internal network can not be monitored by a 3rd party. There is a range of hardware and software VPN servers and clients on the market, some of them even for free. The benefits of the VPN are low price, easy setup, and high security of the connection, but the main pro is that the protected tunnel gives the remote computer access to all services of the internal network. (With port forwarding, it is necessary to configure a separate port for each service, see above.) A risk is that eventual malicious programs of the remote computer can spread over the entire internal network, unless the VPN is configured with certain limitations. To log in, a key with variable code can be used, which represents a very high degree of protection: the user identifies himself using two factors, something he knows (PIN), and something he has (a code on the display of the key, that changed every 60 seconds).

A hardware to set up a VPN is available starting at € 400, very popular are e.g. Mikrotik routers; the main item in the budget are costs for setup and maintenance. Several hours of an experienced IT guy shall do.Fig.2: Connection into a technological network over VPN. A software VPN client on the remote computer establishes connection with the VPN server, and sets up a secured tunnel. The remote computer then becomes a virtual part of the technological network.

Remote desktop

Remote desktop is a service providing remote commanding of a computer located in the internal network using a remote computer and a special software. It makes possible e.g. remote training, remote SCADA engineering or remote configuration of the SCADA computer. The access to the remote desktop must be set up in the firewall, it is recommended to combine it with other measures, such as access from predefined IP addresses only (those of the servicing company or facility manager). The advantage of the remote desktop is that only programs which are installed on the local computer may run in the internal network. Nevertheless, it is possible to copy another program from the remote computer to the local computer, to install it and to run it. The access to the remote desktop is protected by username and password; again, it is advised to set up access from predefined IP addresses only. This increases security, but may decrease flexibility: the service engineer will not be able to connect for example from his home or from a hotel where spends his vacations or his business trip.

Web access

A very popular interface for remote access is the web. The problem is that web servers are frequent targets of attacks. It is not a big chance that a malicious program can be run on a PLC over a web request, but a PC-based web server is more subject to this type of attacks. Using other TCP port than 80 is not a security measure, the best solution may be to run the web server in a demilitarized zone (a network area separated both from the internal network and from the Internet). For compact PLCs with embedded web servers, the best would be a stateful firewall with packet inspection. It means that every telegram is checked not only regarding source and destination addresses, but content, too; it is inspected regarding consistency with the other telegrams in the stream and conformity of its data to the communication protocol used, or in other words, if it does not contain malicious commands. A https access does not protect against attacks, it is a measure against being tapped by a 3rd party. Web access usually provides a fairly priced solution for technology control over a common web browser, but on the other hand, it does not always provide the full functionality of the regular SCADA.

Conclusion

The aim of this article was to point out the risks and suggest suitable solutions, not to explain their implementation thoroughly. It is apparent that a process station or a PLC should not be visible over a public IP address (however, it can often be found there); the designers and engineers should discuss the security issues even in the planning phase and not just leave everything on an informal discussion of the engineer and the building manager. In this case, it happens that the system is set up „just to work“ and there is no time for anything else. This approach may strike back later in form of unexpected system dropouts, unavailability of the PLCs in the network, or even technologies being accessed remotely by unauthorised persons. Basic measures, such as locking of machinery rooms, and documentation management, should not be neglected, either. A properly secured building control system represents, after all, a good reference for the subcontractor. „Open control systems“ simply should not be up to their names literally.

Literature

[1] Čeleda, Krejčí, Krmíček: Flow-based Security Issue Detection in Building Automation and Control Networks, http://is.muni.cz/repo/990346/bacnet-security-paper.pdf