One of my favorite conference speakers has to be Robert Former of Itron. Robert is the in-house penetration tester at Itron. He is paid to break things, and it is a job he thoroughly enjoys. Like many vulnerability testers, he is essentially a no nonsense guy that shoots from the hip. If you ask Robert a question about security, you are likely to get a very practical (and honest) answer.
One of the comments Robert has made (on more than one occasion) is that AMI vendors deliver what their customers ask for. Early deployments of Smart Meters lacked many of the security features of today's Smart Meters for two reasons. One reason was that many of the security concerns we face today simply did not exist in our conscience back then. Sure, some will argue that we should have known better, and we should have learned our lesson from blah blah blah, but the reality of how we deal with security is only partially pro-active. Think about this for a moment. You are not going to walk about town in a bulletproof vest until you realize that there are bullets flying. You may take a few precautions if you hear news of some people getting shot, but barricading yourself in body armor is not likely unless you are living in a war zone.
So with AMI, despite all the glorious hype we sometimes see, rest assured we are nowhere near a war zone. Yes, there have been a few shots fired over the bow, but I have yet to hear of any casualties (or, for that matter, any injuries whatsoever).
The other reason why early meters lacked security found in today's meters is because utilities simply did not demand it. Utilities wanted (and still want) inexpensive, reliable, and easy to manage meters. Adding security to a meter can directly impact all three of these criteria. Early deployments were focused on just getting everything to work, and many still are.
Yet we live and we learn...or so we hope. The fact is that utilities are now keenly aware of the need for security, and they are now beginning to demand it from vendors.
However, this is not necessarily working out as well as it should.
I have had conversations with several vendors who have told me that some potential customers have essentially copied and pasted the entire NIST IR 7628 final report (which is 3 volumes) and said something akin to "do this" to their vendors. As someone who is currently working on developing testing and certification guidelines for Smart Grid security as part of the NIST Testing and Certification CSWG working sub-group, I can assure you that this is not a good idea. This is like handing a copy of "Larousse Gastronomique" to a caterer and saying "cook this".
Knowing what to ask for is crucially important for a utility. Without some type of guidance, utilities are not going to be very effective at making demands. In fact, without knowledge of what they ask for, utilities are likely to accept anything they are given as a response to their demands. I mean, how are they going to verify anything anyway?
The work being done in OpenSG is seeking to rectify this. There are a number of prominent utilities working in OpenSG, but the majority of utilities in the USA are not active members of OpenSG. There is a wealth of information available to anyone who wants it, and anyone (utility or not) can participate in the work. By educating themselves about security, utilities can create RFP's in an informed manner, and they can also take advantage of the tools and people available to help them verify that they are getting what they demand. Getting involved is easy. Send an email to darren@utilisec.org (who is the current chair), or Bobby@enernex.com (the current co-chair) and you will be on your way.
The answers are out there.
1 comment:
A good starting point might be to google the phrase "cyber security procurement language".
Post a Comment