Security Issues with BACnet Value Handling
Matthew Peacock, Michael N. Johnstone and Craig Valli
Security Research Institute, Edith Cowan University, Perth, Australia
Keywords:
Building Automation, State Modeling, Security, Heating Ventilation, Air Conditioning.
Abstract:
Building automation systems, or building management systems, control services such as heating, air-
conditioning and security access in facilities. A common protocol used to transmit data regarding the sta-
tus of components is BACnet. Unfortunately, whilst security is included in the BACnet standard, it is rarely
implemented by vendors of building automation systems. This lack of attention to security can lead to vulner-
abilities in the protocol being exploited with the result that the systems and the buildings they control can be
compromised. This paper describes a proof-of-concept protocol attack on a BACnet system and examines the
potential of modeling the basis of the attack.
1 INTRODUCTION
Building automation systems (BAS) rely on report-
ing and logging to relay communications between
devices automatically to ensure proper coordination
and operation of a buildings services. From a secu-
rity standpoint, protecting reporting and subsequently,
the operation of the BAS is a priority for the con-
tinuity of building operation. In regards to BAC-
net, a popular BAS protocol; the overuse of the
change of value (CoV) reporting method can cause
network peaks, resulting in denial of service. Rec-
ommended implementation-based solutions shift the
problem from network throughput to a security is-
sue, where use of CoV is limited by a buffer, which
can prevent core devices from receiving CoV noti-
fications (Chipkin, 2009). In addition, as operation
of BAS devices can cause cyber-physical actions to
occur, priority levels for commands must be defined
to resolve conflicts. The implementation of priority
within BACnet on cyber-physical properties lack clar-
ity. For example, in the current release of the BACnet
standard, system behaviour is undefined when multi-
ple devices write to the same property with the same
priority level (SSPC-135, 2012). This presents a po-
tential vulnerability as malicious writes represented
as legitimate value changes and the ensuing events
could have destructive consequences for the building
controlled by the BACnetwork.
The paper will discuss the BACnet structure, fol-
lowed by data value handling, and related security is-
sues. A theoretical attack is presented, with an ex-
perimental setup discussed. Further, examination of
modeling approaches to generate features and subse-
quently alerts for malicious events, to improve the re-
silience of building systems is discussed.
2 BACKGROUND
Security issues in BAS are an emergent threat, with
security analysis undertaken by (Holmberg, 2003),
(Kastner et al., 2005), (Granzer and Kastner, 2010)
and later (Peacock and Johnstone, 2014). (Holm-
berg, 2003), (Kastner et al., 2005) identify, denial of
service, eavesdropping and buffer overflows in core
functions of the protocol. While (Granzer and Kast-
ner, 2010) primarily discuss the limitations of secure
communication, exchange in BAS. (Holmberg, 2003)
and (Kastner et al., 2005) identify the increased con-
nectivity between previously isolated BAS networks,
corporate intranets and the Internet for remote man-
agement; an increasing trend, identified by (Peacock
and Johnstone, 2014). A number of these identified
vulnerabilities in BACnet have had mitigations sug-
gested such as the BACnet firewall (Holmberg et al.,
2006), however, (Peacock and Johnstone, 2014) iden-
tifies the potential of legitimate-yet-malicious com-
mands operating inside BACnetworks, which would
not pass traffic through a border firewall. A potential
solution is a BAS specific intrusion detection system
(IDS), the focus of work by (Johnstone et al., 2015)
and (Kaur et al., 2015).
546
Peacock, M., Johnstone, M. and Valli, C.
Security Issues with BACnet Value Handling.
DOI: 10.5220/0006263405460552
In Proceedings of the 3rd International Conference on Information Systems Security and Privacy (ICISSP 2017), pages 546-552
ISBN: 978-989-758-209-7
Copyright
c
 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

