Network level simulation

Historically, the network level of a BAS requires gateway devices to translate between protocols to allow networking access between devices. Typically, a network controller connects multiple application controllers together, which in turn are connected to a range of underlying sensors and actuators. Protocol convertors and broadcast forwarders sit in between controllers and field devices, or are embedded into the controllers. With a full BACnet/IP network, the topology can follow a more traditional IP-based network. The network topology is considerably flat, with related sensors, actuators and controllers all located within one subnetwork. Each air handling unit can be split into separate subnetworks with BACnet-routers used for cross-subnet broadcasts, or, depending on the size, the full system can be in one subnet. For this simulation, the entire building’s BAS is in a single subnetwork. For network capture, all traffic is port forwarded to a capture port, where Dumpcap (Combs, 2017) is used to capture the traffic. An external network connection exists to a physical switch, whereby a deployment management system, and the external attacker device are located. Further attacker information is defined in Section 4.6.9.

The BACnet devices and network traffic are defined using the BACnet open stack (Karg, 2017), where the profiles described in section 4.6.7 were used to construct the devices which are deployed into lightweight Ubuntu virtual machines. Using the BACnet open stack (Karg, 2017) allowed the simulation to be defined in software, rather than being restricted based on the specific vendor hardware controllers in use, providing a more generic simulation.

While the BACnet open stack (Karg, 2017) is the most complete of any identified open source BACnet stack, it is described as a baseline system, with the requirement of customising the BACnet open stack to implement into a device. A number of core functions were required to be implemen- ted into the BACnet open stack to represent the behaviour of the devices for this scenario. These included a method of handling CoV requests, identified in Johnstone et al. (2015) as being in- complete, and ensuring each device was represented appropriately. The BACnet open stack was amended in the following ways to be used in this scenario.

1. The CoV handler function for analog input values was defined in the analog input object definition, by default, only the CoV handler for binary input values was defined.

2. The present value for analog outputs had a range restriction from 0.0 to 100.0, this was removed to allow fan speeds in RPM defined in the scenario to be held in analog output objects.

3. To allow for controller devices to subscribe to other devices, the confirmed CoV subscription code was implemented into the device code.

The behaviour of the devices are defined based on best practices (‘Best Practices in HVAC Controls’, 2012) and analysis revealed by the real data analysis undertaken in §5.2.1. Each air handling unit controller manages a range of sensors and actuators. Namely, each air handling unit polls each duct sensor for its analog input. The analog outputs are used to control the actuators

and fans. The values of the analog outputs are calculated based on the input values from the sensors using the control logic defined in §4.6.6. Each thermostat controls an associated VAV box in its zone, where it reads the values of the pressure sensor and flow sensor, and uses the analog output control to position the damper actuator in the VAV box. The communication paths are further detailed in Figure 4.18.

Drawn from the analysis of the real captured data from the university network, the choice of controller impacts heavily on the BACnet commands traversing the network, particularly Write property commands. Vendors can implement proprietary middleware network protocols, which encapsulate BACnet commands. These commands are often classed as commandable properties, such as write commands. As the real network data captured relies on a closed source middleware BACnet layer for Write property commands, it is unclear what real network behaviour would entail for write commands. Thus the assumption is made that write commands to output values, whose values command physical changes in systems do occur; while write commands to input values do not occur given they are used to hold sensor reading values. This assumption aligns with the default behaviour of the BACnet open stack (Karg, 2017), and was implemented as the normal behaviour for the simulation scenario. Given the discrepancies between the simulation data, which contains write commands in native BACnet, and the real dataset, which uses a proprietary protocol to encapsulate the majority of BACnet write commands, the simulation data which involves write commands has been omitted for statistical comparisons between the datasets.

