Since Smart Grid is a relatively new topic, the next four paragraphs will be devoted to a brief overview; Skip it if you like.

Smart Grid refers to the new generation of power grids. It is based on large networks of sensors and actuators that pass data continuously, to allow for more flexible, and more efficient, distribution of electricity.

There are many advantages to the incorporation of real-time measurement, communication and processing, to the distribution network. Distribution is made not only more efficient, but also more reliable, allowing real-time changes in electricity routing to overcome periodic instabilities in consumption. It also improves the survivability of the network in the face of conventional war or terrorism: a bomb on one tower or station, rendering it unusable, will automatically trigger routing of electricity around the dysfunctional component. Changes of routing can also occur at real-time, for optimization purposes, more efficiently matching supply to demand.

Integration with consumer equipment may allow the utility company to trigger heavy consumers of electricity on and off, given the owner allows that. For example, the washing machine may withhold its process automatically until 9pm, so to reduce the load on the network, and in turn allow the customer to enjoy lower rates. In general, direct real-time sensing of power consumption and real-time information on capacities, can trigger new business models in paying for electricity. For example, it may enable the offering of multiple rates, depending on the reliability of the supply. In this example, a customer may be offered to pay 20% less for electricity, in return for agreeing to have his power cut off for up to 2 hours each day, e.g., if the network needs to flatten a consumption peak.

Renewable energy will also be easier to exploit. Wind turbines, for example, which produce greener electricity, but with lower reliability, can integrate into the grid along with other resources, in a constellation that will be able to overcome the reliability limitations of some of its components. Distributed manufacturing also assists in cheaper power distribution, and allows private owners of electricity generation facilities to sell electricity back into the grid, encouraging the exploitation of renewable energy.


Concerns emerge when security considerations comes to play. As I mentioned earlier, a Smart Grid may actually resist bombing better. In general, peer-to-peer systems excel in survivability; this is almost always true. However, considering how we proved to be in securing complex distributed systems so far, the thought of having the most critical infrastructure being reliant on data and network technologies, does cause a shiver.

The Smart Grid, like the old grid, has a short but devastating list of enemies. First, there are the enemy states and terrorists, which I will group together for the sake of this discussion. Second, there are the individuals who may wish to hack their meters, and other equipment, for financial gain. There is also organized crime, which in terms of capabilities, sits somewhere in between. None of these opponent groups shall be underestimated. Fraud is a powerful motivator, recruiting the best minds, and so does an enemy state.

There are many factors making Smart Grid security a hard problem. It is distributed, its components are installed in hostile environments, where some attackers have access to them. Also, some of the equipment cannot be made very physically robust, because it shall remain within a tolerable price range. Lastly, whatever we do now, has to last. It is not software for which we can issue bug fixes every other Tuesday; it is equipment that needs to run for years, if not decades.


I am not aware of an overall approach for Smart Grid security. There are standards out there, such as one by NIST. These are not sufficient, however. They usually touch on aspects that are common to every distributed computer system, without addressing particular challenges of Smart Grids. Where details are addressed, these are often related to organizational aspects rather than engineering aspects. By no means do I mean to downplay the importance of organizational security requirements. These are extremely important, but I try to tackle the issue from the engineering perspective. I am yet to see a good standard that addresses the engineering aspects of Smart Grids, in a normative, prescriptive, text, at the system level.

I may never see such. A complete security framework for Smart Grids, that can be presented in concise normative text, is probably impossible to come up with. Security is all about tradeoffs, and the more complex a system is, the more complex and diverse the tradeoffs are. I tend to believe that documents such as NISTIR 7628 by the National Institute of Standards and Technology, are the best we can ever hope for.

Wherever there is no standard, there is fragmentation; and Smart Grid security is unlikely to be different. Vendors provide security features that do not necessarily interoperate with other providers’ equipment. It is hard for a purchaser to define and require support for his unique security framework, when he can barely combine components from multiple sources, and has to rely on very few vendors. The fact that the product selection criteria is so sophisticated, even with security considerations put aside, makes matters worse.

So what do we do?

Let us start with what I think cannot be done. The problem cannot be approached by the purchaser forming a specific RFP, based on pre-established definitions of specific security features. His chances of finding a product that fulfills these requirements, along with all other non-security requirements, is slim. There are just too many interoperability requirements, and too few standards, to make it all happen. This is, of course, unless a vendor came up with a complete suite that miraculously meets the purchaser’s fine-grained security requirements.

Instead, security requirements have to be put in place, but at a high level, with the burden of proof being shifted to the vendor. The requirements presented to vendors shall not discuss features and their implementation, but rather a security target, specifying attack vectors that shall be mitigated; without any mention for how. These attack vectors should be specific as well as general, such as in the form of an attack tree.

The vendor shall receive this attack tree, list the security features and properties of his product, and explain how these features and properties, in various combinations, address each node and branch of the provided attack tree. The purchaser can then judge the offering, based on the completeness of the coverage, and based on the quality of the vendor’s assessment.

This method of presenting requirements to vendors serves three purposes:

• It provides flexibility to the requirements specification. Instead of seeking a prescribed set of features, the acceptance criteria is more open-minded towards different methodologies and different approaches. When defining methods for protecting the Smart Grid, there is more than one correct answer. Insisting on his one, may change the purchaser’s situation from having a very few finalists, to having zero.

• Allowing the vendor to demonstrate his own mapping of attack tree components to his offering’s security features, will give the purchaser a chance to judge the vendor on his ability to carry out a sophisticated security analysis, rather than on his ability to follow a list of security buzzwords on an Excel sheet. After all, the purchaser is going to rely on the vendor’s security expertise for years, so determining his true analysis skills and security understanding, is highly desirable.

• Asking a vendor to provide a set of narrowly-defined security features, such as the usage of this or that encryption, the usage of this or that protocol, or the deployment of this or that protection for the meters, may make the process easier for the purchaser in the short term. Indeed, it is not too difficult to take one reference example and specify low-level requirements based on that. However, judging a product by how the vendor addresses threats, rather than by how he checks boxes next to descriptions of technicalities which he may not even understand fully, provides more reliable results. Security is in the details, but also in the overall approach, as well as in the overall understanding of the risks and the countermeasures. A check-mark next to “AES-256″ does not mean the product will resist an eavesdropper on the copper wire between the meter and the transmitter, and a check-mark next to “epoxy coating on controller” does not mean that the controller’s operation cannot be subverted. We care about mitigating threats, not about supporting features, and the closer what we measure is to what we care about — the better.

We are used to resorting to easy-to-measure numeric representations and checklists, when it comes to determining compliance with our requirements. However, when making such a tough selection in such difficult circumstances, involving so many constraints, and with so little room for making wrong choices, we might need to switch back to more thorough selection processes.