3 BACnet
BACnet is an object-oriented peer-based protocol for
managing building automation systems. Released in
1995 as an ASHRAE/ANSI standard, BACnet gained
ISO standardisation (ISO 16 484-5) in 2003. BACnet
is actively maintained, with reviews of the protocol
occurring every four years until 2008, thence chang-
ing to biennial reviews (SSPC-135, 2014). BACnet
focuses on the network layer and above, with the
goal of being operable on any data link and physical
medium. The BACnet standard defines data structures
to represent the communications and devices on a
BACnetwork. The core data structure is an object, of
which there are 54 standard types. When combined,
objects can represent a device, with each object con-
taining properties which further define the features of
the object. Similarly, communications on the network
are defined in the BACnet standard as services, of
which there are 38 types (SSPC-135, 2012). A core
process of BACnet is communicating values across
the network between devices to allow automatic ac-
tions to occur.
3.1 Data Collection in BACnet
Devices require correct, timely information in order
to act appropriately to events occurring in a building.
In BACnet, reportable information is defined as ei-
ther value-based or event-based, both of which are
time-stamped. As BACnet is a peer-based network,
any device in a BACnetwork may request values from
other devices, or be notified of events occurring. To
accomodate peer-based communications, by default
BACnet devices are passive servers which listen for
requests and service received requests. Each data
sharing transaction is represented as a client/server re-
quest, where the device requesting data is a client, and
the targeted device providing the data is the server.
A server in this case might be a temperature sensor,
whilst a client might be a HVAC controller. Depend-
ing on the data type, either value or event, the retrieval
process differs. Value data is shared using one or a
multiple of polling, change of value (CoV) reporting
or triggered collection; while event data uses event
logs to collect notifications. The three methods men-
tioned for value based reporting are implemented us-
ing a Trend Log object, which can monitor one object
or property on a device. When a value changes, a no-
tification is stored in an internal buffer in the Trend
log object, as a Trend log record. Each record holds
the timestamp of when the change occurred, and the
changed value of the monitored property.
Polling uses the default passive model previously
discussed, where data retrieval queries are made to
the server device at defined time intervals. A prob-
lem with polling is the potential for state and value
changes between polling intervals, the active value
changes of the system will not be updated unless they
exist when a query is sent. A careful balance is re-
quired, as increasing the frequency of polling can
impact the throughput of the network significantly
(Chipkin, 2009). An alternative is an active data col-
lection method called CoV reporting. CoV report-
ing uses a subscription-based method, where a client
may request a subscription to a particular object or
property value, shown as Figure 1. The subscrip-
tion details the property to monitor, the criteria for
issuance of notifications, and a lifetime for the sub-
scription. The CoV reporting method may be Con-
firmed with acknowledgement of notifications, or Un-
confirmed without acknowledgement. A third method
is triggered collection, which defines a boolean prop-
erty in a device, when the property is true, data is re-
trieved from the device. External network writes and
internal processes such as alarms or other events can
cause the trigger to become true, and cause an im-
mediate acquisition of values to occur. Any property
may be monitored using a Trend log object, and the
property information stored in the buffer can be of any
data type; making the buffer an unrestricted data type
storage area, and potential vulnerability.
3.2 Conflict Resolution
As mentioned previously, all BACnet devices are
peers, meaning any device, connected to the network
may write to any writable property on any other de-
vice. As some property values directly cause cyber-
physical actions to occur, conflict resolution in the
form of a priority system is implemented. BACnet
accounts for the potential of conflicting commands
through a conflict resolution process where proper-
ties are split into commandable, and writeable types.
Commandable properties are defined as those whose
value change causes physical actions, while all other
properties are defined as writeable. Conflict reso-
lution is only applied to commandable properties,
whereas writable properties have no priority mech-
anism, meaning the last write to the property over-
writes the previous value.
The present value property of most objects in BACnet
are classed as commandable properties, see Table 1
for a full listing.
BACnet devices interact with commandable prop-
erties using the WriteProperty or WritePropertyMul-
tiple service requests. The request primitive for both
services contain three parameters; Property Identifier,
Security Issues with BACnet Value Handling
547