Internally, for the simulation to operate the controllers need to make decisions based on the data it holds on each sensor it manages. The logic of each device is defined in §4.6.6. The data read from each sensor is stored in a corresponding input object, which informs the value to be written to actuators from the output objects in the controller. For the simulation, this internal process is undertaken through reading datapoints into the object after receiving the current value from the sensor. This is dependent on timing, as the data is read in every second based on the values generated, while the polling occurs at intervals. The polling interval is different for each vendor and implementation. For example, Shepard (2013) details a one second minimum polling interval, while Thn (2017) defaults its polling interval at two seconds. The real traffic analysis identified a polling interval of eight seconds on setpoint values. Polling is synchronous, the device polls one object then the next in a list. If the network bandwidth is limited, or there are a large number of polls, the network would constantly be polling for values. For this simulation, the values being polled are not static setpoints, rather, sensor values. Additionally, there are three controllers polling seven sensors and two thermostats each, six thermostats polling six VAV boxes, and the logger device polling every device in the network every 15 minutes. As such, an interval of 10 seconds between polls was selected, to reduce the network bandwidth consumed if the minimum polling time was set, and to ensure polling is not a continuous action in the network. Revealed through analysis of the real network traffic detailed in §5.2.1, each object subscription has a subscription duration of five hours, with re-subscriptions occurring every 20 minutes. This behaviour was replicated in the simulation scenario.

Some BACnet systems implement a logging device, which retrieves values from other devices in the network for long term storage, either in a database or flat file. This type of logging often relies on the trendlog object being implemented in a device. As noted from the analysis of Internet-facing devices in §4.2, only supervisory/control devices typically implement trendlog objects. Alternat- ively, a logging device could use normal polling via the Read property or Read property multiple service to retrieve values from sensors and actuators, in addition to controllers. The polling ap- proach was undertaken for the simulation scenario, whereby a logging device polled the present value property in each object in each device every 15 minutes.

The simulation was run on a VMware ESXI 6.0 Server, which had 32GB of RAM and an AMD 3GHz 8 core processor, totalling 24GHz processing power for the virtual machines housed on the server. The normal simulation consisted of 59 virtual machines running for 31 days. There were seven classes of virtual machine, six for the types of devices running in the simulator, and one type for capturing the network traffic. The simulation consisted of 21 actuator devices, 21 sensor devices, 3 controllers, 6 thermostats, 6 VAV boxes, 1 workstation and 1 logging device. The specifications for each device type are detailed in §3.7, Table 3.10. The average load of the ESXi Host CPU per virtual machine was 200 MHz, the average load of the ESXi Host memory per virtual machine was 150 MB for sensors, and 400MB for controllers and thermostats. With a baseline defined and used to generate network traffic classed as normal, an attack framework was developed to generate malicious traffic for this scenario.

AHU 100 Thermostat 130 VAV 131 Analog Input 0 Analog Input 1 Analog Output 0 Thermostat 135 VAV 136 Analog Input 0 Analog Input 1 Analog Output 0

Actuator 110 Analog Output 0

Actuator 111 Analog Output 0

Actuator 112 Analog Output 0

Actuator 113 Analog Output 0

Actuator 114 Analog Output 0

Actuator 115 Analog Output 0

Actuator 116 Analog Output 0

Sensor 120 Analog Input 0

Sensor 121 Analog Input 0

Sensor 122 Analog Input 0

Sensor 123 Analog Input 0

Sensor 124 Analog Input 0

Sensor 125 Analog Input 0

Sensor 126 Analog Input 0

AHU 101 AHU102

Figure 4.18: Logical mapping of simulated devices and the prominent underly- ing BACnet data structures

Legend W

x1

Workstation L

x1

Logger C

x3

Controller TS

x6

Thermostat VAV

x6

Volume DeviceVariable Air

F

x6

Fan A

x15

Actuator T

x9

Temperature Sensor P

x3

Pressure Sensor FS

x9

SensorFlow ESXi Host

Virtual Distributed Switch

T

P

FS

A

C

TS

VAV

F

L

W

NC

NC

x1

Network Capture

Figure 4.19: Network topology of the defined simulation scenario

In document Anomaly Detection in BACnet/IP managed Building Automation Systems (Page 164-169)