Think Outside the Plant: Building Control Systems!
While most of the focus on securing control systems has been in industrial settings, not much work has been done yet “closer to the home,” or at least the office.
Building automation systems — those applications, devices, and protocols that are used to control and monitor HVAC, lighting, energy management, and sometimes fire and physical security systems — suffer from many of same issues we’ve seen in SCADA: inherently insecure protocols and devices, patching problems, and “organizational challenges.” Oh, and our friends OPC and Modbus are also widely used in this space, although BACNet seems the most widely used standards based protocol.
One key difference, at least in my experience, has been that these devices are often directly connected to the campus networks, sometimes on the same VLAN as corporate desktops and printers, making it difficult to define and enforce a strong security perimeter with a single access control device. There also seems to be more interest in direct Internet access to building control systems than with SCADA, DCS, or PLC networks.
In terms of security research, the bulk of the work has been conducted by NIST Building and Fire Research Lab who published a nice BACNet threat analysis back in 2003, but there is definitely more work to be done in defining the security problem space and developing possible solutions.
Stay tuned!
Author: Matt Franz
Posted: December 29th, 2005 under Uncategorized.
Comments: 2
Comments
Comment from Dale Peterson
Time: December 29, 2005, 1:12 pm
Building automation system security is interesting on its own, but they also can have a big impact on control systems for oil/gas, water, electric, etc.
It is easy to imagine blended threats that combine physical attacks and cyber attacks on building automation systems. Taking this a step further, a blended threat could combine physical attacks, cyber attacks on building automation systems, and the end goal of bringing down a critical infrastructure control system.
Comment from Anonymous
Time: December 30, 2005, 6:34 pm
A few observations from a recent implementation of a building control system…
The access control hardware seemed to have a solid focus on security, with encrypted serial connections and countermeasures to detect tampering. This was the sales focus was on the secureness of the solution.
The server software is MS Windows-based, requires a domain controller, and Microsoft SQL server.
Both the vendor and integrator strongly advocated connecting this server to the corporate LAN for remote terminal access and automated reporting. They also advocated opening up the security LAN for wireless LAN extensions.
We found so many things wrong with the suggested server solution.
The client application required domain administrator privileges for the security badge administrator to so some things, such as changing settings on an access controller or a badge printer. The contractors who set up this system required these domain administrator privileges to troubleshoot and complete the installation.
The biggest mistake would have been a connection to the corporate LAN. This would have allowed a path for cyber problems to impact the physical access control. If this was connected as recommended these users would have administrator privileges to all servers and clients on the corporate LAN! We kept the security LAN isolated.
There are also the common (but still serious) vulnerabilities with Windows, SQL server, and wireless LANS.
It was amazing that a security vendor who focused so much on physical security carelessly subverted its own solution with cyber security problems. The vendor expressed no serious interest in changing their solution or recommendations to address these issues. They view it as a matter of preference for the customer.
Write a comment