Many initiatives are being developed globally to limit the energy consumption of buildings, to reduce operational costs and to help hit the targets for lowering CO2 emissions. Such measures include the integration of automation devices and information technologies to improve the energy efficiency of buildings.
More broadly, this growing integration of automated systems within modern buildings, aims to meet three needs:
● Improving the energy efficiency of buildings,
● Securing buildings by installing video surveillance devices, implementing physical access control and managing fire and intruder alarms,
● Improving user comfort by automating services such as heating, ventilation, air conditioning or even lighting.
In practice, smart buildings are physical cyber systems which consist of sensors, actuators, PLCs and computers whose interaction control and monitor electrical and mechanical equipment, thereby meeting the needs mentioned above. Unlike their historical predecessors, modern smart buildings target a greater interoperability between the various equipment through standard and open protocols.
The global architecture of a smart building, outlined in Figure 1, can be divided into three layers:
● The field layer, situated near the monitored physical environment, consists of sensors and actuators. These communicate with the upper layer's PLCs through electric signals or field protocols.
● The automation layer contains a set of PLCs which are used to: (i) read measurements taken by the sensors, (ii) run control logic, (iii) send commands to the actuators. In order to carry out these distributed control functionalities, the PLCs also communicate with each other. These exchanges are carried out using industrial protocols specific to the building sector such as BACnet or KNX.
● The automation layer's data are centralized in the management layer, making it possible to monitor the control loops via SCADA (Supervisory Control and Data Acquisition) software or to log data using historian servers. Unlike the lower levels, the protocols in the management layer strongly resemble traditional IT protocols.
Lastly, smart buildings can also communicate via the internet. It is also becoming more and more common to offer operators remote access to buildings through external monitoring servers.
Improving equipment interoperability dedicated to different technical areas (heating, access control, ventilation, etc.) within a smart building requires the adoption of standard technologies and open communication protocols. In practice, many of these protocols, in particular old ones, often do not have security mechanisms. Connecting smart buildings to the internet might therefore open the door to intrusion attempts by hackers as in the case of the Google attacks .
Furthermore, these buildings often accommodate several organizations and businesses which therefore increases the number of possible entry points. Security measures thus need to be developed for this sector. The purpose of the subsequent sections is to provide an overview of the vulnerabilities and attacks targeting the BACnet protocol, including some advances in intrusion detection.
Communication within the automation layer of a smart building relies on several domain-specific industrial protocols. KNX is an example of such smart building protocols. Created by the Konnex Association in 1999, KNX is used in commercial and residential buildings to control heating, ventilation, lighting, access control or even energy management. Likewise, LONWORKS, created in 1988 by the Echelon Corporation and standardized by ANSI in 1999, is an industrial protocol mostly used in the building sector (ventilation, lighting, etc.). A systematic review of research work on the security of smart building protocols was carried in . The remainder of this document will focus on BACnet.
ASHRAE BACnet (Building Automation and Control networks), created at Cornell University in 1987 and standardized by ANSI in 1995 then by ISO in 2003 (ISO 16484-5 and ISO 16484-6), is a protocol dedicated to the building sector and is supported by hundreds of vendors. BACnet is used in various technical areas such as heating, ventilation, lighting, fire detection systems and physical access control. The protocol is mostly found in the automation and management layers of smart buildings.
BACnet represents information within equipment through objects characterized by typed properties (name-value pairs). These objects can represent physical (status of inputs and outputs) or logical (control logic, applications, calculations, etc.) information. Thus, an object encapsulates a set of information which describes the equipment or which is of interest for other BACnet equipment. Each object within the BACnet equipment has a unique identifier coded with 32 bits including the object type and instance code.
The BACnet standard defines 54 standard object types whose semantics are consistent for all BACnet equipment. For example, each BACnet equipment implements a Device type object whose attributes describe the equipment (Vendor_Name, Vendor_Identifier, Model_Name, Firmware_Revision, Application_Software_Version, etc.).
In addition to objects and their properties, BACnet also specifies the services. There are 5 types of services:
● Access to objects (read, write, create, delete),
● Equipment management (discovery, clock synchronization, initializing, storing and restoring the database),
● Alarms and events,
● File transfer,
● Virtual console (HMI via consoles and menus).
BACnet also defines seven types of networks that can be used to send BACnet messages:
● BACnet MS/TP (RS485),
● BACnet ISO 8802-3 (Ethernet),
● BACnet over ARCNET,
● BACnet Point-to-Point,
● BACnet over LongTalk Foreign Frames,
● BACnet over ZigBee.
For example, BACnet/IP messages are sent in UDP/IP packets (port 47808 or 47809 by default) while ISO 8802-3 BACnet messages are directly encapsulated in Ethernet frames. In practice, BACnet/IP and BACnet MS/TP are the most frequently used types.
In terms of message structure, the BACnet standard specifies two layers:
● A network layer represented by a Network Protocol Data Unit (NPDU),
● An application layer represented by an Application Protocol Data Unit (APDU).
The structure of an NPDU is shown in Figure 2. The first part of an NPDU, called the Network Protocol Control Information (NPCI), specifies the BACnet version used, the source (SNET) and destination (DNET) networks, the source (SADR) and destination (DADR) addresses, as well as a hop count which is a value decremented on each routing action in order to prevent a message from circulating indefinitely within the network. The NPCI also contains the NPCI Control Octet which specifies whether the second part of the NPDU, called the Network Service Data Unit (NSDU), contains the data used for network routing (Network Layer Message) or whether it contains BACnet application data (APDU).
The header of an APDU, called the Application Protocol Control Information (APCI), specifies the parameters required for invoking a BACnet service as well as for dealing with the congestion and fragmentation of BACnet messages (as in TCP). Figure 3 represents the APCI structure for a BACnet Confirmed Request type message. The rest of an APDU contains data pertaining to the requested services.
In 2009, a set of security mechanisms were ratified in Addendum g of the BACnet standard as BACnet Security Services (BSS). This extension to the standard follows the works published by the NIST in 2003 highlighting some threats on BACnet .
These measures include the symmetric encryption of BACnet messages via AES in CBC mode, defining a key server for distributing shared secrets, as well as checking the accuracy of data using timestamps. However, in practice these measures are rarely implemented , and introducing them may lead to incompatibility with the existing BACnet networks and components .
This section presents a set of known attacks targeting the BACnet protocol. These attacks are divided into 6 categories:
● BACnet network recognition attacks,
● BACnet messages spoofing
● Denial of service through BACnet message flooding,
● Attacks through covert channels,
● Attacks exploiting the BACnet subscription schema
● Attacks by writing variables.
During the network recognition and mapping phase, an attacker can issue BACnet Who-Is type messages to retrieve information about BACnet addresses and component identifiers present on the network.
Likewise, the attacker can also use Who-Has messages in order to identify BACnet components that have an object (for example, a temperature sensor). Any component that has an object whose identifier or name corresponds to the Who-Has request must issue a response on the network. This behavior corresponds to normal BACnet operation.
The attacker can also exploit Read-Property type requests in order to collect information about the vendor's identifier, the template name, as well as objects and services that are supported by BACnet equipment.
BACnet messages spoofing
Numerous attacks on the BACnet protocol exploit the capacity of the attacker to spoof BACnet messages. The I-Am service is normally used to respond to Who-Is requests. Since there is no verification mechanism in place, any component can impersonate another component on the network.
Consequently, an attacker can intercept unintended BACnet traffic and perform any number of operations on the intercepted traffic (blocking the messages, modifying their content, eavesdropping on the exchanges, etc.). The reaction of a component when receiving two I-Am responses (one from the legitimate component and one from the attacker) is specific to each vendor. For some BACnet stacks such as the BACnet Open Stack, only the first response is taken into account.
An attacker can also redirect traffic by spoofing BACnet I-Am-Router-To-Network type messages. This type of message is normally used to indicate the availability of a router on a particular network.
Denial of service via BACnet message flooding
Here, the objective of the attacker is to send a substantial amount of BACnet messages on the network in order to slow it down and prevent components operating correctly. In the simplest case, an attacker can issue repetitive Who-Is type requests by varying the identifiers of the requested components.
On the other hand, an attacker can spoof the source address (SADR and SNET) in BACnet Who-Is-Router-To-Network type messages. These messages are used to identify BACnet routers on a given network. The target machine therefore receives more responses than it can handle, leading to a denial of service. Likewise, the attacker can spoof I-Am-Router-To-Network type messages with the address of a specific machine, then issue messages on the network so that the target machine receives all the responses as well as the subsequent traffic to be routed.
Attacks through covert channels
Research  has shown that it is possible to set up covert channels via BACnet messages. The aim of these covert channels is to hide the existence of a flow of information that can violate the system's security policy.
For example, such channels may serve as a means of communication between machines that are part of a botnet and a command-and-control server. To achieve this, the researchers use network layer (NPDU) Who-Is-Router-To- Network and I-Am-Router-To-Network type messages, as well as application layer (APDU) Who-Has and Who-Is type messages.
In order to set up a covert channel, the issuer and the receiver must agree on the encoding beforehand (for example, by assigning the following values: Who-Has → 00, Who-Is → 01, Who-Is-Router-To-Network → 10, I-Am-Router-To-Network → 11), the identifier of the network to use for NPDU layer requests, as well as the identifier of the component to use for the Who-Has request. Generally, with n different types of messages (4 here), the attacker can send log2(n) bits per message.
The researchers also suggest using parameters of specific BACnet messages such as the network identifier of the Who-Is-Router-To-Network requests. The difference resides in the fact that the number of bits conveyed by each message only depends on the modified parameters and not the total number of message types used for the encoding. Finally, the researchers also suggest an approach based on the time between Who-Is message packets. However, this approach can draw attention as it risks generating a significant amount of traffic of the same type of messages.
Attacks exploiting the BACnet subscription template
The BACnet standard offers BACnet clients the option of subscribing to specific variables on the BACnet servers. The server then sends a notification to the subscribers for each subscribed variable value change. These notifications may need to be acknowledged by the subscribers. These are referred to as Confirmed notifications.
When a subscriber does not acknowledge a notification, the server resends the notification at the end of the response time set by the APDU_Timeout parameter. The maximum number of tries is defined by the Number_Of_APDU_Retries parameter. The default value of the APDU_Timeout and Number_Of_APDU_Retries parameters is usually set at 300 ms and 3 tries respectively, but this can vary depending on the manufacturer. However, when subscribing to a BACnet server, the client can specify the value of the APDU_Timeout parameter.
Consequently, a possible attack scenario  consists in: (i) subscribing to all the BACnet equipment on the network, (ii) requiring notifications to be acknowledged while specifying a low value for the APDU_Timeout parameter, and then (iii) disconnecting from the network. In this way, when a variable on a piece of BACnet equipment changes value, notifications are sent at an increased frequency on the network without receiving acknowledgment.
The attacker can renew the subscription when the number of attempts reaches the Number_Of_APDU_Retries value. Please note that a client can subscribe several times on the same BACnet server. This increases the attack's effectiveness and prevents the attacker from manipulating the Number_Of_APDU_Retries parameter which can be easily detected when compared to the values specified by the manufacturer.
Attacks by writing variables
In the absence of any security mechanisms, an attacker can modify the value of BACnet object properties through Write-Property commands either by playing with the set of values of the property type or by writing values outside the range of expected values.
Furthermore, it is also possible to exploit legitimate BACnet commands in order to modify the control logic, thereby interfering with the nominal behavior of the controlled physical system. This type of attack requires sufficient knowledge about the operation of the targeted building.
In this scenario, an attacker can exploit services such as Write-Property or Delete-Object in order to change the behavior of the BACnet components in accordance with the sensor measurements. This may lead to human and equipment damage.
In this section, we explore detection approaches that are appropriate to BACnet networks. The purpose of an intrusion detection system (IDS) is to detect, via an automated process, violations to a system's security policy. In contrast to the preventive measures recommended in Addendum g, IDS are essentially reactive security measures that detect security breaches.
Similar to IDS developed for industrial systems, most of the work for BACnet focuses on network detection approaches. Likewise, most of the research involves behavioral detection approaches; the principle being to detect deviations from a nominal behavior reference of the system.
These approaches are deemed promising because they can detect new attacks by capitalizing on the regularities observed on the BACnet networks. In the remainder of this section, we will take a look at approaches along the same lines.
The authors in  seek to characterize the traffic flowing in a BACnet network on a campus containing around a hundred BACnet components. A flow is defined on the basis of protocol fields in the BACnet protocol network layer (SNET, DNET, SADR, DADR) as well as in the Ethernet (MAC source and destination addresses, VLAN identifier) and IP (network source and destination addresses) layers. Then, statistical measurements on the number of packets and the number of bytes are computed for each flow identified on the network.
These measurements show statistical regularities for certain types of BACnet messages, in particular I-Am-Router-To-Network messages (issued every 30 minutes) and Read-Property messages (distinctive diurnal behavior). These uniformities make it possible to derive the normal behavior of the system and to detect attacks causing significant statistical deviations (such as denial of service through flooding). However, such an approach would be difficult to transpose to targeted attacks only requiring a few messages such as physical variable manipulations.
Inspired by the BACnet flow notion and the protocol attributes developed by , other researchers  suggest a behavioral intrusion detection approach based on a predictive rule-based induction algorithm (RIPPER algorithm ) that can classify the legitimacy of a flow over a given period of time. The research is carried out on a simulated BACnet network, representing a fire detection system.
The authors consider their approach as effective when faced with a set of attacks such as denials of service. However, a fundamental limit of the approach is the absence of any context regarding the status of the physical process. Therefore, the approach would fail to detect physical process-oriented attacks modifying legitimate Write-Property messages which, from a network point of view, would not lead to any significant deviation from the behavior seen while learning the rules.
Following a different approach, the work in [9, 10] develops a specification-based intrusion detection approach. Here, information extracted from the BACnet network specification and configuration files is used to automatically create rules that can work out the expected behavior of the system.
Information is extracted automatically:
● By carrying out a preliminary mapping and identification phase of the network's BACnet components via the Read-Property or Read-Multiple-Properties requests on the Device type object properties,
● By retrieving, for each identified component, information from specification files such as the Protocol Implementation Conformance Statement (PICS) and Engineering Data Exchange (EDE) files. These files are defined by the manufacturers (PICS) or by the operators for each installation (EDE) and describe the objects and services implemented for each component.
Then, the rules are automatically built to express constraints concerning:
● The objects implemented for each component,
● All the values allowed for the object properties,
● The supported services.
However, similar to the approaches developed by [6, 7], the context of the physical process is missing from the detection approach. In this way, an attack that leads to forbidden process behavior while respecting the constraints concerning the requested objects, the types of requests and values of the properties cannot be detected by this approach.
As for a number of industrial protocols, including those used in smart buildings (KNX, LONWorks), the BACnet protocol was not designed with security in mind. Despite the efforts to include security mechanisms within the standard, their implementation on a wide scale faces numerous problems in terms of compatibility and migration costs. BACnet networks therefore need to be monitored in order to detect intrusion attempts.
Nevertheless, while current approaches seem to detect noisy attacks on the network (such as denials of service through flooding), they do not seem to cover targeted attacks that aim to leave the physical process in a critical state. Despite the extensive knowledge of physical processes and control loops required to carry such attacks, their high impact should motivate further research in physical process-aware intrusion detection for smart buildings.
 Pierre CIHOLAS et al. “The Security of Smart Buildings: a Systematic Literature Review”. In: CoRR abs/1901.05837 (2019). arXiv: 1901.05837. URL: http://arxiv.org/abs/ 1901.05837.
 CYLANCE. Google’s Buildings Hackable. URL: https://threatvector.cylance.com/en_us/home/Google-s-Buildings-Hackable.html.
 Jaspreet KAUR et al. “Securing BACnet’s Pitfalls”. In: 30th IFIP International Information Security Conference (SEC). Under the dir. of Hannes FEDERRATH and Dieter GOLLMANN. T. AICT- 455. ICT Systems Security and Privacy Protection. Part 9: Cyber-physical Systems and Critical Infrastructures Security. Hamburg, Germany, May 2015, p. 616-629. URL: https://hal.inria.fr/hal-01345153.
 David G. HOLMBERG, National Institute of standards and Technology (U.S.) BACnet wide area network security threat assessment [electronic resource] / David G. Holmberg. English EN Dept. of Commerce, National Institute of Standards and Technology [Gaithersburg, Md.], 2003.
 S. WENDZEL, B. KAHLER and T. RIST. “Covert Channels and Their Prevention in Building Automation Protocols: A Prototype Exemplified Using BACnet”. In: 2012 IEEE International Conference on Green Computing and Communications. Nov. 2012, p. 731-736. DOI: 10.1109/GreenCom.2012.120.
 Radek KREJCÍ, Pavel CELEDA and Jakub DOBROVOLNÝ. “Traffic Measurement and Analysis of Building Automation and Control Networks”. In: Dependable Networks and Services. Under the dir. of Ramin SADRE et al. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012, p. 62-73. ISBN: 978-3-642-30633-4.
 Z. PAN, S. HARIRI and Y. AL-NASHIF. “Anomaly based intrusion detection for Building Automation and Control networks”. In: 2014 IEEE/ACS 11th International Conference on Computer Systems and Applications (AICCSA). Nov. 2014, p. 72-77. DOI: 10.1109/AICCSA. 2014.7073181.
 William W. COHEN. “Fast Effective Rule Induction”. In: In Proceedings of the Twelfth International Conference on Machine Learning. Morgan Kaufmann, 1995, p. 115-123.
 Marco CASELLI et al. “Specification Mining for Intrusion Detection in Networked Control Systems”. In: 25th USENIX Security Symposium (USENIX Security 16). Austin, TX: USENIX Association, 2016, p. 791-806. ISBN: 978-1-931971-32-4. URL: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/caselli.
 Herson ESQUIVEL-VARGAS, Marco CASELLI and Andreas PETER. “Automatic Deployment of Specification-based Intrusion Detection in the BACnet Protocol”. In: Proceedings of the 2017 Workshop on Cyber-Physical Systems Security and PrivaCy. CPS ’17. Dallas, Texas, USA: ACM, 2017, p. 25-36. ISBN: 978-1-4503-5394-6. DOI: 10.1145/3140241.3140244. URL: http://doi.acm.org/10.1145/3140241.3140244.