Client Device Server Device
1) CoV Subscription Request
3) CoV Notification
6) CoV ACK
2) Value Change
4) Wait for ACK
5) Write to Buffer
Figure 1: Confirmed CoV transaction.
Table 1: Commandable properties in BACnet adapted from
ASHRAE STD 2012.
Object Commandable property
Analog Output Present Value
Binary Output Present Value
Multi-state Output Present Value
Multi-state Value Present Value
Analog Value Present Value
Binary Value Present Value
Access Door Present Value
BitString Value Present Value
CharacterString Value Present Value
Date Value Present Value
Date Pattern Value Present Value
DateTime Value Present Value
DateTime Pattern Value Present Value
Large Analog Value Present Value
OctetSTring Value Present Value
Integer Value Present Value
Time Value Present Value
Time Pattern Value Present Value
Positive Integer Present Value
Channel Present Value
Lighting Output Present Value
Property Value and Priority. The three parameters
contain the commandable properties ID, the desired
value for the property, and the priority value respec-
tively. The priority value is a number set between
1 and 16 for that WriteProperty service request, the
lowest number having the highest priority. The BAC-
net standard defines consistent representations for the
applications of command priority levels, with 5 de-
fined applications and 11 flexible open applications
which can be implementation specific, shown as Ta-
ble 2. When a client device no longer requires access
to the commandable property in a service provider,
a relinquish command is sent to the provider, using
WriteProperty or WritePropertyMultiple service re-
quests. The relinquish request uses the same parame-
ters as a normal write request with the property value
parameter set to NULL. When a device is notified that
no service request exists at that priority level, the next
priority array element is checked for a service request.
When all elements in the priority array are NULL the
property value will be set to the value defined in the
Relinquish Default property of the object.
Table 2: BACnet Priority array applications, adapted from
Newman, 2013.
Priority level Application
1 Manual Life Safety
2 Automatic Life Safety
3 Available
4 Available
5 Critical equipment control
6 Minimum on/off
7 Available
8 Manual Operator
9 Available
10 Available
11 Available
12 Available
13 Available
14 Available
15 Available
16 Available
3.3 BACnet Security
BACnet was not designed with security as a pri-
mary requirement, with early systems operating in
isolated networks without any external connection.
With the increasing connection of BACnetworks to
external facing networks, such as the Internet or en-
terprise networks for maintenance, the attack surface
has increased. Holmberg (Holmberg, 2003), docu-
mented a number of the threats to BACnet, with fur-
ther work being undertaken by (Kastner et al., 2005)
to increase the security features of BACnet. In 2009,
the suggestions from the threat assessment were rat-
ified as BACnet security services (BSS), as Adden-
dum g to the BACnet standard. Despite being an of-
ficial addendum to the standard, BSS is not widely
implemented, with Newman, the original chairman
of BACnet stating “no company has yet implemented
it in a commercially available product” (Newman,
2013). Additionally, Newman(Newman, 2013) sug-
gests that BACnet/IP could be secured using IP se-
curity solutions, such as IPsec, TLS, or Kerberos. In
contrast, given that a number of BACnet vulnerabili-
ties are not solved by encryption (as in the aforemen-
tioned protocols), but rely on authentication instead,
this indicates that the coverage of the attack surface is
incomplete and therefore not all BACnet vulnerabili-
ties are mitigated.
ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy
548

