The
security and scalability of BACnet/IP: why the 'B' in BACnet is
singular and stands for a Building not a widespread Enterprise
of Buildings. BACnet/IP is an extremely important protocol in
Richards-Zeta's (RZ) product arsenal: this is how open, multi-vendor
M2M communication is predominately done today. RZ fully supports
BACnet/IP, however we do not require this architecture over the
internet, WAN or between facilities. The majority of the industry
problematically uses BACnet/IP as the vehicle to aggregate information
from multiple buildings/sites (enterprise) into a central server
(client-server architecture with a single point of failure) where
management and data visualization occurs. RZ on the other hand
pushes that functionality towards the edge forming peer to peer
"cloud" architecture. This important architectural difference
has significant implications that touch fault tolerance, security,
management and overall scalability; both from the perspective
of adding additional buildings (Mediators) and feeding data hungry
services like Automated Fault Detection and Diagnostics (AFDD)
that mandate robust and reliable data delivery to reap their value.
With the inception of the internet and its associated standards,
coupled with building owners and facility managers increased demand
for connected buildings, controls vendors and technology providers
have been struggling to provide solutions and maintain market
share. With go to market technologies and standards that were
created and adopted prior to the inception of the internet, these
players are attempting to provide a new standard that allows the
advanced technologies of todays pervasive internet to apply to
Building Automation.
The ASHRAE standard protocol for Building Automation Controls
network (BACnet) continues to gain market share in building systems
connectivity. However, problems arise when trying to implement
this building control protocol for multiple (i.e. enterprise)
buildings for which much better proven web services standards
exist.
Products based on platforms such as BACnet/IP are being sold
as IP enabled solutions which can provide a way to network numerous
buildings across the network. However, there are two basic issues
which pose a fundamental problem with this architecture: security
and scalability.
BACnet/IP security, even when employed, is considered fundamentally
"weak". To bring the security to acceptable levels,
additional, more general IT solutions must be applied. The extra
equipment (such as VPN's) essentially constitutes a "gateway"
which is confined to security functions. Keeping the BACnet/IP
network confined to situations that does not put it in harm's
way and therefore avoids exposure to security pitfalls create
added expense and performance penalties.
Use of "data concentrator" type devices (RZ Mediator)
to gateway and/or proxy between the protected buildings systems
that use proven "off the shelf" tools, such as SSL,
TLS or HTTP Authentication, are more suited for the business IT
environment.
While BACnet/IP is a building control network of choice inside
a building or small campus, it is not nearly as suitable for Wide
Area Network deployments for a number of reasons; security, robustness,
media speed differences (MSTP vs. IP), flat device ID name space,
and broadcast message cascades.
While some devices have implemented the optional BACnet/IP security
features, it is far from common. The BACnet/IP security features
only work for confirmed messages (not unconfirmed or broadcast
messages) and brings with it the management of credentials for
a potentially overwhelming number of devices if taken down to
the device level. A Key Server device is required and message
throughput drops. For more information please read the attached
BACnet Wide Are Network Security Threat Assessment written by
the National Technical Information Service (NTIS); http://www.fire.nist.gov/bfrlpubs/build03/art034.html.
This technical report addresses inter-networked building automation
and control systems using the BACnet/IP protocol. The report deals
with threats from known sources due to communication connections
to the corporate LAN and the public internet as well as physical
threats to the building automation equipment and attached computers.
The objective is to have a document that summarizes the threats
toward and weaknesses of a BACnet/IP network.
BACnet/IP (and Ethernet/MSTP) assumes a more responsive dedicated
underlying network than is present on the Internet. Timing between
retries and lack of notification of failures are not typically
suited for the range of delays and uncertainty that exists over
the Internet. Therefore, BACnet/IP installations are not robust.
BACnet/IP networks typically include a variety of media and throughput
capacities. The lack of awareness of the capacities involved in
a network path can lead to saturation of slower segments (such
as MSTP saturation).
While BACnet points are organized in a Device->Object->Property
hierarchy, no such organization is present at the device level
for management of ID numbers. All ID numbers on a BACnet internet
work must be unique thus the flat device ID name space is limited.
BACnet/IP makes use of broadcast messages for various services.
Lack of care in the setup of BBMD devices and the inability to
control the broadcast behavior of many devices can crash large
BACnet/IP systems. This can lead to the decommissioning of BBMD
devices which forces other solutions to discovery and elaboration
of devices on the network.
Network Address Translation (NAT) firewalls are common place
and create additional complexity for BACnet/IP systems. While
recent additions to BACnet/IP to accommodate NAT firewalls are
currently under review, they call for greater, not less, difficulty
in setting up a BACnet/IP network that spans one or more NAT isolated
subnets.
Recognition of these issues with BACnet/IP and other building
automation networks, as well as a desire to provide a way to ease
the interface to business software applications has lead to the
development of various solutions. BACnet/WS (Web Services) and
oBix are examples of two such solutions. While attempting to be
broad enough in conception to allow its application to other network
technologies, such as LonWorks, BACnet/WS is focused primarily,
by necessity on BACnet networks. oBix, on the other hand, represents
a much broader and more extensible approach, but neither have
yet achieved market acceptance. The RZ Mediator Framework provides
a more general solution that is not focused on one particular
building automation protocol. By embracing the standards and technology
of the Internet and approaching this challenge with Open Source
solutions and its powerful Multi-Protocol eXchange (MPX) platform,
building owners and facility managers have the ability to embrace
the diversity found within buildings and provide a future-proof
integration infrastructure. With an MPX platform, all points within
the framework are identified by a unique identifier (URI) and
all information can be presented in common formats, such as HTML,
SOAP or XML-RPC, and a number of other parties are able to securely
consume and manipulate this information. These different parties
might include both operations staff performing diagnostics and
executives examining customer reports via their browser. These
benefits are also extended to value add service providers that
specialize in specific areas such as Intelligent Building Systems
(IBS) infrastructure, building systems analytics, Automated Fault
Detection and Diagnostics (AFDD), Automated Demand Response (ADR),
predictive maintenance, renewable energy solutions and the intelligent
power grid.
|
