During the week of July 17th, I attended and spoke at the “Business Opportunities Gateway Forum – Electrical Power and Energy” which was held in Vilnius and organized by the Society of Electrical and Electronic Engineers in Israel. I looked forward to this event for the opportunity to spend some time with engineers and talk about critical infrastructure protection. It was also a good chance to see all the ideas on smart energy coming from the start-up companies in Israel and Lithuania represented there.
One of the panel discussions was titled “Smart Energy Systems” and will limit my remarks to the presentations that took place during this panel.
“Smart” with the help of IT and Telecommunications —
- “smart grids”
- “smart meters”
- “smart lighting”
- “smart cities”
was the dominant theme of this panel. Hearing about the applications and possibilities of these new technologies was quite exciting. Was pleased to learn that in the city where I live the application of these technologies (smart street lights) had already begun. However what began to bother me was the attention being given to insuring the security and safety of this new technology.
I began to write down short quotes from the presenters and began to notice a disturbing pattern. The first quote from a presenter that stuck in my mind was in his describing the new technology as being with “no vulnerability”. Other words used in the presentations describing the new innovative technologies being applied were —
- “Long wave [providing] connectivity anywhere” (for broadcast messaging, immediate access to intelligent devices)
- “secure IP smart grid solution”
- “going to fully decentralized”
- “communicating with meters with control capabilities”
- “cell modems”
- “IEC 61xxx” standards (but no mention of ISA/IEC 62443)
- and use of TLS (transmission layer security) to insure secure connections
TLS was especially emphasized as a guarantee of security which aroused my suspicion. I did a quick Google search and found many articles about TLS being hacked.
The attention being given to insuring the security and safety of these products seemed too light headed.
The next two phrases I recorded were the about the features of the new smart grid technologies that provide for “remote disconnection of the consumer” and “remote update of firmware”. The apparent lack of attention being given to security was becoming very worrying. At the end of the session there was very little time given to questions from the audience but managed to raise my hand first and made a statement and recommendation to the panel —
I am not happy with the way security is being discussed here. The possibilities of the new technology are being presented in glowing terms but some attention should be given to the darker side. It would seem that there are no vulnerabilities yet I heard two mentioned which could be used by a malicious actor. The first is the remote disconnection of a customer and the second is the remote upgrade of firmware. We have witnessed two malicious applications of these features on December 23rd.
In Ukraine when substations were remotely disconnected and when the firmware belonging to communications equipment used to communicate with the electric grid [substations] was overwritten. I would propose that in addition to the testing for compliance with regulations and standards that have been mentioned an additional test is conducted with a “red team” to evaluate the security and safety of these new products you are putting out to market.
What I noticed at this conference was further confirmation of a tendency seen in other industries to put out a product first and think about security later. The pressure on technology companies coming from a need to get a fast return on investments made in resources and time tends to push security lower on the list of design priorities. Two examples illustrate this. Microsoft Windows was out in the market for many years before Bill Gates’s famous Email in 2002 that called for a greater emphasis on security . Security came after the product was designed and shipped to the public. Security was added later but much time and effort would perhaps have been saved had the security been put in the design right from the beginning. What we are left with is still buggy software with a “Patch Tuesday” every month where the latest discovered software bugs are addressed and the consumer patiently waits for his computer to install the new fixes. The other example is found in the automobile industry. Last summer we heard of the successful hacks demonstrated in taking control of some of the critical functions (steering, brakes) of the new “smart cars” . The automobile industry apparently has just had its “Bill Gates email” moment. Today I read of the automobile industry coming out (published on July 21, 2016) with an “Automotive Cybersecurity Best Practices” guide. Now older cars will perhaps get new software security “patches”.
It is a good time to pause and re-think what we are doing before we install more systems that could make us more dependent on increasingly pervasive technologies. A “smart city” sounds wonderful but if there is some systemic failure (from a simple power blackout) that same city can become a dangerous trap for its inhabitants. Some way must be found to balance the need to put out a product to market ASAP with the need to insure that the product is secure and safe to use by the consumer. The same can be applied to manufacturers selling the latest greatest high tech products to operators of critical infrastructure. Standards and emphasis on compliance with mandatory regulations are not enough. Perhaps inviting a “red team” to participate in the design and testing process can reduce the need for “patch Tuesdays” in equipment used in our critical infrastructures before it is installed?