4 SECURITY ISSUES IN VALUE
CHANGES
In a BACnetwork, devices can operate via a client-
server architectural model where the “server” is the
service provider (SP) or transmitting device (such as
a thermometer) and the “client” is a controller, such
as an air handling unit, or human machine interface.
This model has the following properties:
1. One (or more) clients subscribe to the SP
2. Requests can be queued
3. The queue is stored on the SP
This model is well-known as the publish/subscribe
model. In software development, this is implemented
by the Observer design pattern (Gamma et al., 1995).
Given that BACnet is object-oriented (or at least
claims to be so), it is useful to briefly examine the
principles of the Observer pattern as this informs our
discussion about a specific BACnet vulnerability.
The Observer pattern describes a one-to-many
connection between objects such that when an object
undergoes a state (data) change, its connected (depen-
dent) objects are notified automatically. Convention-
ally, the object that is the source of notification events
is called the subject and the observer objects register
with the subject in order to be notified of changes in
the subject. As the subject is the sole owner of the
data, the observers are reliant on the subject to up-
date them when the data changes (i.e. a state change).
Consistent with the loose coupling exhibited by many
design patterns, observers can be added or removed
from a list maintained by the subject at any time.
The Observer pattern is quite common and is found
in the model-view-controller architecture (and thus in
many user interface toolkits, such as Java Swing). A
concrete example would be the buttons that might be
found on a web form are subjects that notify action
listeners (observers) of events (e.g., a mouse click).
Returning to BACnet, the SP acts as the sub-
ject and maintains a list of subscribers (observers),
namely the Active CoV subscriptions is the list which
holds the CoV subscriptions on the SP. As mentioned,
CoV subscriptions may be either Confirmed or Un-
confirmed, a data service type reminiscent of TCP or
UDP in operation. Unconfirmed CoV reporting sends
a notification to the subscriber when a value changes
within the CoV threshold of the subscription. Con-
firmed CoV reporting incorporates acknowledgement
of change, with an ACK packet to be sent from the
subscriber to the device serving the data.
Due to the many media on which BACnet oper-
ates, some devices take longer to acknowledge a Con-
firmed CoV than others. Two device object properties,
APDU timeout and Number Of APDU Retries set on
the client device determine how long to wait for an
acknowledgement, and how many times to retry wait-
ing. The values for these properties are vendor spe-
Table 3: BACnet Vendor APDU-Timeout default values.
Vendor APDU timeout
value (ms)
APDU
retries
Viking Controls 3000/60,000 3
Siemens 3000 3
Obvius 6000 3
ScadaEngine 500 5
Kepware 1000 3
Tridium 20,000 3
Contemporary
Controls
3000 3
cific, the BACnet standard suggests between 6000ms,
and 10,000ms(Newman, 2013); the de facto standard
set by the vendors is a 3000ms wait time, with 3
retries see Table 3. Some vendor guides suggest a
20,000ms or even 60,000ms wait time, dependent on
the capability of older devices; one guide suggests all
APDU timeouts should be set to the highest value in
the system. If a subscriber is offline when a Con-
firmed CoV notification is sent, the CoV server de-
vice will wait the length of the APDU Timeout of
the client device, and then retry the CoV notifica-
tion the specified number of times before process-
ing the next CoV notification. Given the length of
some APDU timeout values and the number of re-
tries, significant network delays can occur (Chipkin,
2009). Additionally, when a subscriber goes offline,
CoV messages are not stored or queued, therefore if
a subscriber returns to the network, data synchronisa-
tion can be lost. If the subscription is Unconfirmed,
there is no feasible way to determine if the subscriber
has received the CoV notification, or tell if the sub-
scribing device is offline. A combination of polling
and CoV is suggested to counteract devices power cy-
cling, however the solution is not complete, as the log-
ging device for the system could suffer from the same
issue, and the log of a CoV will never be recorded
(Chipkin, 2009). Subscriptions to devices are not per-
sistent between power cycles, meaning if a device is
reset for any reason, the subscriptions to other devices
will not be preserved and must be re-connected.
A solution exists for automatic re-subscriptions,
where a duration property exists in the Trend log
object, which triggers a CoV subscription to occur.
However, the integrity of the BACnetwork is then de-
pendent on client devices re-subscribing to keep a
synchronised and robust system. Due to the capac-
ity of BACnetworks, oversubscription of CoV notifi-
cations is plausible. Robust testing of oversubscrip-
Security Issues with BACnet Value Handling
549

