Cyborg Beetles, Cyber-security, Smart Buildings, and the Smart Grid

Cyber beetles provide an interesting glimpse into agent based interactions. Smart grids and smart buildings are integrated today using deep, integration, and complete control of the underlying processes. As more and more nodes are added to any system, the overhead of maintaining all interactions at a central point becomes more significant. In grid-scale systems, system designers have managed complexity by limiting diversity; a system may be managing ten thousand substations, but at least they are identical systems. A current DARPA project dramatically demonstrates a better approach.

At a recent IEEE meeting in Italy, Michel Maharbiz of the University of California demonstrated his Cyborg Beetle. His team has implanted electrodes in a giant flower beetle and mounted a wireless receiver on its back. The team is able to cause the beetle to take off, to hover, to turn left and right, and to land. Someday, a system like this may be used for surveillance or to guide rescue operations.

The beauty of the system is its simplicity. It uses an off-the-shelf wireless receiver. The signals sent to the beetle are very simple. The beetle performs all complex acts without requiring direct control. The biggest challenge is placing the electrodes. The interface consists of six electrodes implanted in the basal nodes of the flight muscles and in its optic lobes.

The beetle is arrives able to maintain its equilibrium. It comes able to synchronize its muscles to maintain efficient flight. The system uses the minimum signals needed to make the beetle do so. Like scratching a dog on the side to get that hind leg going, the cyborg beetle gets an itch to fly and takes off. Because the messages are so insignificant, this approach saves battery life as well programming complexity.

The beetle has evolved for efficient flight and balance. A core principle of ecology is that the most intense competition is always intra-niche competition. Beetles compete with other beetles, and compete most intensely with beetles that seek the same food, and live in the same place. This is a good model for the smart grid and for smart building interactions.

We want the most rapid development we can get for each of the nodes of the smart grid, and for each of the technologies of smart energy. To get this rapid development, we must put these technologies in direct intra-niche competition, and not allow competition to be lessened by large product lines or entrenched systems.

We can do this by limiting the control and integration we use between each node on the grid. We must eschew deep integration and direct control of the processes of each substation. Just as the Cyborg Beetle operators leave flying to the evolved processes, we should leave substation operation to the substation, and home device operation to the home devices. We want a rich, diverse ecosystem of energy strategies, an ecosystem with intense competition.

Control of the Beetle is limited to deciding whether to hover or to land, to turn left or to turn right. The beetle knows how to fly, and how to land. A beetle that will not fly can be replaced. That’s how it should be in the smart grid and in the smart building and home. Let the node take care of security. Let the node take care of operations.

