The Building Automation Middleware Project

The Building Automation Middleware Project

BAM Team[1]

Introduction

Building Automation Systems (BASs) provide new opportunities for convenient and efficient facilities management through the use of computer network control. Such systems are commonly used to manage functions like HVAC, lighting, surveillance, and door locks through a dedicated network connected to a central control system. Existing systems rely heavily on isolation for their security, but this reliance limits the types of applications that can exploit the BAS capabilities. In particular, it limits the ability of building users (as opposed to administrators) to use the BAS for their own purposes, limits the ability to integrate BAS functions with enterprise systems, and places a greater burden on building administrators by relying on their direct involvement for almost all functions. Relaxing these limits introduces challenges for security and integration, however, as opening the system increases its attack surface and the most useful functions of the BAS require reliable interoperation with legacy enterprise systems. The UIUC Building Automation Middleware (BAM) Project aims to address these problems by developing new technologies for secure middleware for BASs. The project pursues both fundamental scientific advances and practical case studies. This BAM position paper outlines the scientific objectives, the practical case studies, and the plans for the case studies.

Scientific Objectives

The project aims to explore three areas that require more advanced scientific techniques for BAM. These are perimeter control, audit and intrusion detection, and privacy and insider threat mitigation.

Perimeter Control. Since BASs often rely on isolation for the security of individual devices in the control system, there is a need to protect these devices behind a suitable perimeter and gateway when opening them to enterprise systems or the Internet. We aim to explore a system for doing this with a pair of architectural elements that communicate via a high-level interface based on oBIX. The application server will hold application software but it must communicate through a control network gateway server to execute actions on the BAS control network. In particular, the application server will prepare credentials for authenticating requests but these must be double-checked by the gateway to limit the damage that could be caused by a compromised application server.

Audit and Intrusion Detection. One of the main reasons that control systems are not more extensively connected to the Internet is the value of the resources they offer. An attack on a BAS might be used for theft, such as sending a command to open all doors so that physical assets can be removed, or for violations of privacy, such as tapping into video feeds from surveillance cameras. While one can deploy audit and intrusion detection systems on elements like the application server using COTs systems that can improve security, some of the most interesting opportunities in this area lies in developing systems that are domain-specific and can operate at a low level in the control system, thus providing information that would be very difficult to circumvent. We aim to develop a system to translate between such low-level monitoring and high-level events that would be meaningful to a building manager.

Privacy and Insider Threats. One of the features of new BASs is the amount of detailed data they provide about building users and the degree to which they concentrate power over this data in the hands of administrators. On the one hand, building users can benefit from more discretionary control over data that pertains to them; On the other hand, there are benefits to limiting the access of parties to BAS data such as surveillance videos and BAS functions to minimize losses from system compromises and insider abuses. We are pursuing projects on both of these directions. One line of inquiry concerns enabling users to aid workflow by exercising discretionary control over a location information service; another line of inquiry concerns “video redaction” in which sensitive data on videos is encrypted so that information can be more precisely controlled. For example, we can show how to encrypt faces of subjects in videos so they can be revealed only if there is a reason, such as evidence of a crime by the redacted subject.

Practical Case Studies

We plan a case study for two applications with respect to the SiebelCenter, a 225,000 square foot office building that houses the UIUC Computer Science Department that was built in 2004 and uses the Andover Continuum System for its BAS. The two applications were chosen to be ones that benefit a broad range of stake holders (viz. both building users and administrators), exhibit modest complexity, and strike a balance between being risky and being interesting.

Delegated Access. One of the major activities of the building managers is to ensure that building users get proper access to the rooms that they need to use. In the university environment, room permission is transient, so as a result, the building managers are spending a lot of time adding and removing room access to different persons. This motivates the scenario for delegated access. There are many rooms in the building for which one could assign a “manager” that isn’t the building manager. The delegated access system would allow building managers to assign rights to room managers that allow room managers to make the access list for a room. As an example, imagine that Joe runs the lab in room B and needs to give his student Sally access to the room. In the current system, to get access to the room, Sally may send an e-mail to the building manager, Bill, who subsequently e-mails Joe to ensure that Sally should indeed have access. After receiving confirmation from Joe, Bill will then give Sally access to the room, followed by an e-mail to Sally tells her that her access rights have been updated. If the system had delegated access this scenario would play out as follows. Bill would give Joe rights to manage the access list for room B. When Sally needs access she would simply ask Joe who would subsequently log into the Delegated Access System and add Sally to the access list. This addition would be audited. Once the change has been made, Sally, Joe, and Bill would receive e-mail notification of the change and Sally would have access to the room.

Mobile Access. A common problem in a building (with or without real keys) is that people forget their keys. When this occurs they need to be issued a temporary key by the building manager. The mobile access case study is designed to mitigate this problem. The mobile access scenario would allow users to connect to a system either over the web or with an application on their cell phone and request that their door is unlocked. Currently, if a user, Fran, forgets her key she must visit the building manager who will issue her a physical temporary key. With the mobile access scenario, Fran could simply log into a computer and request that her door is open, or she could run a small application on her cell phone that would send a command to open her door. As with the delegated access system, actions through the mobile access system would be closely audited for suspicious behavior to ensure that there are no attacks that could potentially result in physical damage to the building.

Plan

We plan a development of the practical case studies in four phases.

Phase 1. In the first phase we plan to design the system and implement the two case studies on a test bed for the Andover Continuum System. With this test bed, we can simulate a building with 2 doors and up to 2 ‘areas’. Each door accepts a different kind of access card, one accepting swipe cards and on accepting proximity cards. One of the ‘areas’ is equipped with a motion sensor. The system is capable of handling any number of users, however, for the time being we currently have 4 users. The test bed is in a stand alone configuration, therefore there is only one management console connecting to the system. The test bed is only able to simulate the access control functions of the Andover Continuum System.

Phase 2. In the second phase we would like to deploy the delegated access system to a few trial doors in the SiebelCenter itself.

Phase 3. In the third phase we would like to complete two tasks. First, we would like to deploy the delegated access system for general use in the SiebelCenter. Second, we would like to deploy the mobile access application for use on a few doors in the SiebelCenter.

Phase 4. In the fourth phase we would like to deploy the mobile access application.

[1] Carl A. Gunter ( is the point of contact for BAM. Other team members are Nikita Borisov, Jodie P. Boyer, Ragib Hasan, Lars Olson, Dave Raila, Teresa Schurg, and Chuck Thompson.