Tách raSửaĐóng

Văn Phòng Đại Diện tại Việt Nam

#29.05, Tòa nhà Pearl Plaza, 561A, Đường Điện Biên Phủ
Phường 25, Quận Bình Thạnh
Thành Phố Hồ Chí Minh, Việt Nam

+84 28 7300-2439
info@beckhoff.com.vn
www.beckhoff.com/vi-vn/

Nov 22, 2023

BACnet as a secure standard in building automation

BACnet Secure Connect – Making building automation secure

Published in: building&automation 07/2023, VDE Verlag, www.vde-verlag.de

When the BACnet (building automation and control networks) standard was first released in 1995, cybersecurity was not yet a concern in the field of building automation. The open and interoperable nature of BACnet contributed to its quick and widespread adoption; however, global networking and the integration of the Internet into building automation equipment now pose new challenges for IT security. This is where BACnet Secure Connect comes in to tackle these evolving concerns.

While 56-bit DES encryption has been a standard feature of BACnet since it was first launched on the market, it has gone mostly unused in practice. Since fall 2019, however, an extension of the standard has been available in the form of BACnet Secure Connect (BACnet/SC), which sets the bar for the most up-to-date cybersecurity measures.

Frank Schubert has been working in the Building Automation Marketing & Training department at Beckhoff Automation GmbH & Co. KG, Verl, since 2015. He has been involved with the BACnet standard since 1997, is a member of the Marketing and Technical Working Groups in the BACnet Interest Group Europe, and active in the BACnet Committee SSPC-135 at ASHRAE, supporting the ongoing development of the BACnet standard.
Frank Schubert has been working in the Building Automation Marketing & Training department at Beckhoff Automation GmbH & Co. KG, Verl, since 2015. He has been involved with the BACnet standard since 1997, is a member of the Marketing and Technical Working Groups in the BACnet Interest Group Europe, and active in the BACnet Committee SSPC-135 at ASHRAE, supporting the ongoing development of the BACnet standard.

Aside from the security concerns, BACnet projects have traditionally often faced resistance from IT managers, with the use of broadcast messages and the somewhat unconventional assignment of the port number (dec. 47808 = hex BAC0) frequently met with skepticism.

In a bid to address these concerns, three clear objectives were set for the development of BACnet/SC:

  • enhanced cybersecurity through the use of the latest TLS 1.3 standard and X.509 certificates
  • IT-friendliness achieved by leveraging established IT standards and protocols
  • downward compatibility (routing) with existing BACnet systems

Technical configuration of BACnet Secure Connect

BACnet/SC uses WebSockets based on the TCP protocol for communication. These WebSockets are based on relaying HTTPS connections, which IT departments are familiar with as a well-known and established procedure. It makes no difference whether the currently prevalent IPv4 or IPv6 is used, and even the media (data link layer) may vary – for example, Ethernet, Wi-Fi, 4G, or 5G. BACnet/SC complements the existing eight data link layers, such as BACnet/IP or MS/TP, ensuring that existing BACnet networks can be easily connected to a secure BACnet/SC infrastructure (BACnet routing).

BACnet/SC is based on a ‘hub-and-spoke’ architecture, where all communication and device authentication are handled through a central hub known as the primary hub (PH). In the event of a communication failure, a failover hub (FH) takes over this role. This is ideally connected to a different power supply and located in a separate fire zone and IT segment. The option is also available for two devices to communicate with each other directly (direct connect), for example, to ensure better scalability or share important messages. In this case, the devices authenticate each other mutually.

For remote access from outside via the insecure Internet, PH and FH can also be hosted off-site in cloud systems. The local firewall is also very IT-friendly in terms of the necessary configuration and therefore straightforward to operate. Only outgoing HTTPS traffic needs to be enabled, which is typically already configured in most IT networks.

Use of certificates

The TLS1.3 standard uses X.509 certificates, which are signed by a central certificate authority (CA) to allow devices to trust each other. When a device presents the certificate to the hub, it checks details such as its validity, expiration date, and CA authentication.

The CA does not have to be provided externally; it can be operated locally as part of the IT infrastructure using software like OpenSSL, but proper access control is essential to prevent security breaches.

Organizational challenges for building automation

All of these technical requirements give rise to a whole host of new organizational tasks and challenges in practice. Cyber certificates are only secure if they are regularly replaced; those with very long (e.g., several years’) or even unlimited validity are worthless. If the certificate for a device expires and is not renewed, it is no longer possible to communicate with that device until the certificate is updated. This raises the question during projects of who is responsible for these tasks and for performing regular updates: the system integrator during annual maintenance, the facility manager, or the IT department?

TwinCAT 3 from Beckhoff integrates all important subsystems such as BACnet and also supports BACnet rev. 14 with TwinCAT 3 BACnet (TF8020).
TwinCAT 3 from Beckhoff integrates all important subsystems such as BACnet and also supports BACnet rev. 14 with TwinCAT 3 BACnet (TF8020).

To automate this process, the BACnet standard defines a procedure in which a device generates a certificate signing request (CSR) as a file. This file is then transferred to the CA, where it is signed and returned to the device as a signed certificate. With this procedure in place, certificates can be replaced with minimal effort and therefore updated at regular intervals.

Convergence of IT and OT

In today’s building automation projects, the boundaries between IT (information technology) and OT (operational technology) are often blurred and no longer clearly distinguishable. Attacks on these systems have increased exponentially in recent years, leading to continuously rising cybersecurity requirements. Inadequately protected OT systems often serve as gateways for cyberattacks, and building automation components can also be impacted by threats from the IT sector.

It is with all of this in mind that the IT and BA departments have to collaborate and work together closely to maximize their defense against attacks. It is also essential to define organizational processes and have appropriate data backups in place in case of a successful attack. Yet even with the best preparation, a successful attack can result in several months of downtime and significant financial damage.

A user- or role-based authentication and authorization system is currently in the initial stages as an addendum to the BACnet standard.

Secure communication systems

BACnet/SC faces challenges in gaining acceptance compared to established, equally secure communication systems such as OPC UA. Many consider the need to secure open BACnet as urgent; however, IT departments often advocate for the use of OPC UA or MQTT. Firewall rules for anomaly detection are already in place for these protocols, while they are often still lacking for the relatively new BACnet/SC.

It therefore remains to be seen which protocol or standard will prevail and gain the necessary acceptance from all stakeholders. On the other hand, BACnet/SC continues to use the established BACnet object model and the same services as with data link layer such as MS/TP or BACnet/IP, which means existing systems can be migrated with little effort. Regardless of the outcome, there is one thing that remains certain: In a networked world, building automation must be designed with security in mind.

Further information