tion is often not carried out, due to the risk of damage
to devices (Chipkin, 2009; Newman, 2013). An im-
plementation guideline solution suggests limiting the
number of subscriptions a device is capable of hold-
ing, to reduce the potential traffic density. A device
on the BACnetwork may subscribe to the same ob-
ject multiple times, as the unique identifier for each
subscription is self-assigned. Each implementation of
a device may have a limit applied to the quantity of
subscriptions that each device can initiate. This bot-
tleneck creates a network security issue, where crit-
ical devices will not receive notifications due to the
subscription limit being reached (malicious or not).
4.1 Issues with Bounded Priority
Arrays
An identified issue with the array implementation of
BACnet is that each priority value in the array may
have only one command stored at a time. As de-
scribed, upon relinquishing an array position, a device
will write a NULL value to the array position, which
causes “unknown behaviour” for the queued com-
mand in the same array position (SSPC-135, 2012).
As source authentication is not specified for write
commands entering the priority table, the priority ar-
ray attempts to create a queue of values to enter into
a commandable property. An issue similar to writable
commands is created, where a write first wins sce-
nario is created, negating the purpose of the array,
when same priority commands are issued. Addition-
ally, as there is no verification of priorities on com-
mands, any device may change the value of a com-
mandable property at any priority. Similar to Con-
firmed CoV notifications, these commandable prop-
erty writes are legitimate traffic which could be ex-
pected to be made on the network. (Johnstone et al.,
2015) assessed the possibility of detection using time
deltas between same packets with success for writes
with the highest priority. Potentially, the same type
of detection could be applied to the priority of same
packets from an identical source device to determine
malicious behaviour.
4.2 Theoretical Attack Scenario
A potential scenario could manifest as a malicious
device sending Confirmed, low threshold value CoV
subscriptions to every supported device on the BAC-
network, and then shutting itself down. Whenever a
value on any device changes the malicious device will
be notified, but as the malicious device is offline, each
legitimate device will then wait for the timeout to ex-
pire before sending the next notification. A model of
the attack is detailed as Figure 2.
As the APDU timeout property is defined on the
client of the transaction, the malicious device may
set the length to wait, and the number of retry at-
tempts. (Newman, 2013). Detection of the attack
may be achievable given the vendor timeout values
detailed in Table 3, as values which differ drastically
from the defacto-standards may be easily identified.
However, as a device may subscribe multiple times
to another device, a proposed attack chain involves
subscribing within the normal time values, up to 20
seconds, with three retries and multiple subscriptions
thus increasing the denial of service on the device by
each subsequent subscription. The impact of manipu-
lating the timeout values is dependent on the building
services provided, and the criticality of the buildings
contents. Preventing values being reported on the net-
work is of serious concern, with a clear reduction in
availability to the cyber-physical systems controlled
on the network. Given that the commands used to
cause the attack are legitimate, and can appear to be
normal traffic on a BACnetwork, a different type of
detection method, with contextual analysis of the net-
work is required to identify these situations.
5 EXPERIMENTAL ANALYSIS
Experimentation is required to examine the impact of
this attack, and the potential of identification and clas-
sification. As described, robust CoV testing is often
not undertaken due to fear of network and physical
degradation. As such, an experimental setup was de-
veloped for generation of network traffic, and manip-
ulation of CoV values, the materials used are noted in
Table 4. The experimental setup resembles a subset of
Table 4: Experimental Setup Materials.
Software/Hardware Details
Raspbian Jessie R2016-09-23, V4.4
CBMS Studio V1.3.7.1204
CBMS Engineering
configuration tool
V1.3.1221.7
Bacnet Open Stack V0.82
Windows 7 SP1
Wireshark V1.12.1
3x Raspberry Pi 2 1GB ram, 16GB SD card
Cisco 3560 Switch SPAN configured
Windows 7 Desktop 16gb Ram, 128GB SSD
a BACnet controlled HVAC service. The air handling
unit (AHU) acts as a client, subscribing to the ther-
mostat present value property, when a value change
occurs the AHU is notified. A CBMS BACnet server
instance runs on the thermostat Raspberry Pi, emu-
ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy
550

