Friday, March 18, 2011

Right Idea, Wrong Platform...

Okay, I can't help sharing this.  A quick search on Facebook reveals that there are 3 different groups there with concerns about Smart Meter data privacy.  One of them is completely open.

Really?  Are you sure you want to use Facebook to build your privacy advocacy group?

I mean, I understand about privacy concerns, that's why I'm involved in the privacy work on Smart Grid (among other areas.)  Addressing those concerns is critical.  I've said so elsewhere.

But if you are really a privacy advocate getting those concerns addressed means rolling up your sleeves, and helping with the real business discussions where standards and business practices are being established, not flapping around Facebook with a bucketful of speculation and little credibility. 

(Sorry, but using a platform created by the guy who called people who "trust me" "Dumb ****s" does not enhance one's credibility as a privacy expert.)

Really, those of us working on this stuff could use some help.  All we ask is that you come willing to do two things;
  • listen to what is already being done to resolve the potential problem, and 
  • help us do it better.

Thursday, March 3, 2011

Smart Grid Security East, Day 2

Still getting caught up on e-mails after Smart Grid Security East.  I was hoping to update things from the conference site, but with moderating two panels and networking, I got behind the curve.

So not as much from the second day, but I'll update this as I get a chance to review the conference session videos.

Panel of Security Solutions Vendors
Interesting comments: Most threats are insiders. 
(I'm not sure about that, but clearly most successful attacks are insider.  One defence against both insider and outsider threats:  Before executing a command, the system needs to ask "Does the command make sense?")

Interesting to hear security vendors name the meter manufacturers they're working with. Who's not on the “we're secure” list?

You may have an interoperability standard, but without the ability to enforce interoperability, you don't have anything. It becomes interoperability in theory only.

At one point, commenting on how long the standards process takes (and it is admittedly a long painful process), Mike Ahmadi compared the standards process to the food service industry, noting that food service is all about “there are people here, make food now.”   

Based on that comparison, I'd say that the Smart Grid standards process is the Iron Chef of standards processes;
  • There's not enough time,
  • You don't know what you'll have to work with, and
  • When you're done, people who weren't involved in the process will judge the result.

A great comment from Annabelle Lee's keynote: "If you're not failing, you aren't doing R&D."

From the DOE, FERC, NERC Panel on the Energy Grid Risk Management Process
William J.Hunteman of DOE commented that the goal is the development of a 
risk management process, not a risk management “howto.”  He also commented on the need for a greater utility representation.

As I said, more later after I've had a chance to catch up on the video from parts I missed.

All in all, this was an outstanding conference, with the top people in the field discussing how they see the world of Smart Grid Security.  

We need more conferences like this.

Will Smart Grid need a Carterfone decision?

Anybody remember the days before the AT&T breakup?

How about the days (before that) when you had to lease a special "protective device" from MaBell if you were going to hook up something?  Or the time before that when you just plain couldn't get anything but Ma Bell equipment?

Just a bit over 42 years ago, the FCC told the phone companies that they couldn't have absolute control of what got hooked to their network, and set standards for what could be hooked to the phone network.  While it still took a while to bear fruit, that was the beginning of the process that got us to the anywhere / anytime connectivity that we have generally gotten used to.

While some very talented people have been working hard at interoperability, I hear a lot of talk (and have read a few use cases) that indicate that at least some parties think that if the utility doesn't exercise control over the devices on the customer side of the meter, there is a threat to the reliability of the grid.

Think about that for just a hot second.  The existing grid doesn't need that kind of control of end-user devices, so why should a more intelligent and adaptable grid need it?

Now, I can see an argument for direct control of customer owned generation and storage, perhaps.  I can also see ways that it seems to me the same job could be done without it, and I suspect that if we don't design in that kind of flexibility now, it will be required of the grid later, and require some expen$ive re-engineering.

I invite comment and thought...

Tuesday, March 1, 2011

Thoughts from Smart Grid Security East

Thoughts from Smart Grid Security East...
Note: I'm not naming names here, because (a) some of these honest comments could get people in trouble back in the office, (b) I recognize that these comments are out-of context and paraphrased, and the speaker might not have meant exactly what I heard.  
(My opinions are in italics.)

An interesting observation from a meter vendor:
Security is starting to come from meter vendors because their customers (the utilities) are insisting on it.  It is a market-driven commercial need.

His advice to consumers who are concerned about security and privacy:
  • Ignore the 'tinfoil hat brigade' in Marin County. Do your own research.
  • Ask the tough questions of your utility, and / or your PUC:
    • What data is the company gathering?
    • How long will they retain it?
    • How will they protect it?
    • Who else gets it, why and under what conditions?
 In my opinion, this will only increase as PUCs get up to speed on security and start demanding it of utilities.  PUCs, ask your utilities these questions.

The utilities need a financial reason to spend the money on security and privacy.  There is a need to educate the business professionals about the need for security. From a business standpoint, by itself, security is a negative ROI item.  You can spend money on it, and have no ROI.  In fact, if you do it right, you'll never have any ROI on it, because the ROI impact of security is a negative ROI for not doing it.
Other interesting comments overheard:

One software company rep claimed to have achieved "absolute development security."  Move over IBM and Watson.  Heck with artificial intelligence, these guys have developed artificial omniscience.

If you're interested in a good analysis of insider threats, Google the Verizon insider threat study.  (This from a former Secret Service agent.)

(From a equipment supplier) We do security testing on our competitor's products, but we don't keep our findings secret.  We call or e-mail them if we find anything.  It does me no good to hide the results of my testing on my competitor's equipment from my competitor. If I try to screw him, I screw myself.

(From another supplier on the same panel)  In other industries (finance, for example) there is a common association for sharing vulnerabilities and certification processes. That needs to be done for Smart Grid. It is happening to some extent organically, but it needs to happen intentionally.

Equipment vendors are doing what they can, but the buyers need to be held accountable for secure implementations. True in part, but the buyers are dependent on the vendors to tell them how to secure the implementations.  The components have to be secure, but so do the combinations of components, and the operations and systems they interact with.

The problem of long lifespans of security-related equipment.  The ability to upgrade field equipment remotely is critical.  For example, in residential meters, a truck roll to upgrade a meter may cost more than the device.

The appliance vendors still may not have come completely to terms with the need for a software upgrade path.   How do you upgrade a refrigerator's firmware?  Appliance upgrades are not likely to be allowed to come through the Utility AMI network. 

Meter vendors have to treat whatever is on the customer side as inherently hostile. They do not know whether the equipment is currently patched, so they must limit what data can come from the customer side of the meter to that which is absolutely necessary.

From a security standpoint, passing “content” (consumer information, appliance firmware or consumer instructions) either way over a “control” network is a bad idea, particularly if equipment on the customer side of the meter is passing commands to (or through) the meter.  It creates too much opportunity for an attack vector.
This makes “prices to devices” a far more viable option from a security standpoint.  For example, if;
  • the utility broadcasts pricing information to the customer and/or the customer's equipment (via the AMI network, or through another channel), 
  • equipment on the customer side responds to that pricing information without discrete commands from the utility and
  • the utility simply reads the meter as needed,
the result is an "air gapped" communications system.  Far more secure for the utility and the customer.

All in all, a very interesting conference, and I was only there for half the day today (the morning was spent in travel mode.)
More to come tomorrow...