You can watch the flight of the Beetle at MIT Technology Review Multimedia (http://www.technologyreview.com/video/?vid=217)

Cyber Security for the Grid

SCADA security, often called cyber-security when talking of the smart grid, is one of the areas where not only the answers are difficult, but often selecting the right questions is difficult. Supervisory Control And Data Acquisition (SCADA) refers to the on-line, computer-based monitoring and control of process from a central site. SCADA, which puts little intelligence into the distributed points, is still the primary model used for utility distribution systems, including the telemetry and operation of today’s dumb grid.

The SCADA model of systems architecture was appropriate when we were building monolithic systems using the very expensive minicomputer and networking was in its infancy. This led to the then obvious decision that the system has exactly one controller. Two systems sharing data was an unacceptable hindrance and bottleneck on process control. Large monolithic systems are expensive to install, expensive to update, impossible to partially upgrade, and do not imagine a need for inter-component security, any more than I imagine security between my arm and my leg. Every integration between two systems was detail oriented and required exposure of every detail, no matter how unimportant.

Distributed inexpensive systems are the rule today. Systems with full security and mutual authentication between every node are still orders of magnitude faster and cheaper than the old systems. Communications are orders of magnitude faster. Almost all of the constraints about how things needed to be done are now no longer true.

For too many control systems, the old models still apply. I spend a lot of time in the somewhat less critical building systems space. Nearly every vendor in that area prices an enterprise controller so that we will buy only one, and that one talks to all. Integrations are excruciatingly slow. The vendor, knowing he will only sell a few of these, prices them accordingly.

Before we built our Enterprise Building Management System (EBMS), we had multiple conversations with BAS vendors about installing multiple enterprise controllers rather than one. The incremental cost of the bits would have cost them nothing. I understand their need to get, say, a quarter million dollars per site. I just wanted my site to consist of 20 peers rather than a single master. They believe that 20 peers should cost 20 times a single system for the site. This was a marketing decision, not a technical decision, and it was a bad one.

We went to a distributed approach for EBMS (just search the archives), something that looks nothing like the approaches of SCADA. I can now upgrade parts of the infrastructure by replacing a single autonomous system agent in a single location. The deep intimacy that old integrations required is gone, and the reliability and resilience of the system is improved. This means it is possible for me to roll out incremental security fixes, or even system agents from a different platform, without spending years and re-training all.

I’ve heard a lot of scary, scary things when discussing SCADA. "Our system is so large and complex you may not comment on it until you have studied it for years" (So your system would fail if key plant engineers got hit by a bus going to a birthday lunch. That is yet another security problem). "Our system is so exceptional that it cannot share account management with the corporate HR systems." (So the business process to turn off remote access to these systems is too convoluted to occur in a timely manner). Recently, I have listened as SCADA engineers have railed against security researchers who expose security holes. "Our system is so unwieldy that we cannot respond to identified security holes in a timely manner." This attitude is dangerous for smart buildings and for the smart grid.

Security is about being able to do the right thing at the right time when requested by the right person. Denying access is just the most trivial part of that. Security is knowing whether to trust inputs received from others. Security is self detection of configuration changes, i.e., awareness of system integrity. Until smart buildings and the smart grid come to this fuller awareness of security, they will be too immature to interact.

Nuclear Zombies and the Smart Grid

Today I’m thinking about the unconventional security problems of the smart grid. This means that I am considering the special issues of widely dispersed intelligent devices. I am also becoming the 1,142^nd blogger to write about the newly recognized zombie menace in Texas.

Widely distributed assets cannot be entirely protected against direct physical access. If responsibility for the distributed assets is distributed as well, as they would be in Distributed Generation (DG) and Net Zero Energy (NZE) scenarios, then it is foolish to act as if one can. (DG refers having dedicated power plants spread across the grid. DG as associated with alternative energy, wherein assets should be arrayed “wherever the wind blows”. DG facilities are also much more likely to be owned and operated by people who do not work for traditional power companies. NZE puts DG into each and every building. NZE buildings generate when they can, store as they are able, sell to the grid when the price is right, and buy from the grid when they must.)Zombies come to Texas

This week there was a widely reported hack of a distributed asset—a traffic sign in Texas. Such systems have minimal security, and may be deployed into the field with the default password still in place. If you have access to the sign, it is usually no more than a few minutes work to perform a hard reset and restore the default password. This is usually true for any system; if I have unfettered physical access, the system is sooner or later mine. In Texas this week, a highway sign was hacked to warn of “Zombies Ahead”.

In circumstances like this, it is more essential to be able to determine if the configuration has changed, than it is to make the system un-assailable. Should mutual authentication, and mutual trust include mutual configuration checking?

An entirely different aspect of smart grid security, or perhaps survivability is also on my mind this week.

There are many concerns that at least one US city will be subjected to an EMF pulse in the years ahead. EMF (electromagnetic force) pulse refers to the large power that follows a nuclear blast. Enhanced EMF weapons funnel more energy into EMF than into blast. Enhanced EMF is generally considered an electronics killer. AN EMF pulse could destroy navigation and communications and data centers and home computers. An EMF pulse could take out the internet. When we have a smart grid, then an EMF pulse can take out the substations and metering infrastructure.

Security includes survivability. Most definitions of security describe graceful degradation rather than catastrophic failure. After an EMF pulse, systems would have to fail to some sort of default configuration that still worked, even if minimally. This default configuration, though, might break the trust described above.

How will the smart grid handle nuclear zombies?

The Sound of Breaking Glass

I love the sound of breaking glass
Deep into the night
I Iove the work on it can do
Oh a change of mind
Oh change of mind, sound of breaking glass
All around, sound of breaking glass
Nothing new, sound of breaking glass

Nick Lowe

Security in the built world is most critical at precisely those times when the demands for performance and interaction are greatest. Buildings may lose their communications with the outside world when partially destroyed. The power grid may require ad hoc reconfiguration when its communication lines are down.

The built world traditionally has found security in isolation. Building Control Systems are isolated in a mechanical room and not plugged to the internet. Fire system annunciators are often limited to one-way communications. Access is often all or nothing, with many systems secured only with the default account and password from the manufacturer.

If a system is all or nothing, then it has little need for nuanced identity management. In traditional building monitoring systems, pretty graphics sell the system, but operators look primarily at tables of values. Without service definitions, the systems rely on operator knowledge to put the pieces together. Without service definitions, monolithic security is the only choice.

Considering the requirements of using building systems for situation awareness during emergency response can lead to the wrong conclusions. The mind leaps to all-out conflagration, wherein all security should be cast aside to allow the fire department unfettered access. Yet emergency response also includes the arrest of the lurker on the third floor, and the minor spill of chemicals in the manufacturing wing, and the ambulance responding to the heart attack in the secured executive suite. In many scenarios, the responder will be granted limited access, for limited times, to only a portion the available sensors and surveillance cameras.

Power systems have different requirements for emergency security. The intelligent grid will both support and require reconfiguration more readily than it does today. Distributed generation raises the real possibility that both sides of a downed power line are hot, increasing safety risks during emergency repairs. Improper interactions with the downstream systems can incur liabilities for equipment damage, equipment not owned by the utility and not professionally monitored.

Infrastructure emergencies often coincide with reduced communications. Reduced communications can disable federated identity management, or even single provider single password checking. Many systems handle this problem with forward caching; user accounts and identity tokens (passwords, biometrics, et al.) at the access point. For example, a campus access control system might forward cache the keys of all residents of a dorm, enabling the door to make mostly correct decisions even when disconnected.

Forward caching fails at precisely those times when the emergency is greatest. During the night with four fires, the fire department from the next county responds to the building. After the great ice storm, line crews from three states away are restoring the substation. During the worst fire, the battery in the incident commander’s PDA fails, and he switches to an unregistered device. The tightest, best security fails when you need it most.

Medical systems define what is called a “Break Glass” incident. Break Glass might rely on a standard account and password, one that might never change. By using the Break Glass password, the system is alerted to log fully every action taken. Break Glass incidents also trigger an audit alert. Post incident audit might require, for example, an explanation of the event, as well as an administrative review of all changes made to the system.

I think both building systems and energy systems, including SCADA for Transmission and Distribution can make use of the practice of Breaking Glass.