Client Device Server Device
1) CoV Subscription Request
4) CoV Notification
7) CoV ACK
3) Value Change
5) Wait for ACK
6) Write to Buffer
2) Client Disconnect
Figure 2: Malicious Confirmed CoV transaction.
Rpi-
Thermostat
Rpi-AHU
Rpi
Logger
Cisco 3560
Windows 7
Configuration
Desktop
Figure 3: Experimental Setup.
lating a thermostat. The AHU subscription is under-
taken using the BACnet protocol stack version 0.81.
Configuration of the thermostat is undertaken using
the CBMS engineering tool, running on the Windows
7 configuration desktop. All traffic on the network is
port mirrored to the Raspberry Pi logger device, using
Wireshark for packet capture and analysis. A graph-
ical depiction of the experimental setup is shown as
Figure 3.
Initial experimental results shown in Table 5 are
encouraging, with a server device failing when a ma-
licious client disconnected from the network. Pack-
ets 80040 and 80041 show a normal CoV notification
and ACK details (shown as a reject due to a limited
server implementation). Packets 80327, 80510 and
80656 show three attempted notifications, 10 seconds
apart after the device has disconnected. During the 30
second window, the tracked server value was changed
multiple times, none of these changes were reported
as the server device waited for the acknowledgement
packet from the disconnected client. Entry 81438 and
81439 show a value change and subsequent return to
a normal notification and ACK, shortly after the client
device was reconnected. No CoV notifications were
generated by the server device while it waited for the
ACK from an offline client. When the client recon-
nected, multiple changes in value that would normally
trigger alerts were never disseminated to the client.
Further experimentation is being undertaken to in-
corporate further subscribing devices, to determine
the impact on the subscribed device if multiple sub-
scriptions exist, and one subscriber is not connected
during a CoV occurrence.
Modelling the legitimate-yet-malicious scenarios
may reveal further information, such as a network pat-
tern or activity which could indicate a malicious event
taking place from legitimate commands. Such a pat-
tern or activity could be suitable for a detection rule.
6 DISCUSSION
We have described a vulnerability in BACnet that
could have serious consequences to infrastructure.
This vulnerability, in itself, is not the problem as
we foresee a catastrophic second-order effect aris-
ing from the realisation of the threat. The full ex-
tent of this type of attack, and further attacks could
be explored using an adversary model. Bodeau and
Graubart (Bodeau and Graubart, 2013) outline the
purpose of an adversary model as defining the intent,
objective and strategy of a threat being realised, in re-
lation to an adversary profile. As such, it would be
beneficial to explore and define a profile for an ad-
versary intent on disrupting building operations. A
potential second-order attack could be crafted to take
advantage of this vulnerability through delaying re-
sponse to a temperature controller, adversely affecting
a datacentre where servers that house financial data
operate. The loss of banking data or even the time de-
lay whilst such data are recovered from a backup are
significant events for any financial institution.
Due to the time-dependent nature of cyber-
physical systems, models that can express time are
useful for verifying certain properties of the system.
Clearly, the CoV communication process of the BAC-
net protocol, where time is a factor for successful
completion of a command, is one such area.
It is likely that any modelling notation/technique
that can express a queue and has some notion of
state, could represent this type of problem and be
able to verify aspects of the system. Z (Spivey,
1989), Communicating Sequential Processes (Hoare,
1978) or even possibly the Object Constraint Lan-
guage ((OMG), 2014) would be excellent candidates.
Each of these formal notations could model the
BACnet change of value reporting. The application
to detection of these legitimate events may be linked
to the time between events, therefore monitoring the
timeout durations on devices waiting for acknowl-
edgements is likely the way forward. The peer-based
nature of the protocol, coupled with multiple sub-
Security Issues with BACnet Value Handling
551

Table 5: Initial experimentation results.
No. Time Source Destination Protocol Length Info
80040 19:58:32.5 192.168.1.12 192.168.1.5 BACnet 85 Confirmed-REQ confirmedCOVNotification[ 67]
device,9999 analog-output,1 present-value
80041 19:58:32.5 192.168.1.5 192.168.1.12 BACnet 60 Reject unrecognized-service[ 67]
80327 19:58:48.4 192.168.1.12 192.168.1.5 BACnet 85 Confirmed-REQ confirmedCOVNotification[ 69]
device,9999 analog-output,1 present-value
80510 19:58:58.4 192.168.1.12 192.168.1.5 BACnet 85 Confirmed-REQ confirmedCOVNotification[ 69]
device,9999 analog-output,1 present-value
80656 19:59:08.4 192.168.1.12 192.168.1.5 BACnet 85 Confirmed-REQ confirmedCOVNotification[ 69]
device,9999 analog-output,1 present-value
81438 19:59:48.5 192.168.1.12 192.168.1.5 BACnet 85 Confirmed-REQ confirmedCOVNotification[ 70]
device,9999 analog-output,1 present-value
81439 19:59:48.5 192.168.1.5 192.168.1.12 BACnet 60 Reject unrecognized-service[ 70]
scriptions and source authentication means that there
is the potential to have this duration value increased
by a malicious host.
7 CONCLUSION
This paper described a proof-of-concept attack on any
building automation system that uses the BACnet pro-
tocol change of value reporting function as part of
their communication and control, and suggested that
a formal proof of the attack would be valuable. We
found that while BACnet has a security addendum
to the standard which defines source authentication,
this is not implemented in practice. We deployed an
experimental setup to investigate the phenomena de-
rived from the BACnet standard, with initial results
promising. We defined a situation where multiple
subscriptions and a lack of source authentication can
cause a failure of critical infrastructure, leading to a
more serious second-order effect, using banking sys-
tems as an example.
In future work, we intend to expand on our exper-
imental testbed, to incorporate more subscribed de-
vices, and widen the scope to other services. Further
experiments will be undertaken, to test the array relin-
quish issue to determine what actually happens given
network traces and memory allocation to the device.
The CoV experiments will be expanded, with inves-
tigation into the use of different stack implementa-
tions, to verify if the behaviour can be generalised.
Finally, we will explore modeling of the protocol to
derive identification patterns, along with defining an
adversary model for building automation.
REFERENCES
Bodeau, D. and Graubart, R. (2013). Characterizing effects
on the cyber adversary: A vocabulary for analysis and
assessment. Technical report, MITRE.
Chipkin, P. (2009). Bacnet for field technicians. Technical
report, Chipkin Automation Systems.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
(1995). Design Patterns: Elements of Reusable
Object-oriented Software. Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA.
Granzer, W. and Kastner, W. (2010). Communication ser-
vices for secure building automation networks. In In-
dustrial Electronics (ISIE), 2010 IEEE International
Symposium on, pages 3380–3385.
Hoare, C. A. R. (1978). Communicating sequential pro-
cesses. Commun. ACM, 21(8):666–677.
Holmberg, D. G. (2003). Bacnet wide area network security
threat assessment. Technical report, NIST.
Holmberg, D. G., Bender, J. J., and Galler, M. A. (2006).
Using the bacnet firewall router. ASHRAE American
Society for Heating, Refrigeration and Air Condition-
ing Journal, 48(11).
Johnstone, M. N., Peacock, M., and den Hartog, J. (2015).
Timing attack detection on bacnet via a machine learn-
ing approach. In Proceedings of the 13th Australian
Information Security Management Conference, pages
pp57–64.
Kastner, W., Neugschwandtner, G., Soucek, S., and New-
man, H. (2005). Communication systems for build-
ing automation and control. Proceedings of the IEEE,
93(6):1178–1203.
Kaur, J., Tonejc, J., Wendzel, S., and Meier, M. (2015). Se-
curing bacnet’s pitfalls. In Federrath, H. and Goll-
mann, D., editors, ICT Systems Security and Privacy
Protection, volume 455 of IFIP Advances in Informa-
tion and Communication Technology, pages 616–629.
Springer International Publishing.
Newman, H. M. (2013). BACnet: The Global Standard for
Building Automation and Control Networks.
(OMG), O. M. G. (2014). Object Constraint Language
(OCL). Version 2.4.
Peacock, M. and Johnstone, M. N. (2014). An analysis
of security issues in building automation systems. In
Proceedings of the 12th Australian Information Secu-
rity Management Conference, pages 100–104.
Spivey, J. M. (1989). The Z Notation: A Reference Manual.
Prentice-Hall, Inc., Upper Saddle River, NJ, USA.
SSPC-135 (2012). Bacnet: A data communciation protocol
for building automation and control networks.
SSPC-135 (2014). Bacnet addenda and companion stan-
dards.
ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy
552