Supply Chain Security Awareness on Upswing for Energy and Comm Sectors

10/25/12 Update: Huawei just said it is ready to have all its source code tested for security. Would other vendors be so bold?

------------------

If you don't subscribe to the online version of the Wall Street Journal, you probably don't get its daily CIO feed, which provides a nice topical tapas-sized taste of what's on folk's minds every morning.

One of those folks is me, and I've been stirred up lately by all the press (The Economist, 60 Minutes, etc.) and Capitol Hill attention Chinese communications equipment maker Huawei has been getting. Personally, I haven't have any direct contact with Huawei or its products, but I have a gut-level response when a company gets pilloried solely on where it's headquartered or the nationality of the owner(s).

Smart Grid Security East and the Software Security Panel

Today I had the good fortune of being on a small panel, moderated by Matthew Carpenter, and with a representative of embedded software security provider Green Hills Software. We focused on grappling with how utilities and their suppliers are confronting application layer vulnerabilities not just in key systems, but across their entire application portfolios. Here's a summary of what I think are some of the interesting facts and other points we touched on:

• Application (or software) security is one of the newest (i.e., least mature) security sub-domains in every sector, which means utilities are not substantially further behind in this domain than some of their similarly sized, non-electric utility peers
• Large and very large utilities can have anywhere from several hundred to several thousand applications ... that they know of and track. A somewhat unsettling percentage of utilities don't know how many apps they really have. It's an often neglected form of asset management and some are working hard to figure this out. And some aren't.
• These same utilities often have one-to-two hundred developers in their internal development teams, most who have not yet been introduced to secure development principles, and with SDLC's that fail to leverage current tools that can really help
• Many utilities haven't yet formulated an application security policy, meaning, among other things: they haven't yet determined which types of software vulnerabilities add so much potential risk that they simply aren't allowed to exist in operational systems. Again, some are moving out with security policies that drive helpful behaviors in this area, but the majority (IMHO) aren't in motion yet
• I was asked what my Big Blue company is doing to help in the app sec area, and responded that we're working on three levels: (1) providing app sec training, consulting, services and tools to utilities, (2) bringing the same to vendors who supply software and software-intensive system to utilities, and (3) adding secure development processes to the SDLCs of the products we market to utilities, including those that comprise the Solutions Architecture for Energy (SAFE) framework

One point I meant to mention but didn't is that in the spirit of walk-then-run, before trying to develop policies and procedures to harden the entire application portfolio, many of the utilities we've worked with to date start at the project level with AMI and / or Customer Portal implementations. With AMI, we've seen utilities run application security tests on both the internally developed as well as vendor supplied software with good results. So good, in fact, that some of the related meter vendors, seeing the results, have procured our tools for their own internal use in their SDLCs, which again benefits the utilities when they buy these new, more secure products. And ditto for customer portal projects.

As this was a Powerpoint-free zone by design, in today's session we were just guys talking. But I've been building a short slide deck called "Securing Your Smart Grid Customer Portal" and plan to make it available, via the blog, to attendees shortly after the conference concludes. I think (and hope) you will find it helpful.

Software Security for Energy Sector Control Systems

John Cusimano has just written a great piece for anyone concerned with the software that runs energy (and other) sector control systems. It's called "Demanding Software Security Assurance" and you can read it HERE.

My own involvement in the software assurance domain is skewed towards IT and data center systems, but our work appears to intersect in a document referenced in the article. "Enhancing the Development Lifecycle to Produce Secure Software, version 2.0" was published in 2008 by the DoD's Data and Analysis Center. Here's an excerpt:

Software Assurance has emerged in response to the dramatic increases in business and mission risks that are now known to be attributable to exploitable software, including:

• Dependence on software components of systems despite their being the weakest link in those systems

• Size and complexity of software that obscures its intent and precludes exhaustive testing

• Outsourcing of software development and reliance on unvetted software supply chains

• Attack sophistication that eases exploitation of software weaknesses and vulnerabilities

• Reuse and interfacing of legacy software with newer applications in increasingly complex, disparate networked environments resulting in unintended consequences and the increase of vulnerable software targets

Asking utilities to detect and protect every weakness in every system they deploy is unrealistic. More manageable, is to ask (or better, demand) suppliers develop and deliver secure systems to their customers, especially those running components of critical national infrastructure. As Cusimano says:

It is refreshing to see a point of view that recognizes that industrial control system security is not just a problem that owners and operators of industrial facilities need to address. Of course, owners/operators are ultimately responsible for the safety and security of their facilities, but that responsibility needs to be shared with their automation equipment suppliers.

For a lighter treatment on a related subject, you can see and hear a webcast I did on Smart Grid software security last September by following this LINK. 

Smart Grid Security East: Final Reminder ... and an Offer

Here are the details for logisticians:

• Hotel: The Crowne Plaza Knoxville hotel is the site of the Conference, and it's offering discounted room rates of $99 for attendees to the conference. (Remember to specify the “Smart Grid” block or the code “IWM”) 
• Dates: Feb 28 - Training workshops, Mar 1 and 2 - Conference
• Click HERE for conference web site and HERE for $300 off the full price including workshops

And since I think this is a good deal, and nothing of value should be given away for free, I'm going to ask you a question, and the first 5 who answer it correctly can attend Smart Grid Security East for free. Ready? Here you go:

Yesterday, on Valentines evening, an IBM supercomputer named Watson and its two human competitors on Jeopardy were given the following clue by Alex Trebek in the category "Potent Potables Olympic Oddities": "It was the anatomical oddity of US gymnast George Eyser who won a gold medal on the parallel bars in 1904."

What did Watson say? Email your answer to andybochman at gmail dot com and I'll let you know if you were correct ... and fast enough.

The Harsh (Security) Reality of Old Software in the Current and Future Grid

You know I'm always advocating for getting better security awareness and process into everything we do with Smart Grid software. Whether it's developing policy, getting tools and building secure processes into the software development lifecycle (SDLC), and/or educating and arming orgs on what questions to ask software vendors re: the security rigor they include (or fail to include) in the development and integration of the products they market.

Sounds like a pretty good idea. Could make the Smart Grid and utilities' worlds and the North American grid infrastructure a whole lot safer and better, right?  

But then someone comes along and rains on my parade. And not just anyone, but a card carrying grid guru with more experience in this field than just about any other mortal. And what does he say?  This:

One must keep in mind that there will be far more poorly coded, totally untrustworthy firmware and software in the field for decades (the existing installed base) than new, more secure systems following sound development practices installed over the same time period. Dealing with this reality and the fact that the old stuff will not be ripped out should be a priority.

"Thanks" to Erich Gunther of Enernex. So, sports fans, while I and others keep beating the drum for more-secure new software, would a few of you mind getting on the challenge Erich's pointing out? Like, right away please.

New SGSB Webcast is Live

SGSB Webcast 5: Smart Grid Software Security

View more webinars from Andy Bochman.

While it's fun to think of all the great new gadgets and devices that are enabled by the Smart Grid (and that the Smart Grid enables), none of them could even begin to work without the "invisible glue" out of which the entire enterprise is being constructed: software.

As we rush to deploy Smart Meters by the millions, consumer portals, HANs and iPad applications that can communicate with them, meter data management systems (MDMS) to handle the tons of data that's generated, electric vehicles (EVs) to push local electric infrastructures to the limit, and synchrophasers across the continent to give us a better view of "the greatest engineering achievement of the 20th century", it's important to not forget about software just because we often can't see it.

Misconfiguration of software assets and (usually unintentional) vulnerabilities in code are the primary pathways hackers use to breach systems, alter their behavior and reach sensitive data. This presentation is more of a "why to" than a "how to" manual. There are plenty of the latter and I'd be happy to point you to some. But the reasons for taking on this challenge are compelling, and IMHO, need to get out.  

Enough already, here you go. It's about 17 minutes long, and you'll like it better if you make it bigger (click on "Full" icon in the lower righthand corner).

Smart Grid and V2G Weather Advisory: IBM Twitterstorm Coming

Many SGSB readers, though well versed and skilled in the ways of technology, might nevertheless say, "what the hell is a Twitterstorm?"

It's a fair question, and my simple answer is it's an online conversation and Q&A session between a bunch of folks, conducted 140 characters at a time. Maybe by haiku. This is no place for the verbose, and maybe because of that, it should be information dense and entertaining.

As the title of this post indicates, the central focus is on EVs, PHEVs and their interaction with today's grid and the emerging Smart Grid. The Smarter Planet folks at IBM are hosting it this coming Monday, September 20th, and you can see details HERE on how to join in on the fun.

Please make it if you can. No umbrella necessary.

Photo credit: LISgirl / Emily on Flickr.com

(BTW, for those of you unfamiliar with Twitter and Tweets, prior to this BTW note, this post consumed 651 characters not counting spaces. Twitter counts spaces. That's brevity.)

Dawn of a New Day? Cyber Security Attack Disclosure and Implications for US Utilities

First, a Little Anti-Alarmism
There are changes coming, but the sky is not falling. Our cyber defenses are in need of more attention and more focus, but they are generally pretty good. The Smart Grid is clearly a new chapter, and ensuring we get as much of the required security designed and deployed correctly up front will save all of us a great deal of time and trouble later on.

Software and the Smart Grid
First, Let's start by articulating something that should be obvious: The biggest difference between today’s grid and the Smart Grid is software. You may protest and say "That's crazy! The software is a small part. The Smart Grid is growing with millions of new meters, many miles of new high voltage power lines, innumerable sensors, and of course, fault current limiting superconducting transformers." There is no arguing with those additions, but, when all is said, done, and deployed, the whole system may actually lose some mass, as this IBEW video, linked to in an earlier article here, makes clear.

Now back to the software, the key enabler of the Smart Grid. Over the past 30 years, it has been what separates modern enterprises from their pre-IT ancestors by making them faster, smarter, more efficient and more flexible. However, a well-documented but unintended consequence has been that it has also made them much more vulnerable. It's not just that potential bad guys can cause harm with software tools of their own; the real downside is that even on a good, hacker-free day, a large amount of uncertainty surrounds the consistent operation of this most critical corporate ingredient.

Software Provenance and Security
Most large organizations don't know where their software came from, at least not in a comprehensive manner. Any individual application can come from one or several of the following sources:

• Internal development teams
• Outsourced development providers
• Packaged applications
• Software as a Service ( SAAS )
• Web services

From a security perspective, none of the above is necessarily more or less secure than the others. Software provenance is often quite opaque to users. Even when you buy a software from Vendor X, there's no guarantee that all the code was developed by Vendor X coders. There is usually no guarantee that the software is bug-free, that it doesn't include glaring programmatic weaknesses that make it an easy target, or even that it's not already harboring malicious code that can be triggered in the future and cause your organization and / or your customers great harm.

Approaches to securing software systems vary based on what you have to work with. Knowing where and by whom the software was built is a good start. Other factors such as access to source code, access to architects or subject matter experts who really know their way around an application can be a big help. Absent these things you'll want analysts trained and experienced in penetration (or Pen) testing, engineers whose job is to think and act like an attacker, find the easy ways into a system, tell the right folks what they've found, and often recommend hardening approaches.

Attacks on Software Source
All of this, however, is mere prologue to the story that began unfolding earlier this month related to published accounts of attacks against Google and a variety of other popular software vendors. The details are a bit sketchy, but the core elements include:

• US tech companies have recently experienced a series of very serious cyber attacks that appear to have originated in Asia
• Google admits that a couple of Gmail accounts were partially compromised
• Firms report that the apparent target of the attacks was source code relating to popular software packages

This is an interesting phenomenon, because it describes an organic growth model for further hostile behavior. The accounts of the recent attacks in the press are clear on at least two facts: that a zero-day vulnerability led to the breaches, and that source code for familiar software systems was a major target of the attacks on the multiple vendors. According to Richard Steinnon, as quoted on darkreading,

As they get more sophisticated, they are very interested in source code and ways to find new vulnerabilities in software companies' products.

So you see, one feeds the other. Zero-day vulnerabilities are very hard to find. Most popular software packages have been around for a while, and have been well wrung-out in the market. Finding something new and vulnerable in them is neither common nor simple. With the source code, however, it becomes much more straightforward. Looking from the inside out, it is like having a map to the functionality, and weaknesses are revealed that would be very hard to find just searching from the surface. The fact that one of these vulnerabilities was found and then used to steal more source code leads to a conclusion that this is a pretty well-thought-out approach. The attack has been described as sophisticated, and using its spoils to sow the seeds of future attack vectors is equally so.

The Curtain Pulls Back
The big news, however, isn't so much that these events are happening, but rather that they're being discussed so openly. According to Atlantic journalist Marc Ambinder, we have Google to thank for that:

Google's revelation that they'd been hit was deemed a "watershed" moment by security industry analysts, but the other 32 companies who were hit have not followed suit and have begged the government to keep their identities a secret. The government has no choice but to protect their identities -- even as policy encourages greater transparency about the scope of such attacks.

Two weeks ago events reached fever pitch with Secretary of State Clinton speaking out in Washington against nation-supported (if not sponsored) cyber attacks by China and Iran, among others. Basically, she's calling out a new opposition axis, only this time it's isn't an Axis of Evil, it is an Axis of Cyber Threats.

On the Cyber Defensive
In case you didn't know it, US companies and government organizations have long been victims of and targets for cyber attack. This doesn't make the US unique, by any stretch, but recent increases in the frequency of damaging attacks is surprising, given the presence of some excellent cyber security defense programs on our side, and with the increasing instances of public regulation and legislation on the topic. The main culprit appears to be the seemingly innumerable Internet connection points that present attackers with unexpected access to both flaws in software and system configuration errors. These deliver the necessary opportunities for getting to other applications and to sensitive data. With US companies, there is little recourse for companies, little ability to hit back. That's our policy. Again, Mark Ambinder:

[These are] the U.S. network security rules of engagement. Defend, don't attack.... For example, if a U.S. site comes under attack [from a foreign site], the victim -- assume it's an intelligence agency -- can defend it by trying to block the attacks, and it can offensively attempt to figure out who's behind them -- but once that threshold is crossed, it cannot attack the sites. [Most attackers] have no such rules. In fact, [some governments] teach attack techniques to a large group of state-sponsored hackers, and part of the classroom work is for them to conduct actual attacks on sites around the world, including the U.S.

US companies are only obligated to disclose the loss of customers' private information, and they don't have to be very specific about how the loss occurred, so there isn't much improvement in protection as a result of understanding how a successful attack transpired.

Take Aways for Utilities
Smart Grid initiatives are driving a huge increase in Web connectivity for utilities at this very interesting point in the evolution of cyber offense and defense. A big part of that increase comes in the form of new online energy applications and services being built by Google and dozens of start-up companies including Silver Spring Networks, GridPoint, Grid Net, Tendril and ten-year demand management veteran EnerNOC. Are all as forward minded re: security as Google? Time will tell.

We know utilities in other countries have come under cyber attack ... at least one incident induced significant outages. We also know that malicioius code has found its way onto US utility computer systems. But there's lots more we don't know and there are many questions to consider while we're still in the formative stages of the Smart Grid build out:

• Will large US utilities become targets for big cyberattacks similar to those that just hit Google?
• Will they have the defenses in place to protect customer data and maintain reliability as well as it appears Google did?
• Especially as they rely so heavily on enormous amounts of reliable, high quality power, will Google and other more mature cyber security victims be willing to share their best practices with the utility community?
• What obligations do utilities have for disclosing cyber attacks they endure, especially ones that cause tangible damage? And if they do disclose this info, to whom do they disclose it: FERC, NERC, NSA, each other, or the general public?

Despite repeated warnings from experts and the press (for example: here and here) since the Google breach headlines appeared, progress on disclosure from other affected organizations, forensics on the actual mechanisms, and informed recommendations have been slow. That must change. Utilities and their software/service providers should be pressing for information and for assistance, because this kind of data and experience can educate and invigorate utility CIOs and CISOs so that they can err on the side of over-preparation when performing security planning on behalf of their companies and their customers. Nothing could more fundamentally weaken our nation and our competitiveness than an organized and successful attack on our power infrastructure, and these incidents present an uncommon opportunity to learn.

Photo Credit: Mike Baird @ Flickr

Seriously - A Surge

A couple of weeks ago, I took a look at the data provided by the teams at PGE and Austin Energy, combined it with data provided by DOE, and I arrived at the conclusion that the Smart Grid will create a glut of information that the utilities had best begin planning for, because it could easily swamp both the utility and the networks that are expected to carry it.

Unsurprisingly, there was a fair amount of interest in both the conclusions I had reached and in the substantiation of the data I had used. Some of the inquiries were pretty straightforward. My thanks to Editor Katie Fehrenbacher from Earth2Tech for her thoughtful questioning and for introducing me to some equally reasonable experts from the IEEE.

Others were less open to the concept, and there were two main objections to the data. The first was based in existing utility practices. This line of questioning had within it the expectation that a meter read would only contain basic information about the identity of the power meter, the timestamp, and the meter reading itself. Were that the case, it would be possible that the data would be in a paltry range, around 14 bytes per read, resulting in a belief that such a small amount of data would never amount to anything like the avalanche I had described in the piece. The second objection was that there was little likelihood that such data was going to be stored for long, meaning, I guess, that we could design the system as though it had never arrived at all. Many of the questions came from individuals with strong/long histories in utilities, so I felt it my responsibility to validate, again, my data.

While I consider myself to be relatively well-versed on the core of these topics, it is the nature of this blog to focus on my expectations of the future based on information provided elsewhere, by others more directly in the path of the Smart Grid. That said, credibility is a big deal for us, and I decided to go back to Austin Energy, and understand better the reality of the situation from the folks who are actually doing the job, and who are considering these concerns as fundamental parts of their planning for successfully serving their clients on the new grid in the years to come. Andy and I called Andres Carvallo and Karl R. Rábago at Austin Energy, and they generously agreed to help us understand the world and the Smart Grid that they are planning for.

Smarter Grid versus Simpler Meter-Reading

One of the first things I learned was the richness of information gathering and interactivity that these gentlemen expect to coax from the new grid infrastructure. While time, location, and power used are at the heart of a meter read, there is much more to be learned. Investment in the Smart Grid would have a maximum return when the savings were more than a human reader's footwear and gasoline. Some examples are:

Device Health Information

By watching for varying temperature, periods since outage, battery power, heartbeat, and other meter variables, it is possible to better predict and recover from any failures that may happen.

Real Time Monotoring

As has happened historically with most new technologies, it can be expected that people yearning for more data will only be satisfied by that which is most current. It is unlikely to happen in the general population immediately, but history shows us that it is likely that such a real time monitoring feed may be in demand almost immediately, as customers recognize that there is now more information through which they can better manage their energy.

Energy Services Provision trumps Energy Provision Services

There are doubtless going to be additional requirements from the newly informed and empowered customer base for functionality that is logically delivered by the provider. This was a real eye opener for me, that Power Providers are now actively thinking about services that they can offer over the new and smarter infrastructure. Things like profiled energy use: "I am going away, manage my power." or "There is a spike in prices, manage me down by 10%", or "I only want to use power that is generated from renewable resources." These all require data, new interfaces, and a channel overwhich all of the control and monitoring information can be passed. Winners in the new market will be finding ways to capitalize on the need for energy-related services, and will not limit their investment to further driving down the costs of simply providing energy.

Networking Overhead

Given the complexity, regularity, and importance of this data, it is clear that a protocol (Like IP) will probably be adopted to package up and send all of this information in a payload to central systems for analysis, aggregation, storage, and action. Protocols carry their own overhead in terms of describing their content, sources, destinations, etc. None of this is free from the perspective of the systems carrying or storing the data.

Other Factors

We are only just beginning to see the potential for Smart Grid and Soft Grid enablers, leading me to believe that even my estimates are very likely to be low, particularly as we clamor for realtime monitoring and data analysis.

Based on all of this, it looks like the numbers are far from a simple 14 Byte read, and are more likely in the range given by Andres of 4K to 16K per reading. If we estimate the maximum case, the numbers are even higher than I had referenced in the earlier article. Let's not think about real-time (the numbers are mind-numbing), but instead look at a simple check every 5 minutes. 12 (reads/hr) X 24 (hrs/day) X (365 days/yr) X 16K (Bytes/read) yields roughly 1.7GB/meter/year. Multiply that by the number of meters (pick your own scope), and I think the challenge is clear. For more reality, take that number and multiply by 5 for readings every minute, or by 300 for readings every second. That's big.

So, is this a problem because the data going to cause the Smart Grid to explode like a flawed radiator hose in July? I don't think so. I think that time has proven that technical advancement has always helped us stay ahead of crushing data or processing burdens by decreasing computing and memory costs. This has allowed us to paper over our excesses with iron and silicon.

No, this is a problem because rushed, tactical, and incremental hardware adds will not make that data secure. It has to be expected that as organizations run out of room for data, they will simply rush to add more. Caught in a flood of data, the pressures for survival and successful operation will naturally trump any meaningful consideration of rearchitecting data storage for adequate and appropriate security.

This planning (and budgeting) needs to happen now. As Andres said on our call, "You cannot simply build an airplane for passengers who are 5'6" tall and weigh 140, because you can guess that your average passenger, much less your larger passengers, will simply not fit, because they are not that small." In other words, you need to plan for what you can reasonably expect, not for what will make your life, your business, or your CFO, ecstatic.

I think that this is the final insight. For firms that are seeing the Smart Grid as an enabler for cost-savings by transferring operations onto an IP infrastructure, or a wireless metering system, there is little reason to be concerned with a data glut.

For those who recognize that the Smart Grid and the coming Soft Grid will need data, and will need security, and will likely grow to fill whatever space is available, the call is clear. Plan for an avalanche, for a flood. Create systems and segregations that will allow for managing these flows reliably. Characterize what must come through, and what can be dropped, along the way to the back end. Do all of those things and the current systems will be fine, the next systems will not choke, and the ultimate end state will be similar enough to what has been planned to ensure stability, quality, and cost-effective services to all who connect to the grid.

The data surge is coming, and you can either surf it, or be pounded by it. You certainly will not be able to ignore it.

Image Thanks to:

http://www.flickr.com/photos/ndave/ / CC BY 2.0

Smart Grid Security: Answers in Questions

Over the past year, Andy and I have written about the risks and opportunities in the growing software sector of the Smart Grid Marketplace. We have described the space, some of the firms, the investment, and what we are seeing for security in those organizations we speak with. In response, and I think with genuine interest, we've been asked what we are worried about, and in turn, what recommendations would we specifically make to individuals who are either investing in these solutions, or who are actually building them.

In the recent NIST strategy and requirement recommendations release, there was a substantial body of information to be reviewed, and this post is not meant to summarize or to supplant those results (obviously). This is a relatively lightweight view of heavy duty and high-level considerations in software as a critical element in the development of the Smart Grid. It is a practical list of questions that organizations should be able to answer before they commit to software that will either replace or broker their interactions with the Smart Grid.

What is the software's provenance?

Provenance is a term that gets thrown around a lot, but I use it to express the idea of origin. Where did the software come from? Who made it? What was it made from? While absolute provenance is difficult or impossible to ascertain, these answers can help to guide risk awareness and management. Is it new software built for me? Is it existing software that has run similar systems elsewhere? Is it a new solution from an existing partner, or revision 0.9 from a start-up? Is it built from the ground up, or does it contain elements of legacy applications, particularly those that my have been written with a different security mindset? By understanding more about the roots of software, the strategy to secure its use will be better informed.

Why ask the question? Unless you know about the origins of software, it is very hard to put together a plan to ascertain its security. Knowing who built it provides a resource to ask about the way in which it was built. Knowing about its components provides information to use in testing it or researching testing done by others.

What is the plan for ongoing governance?

Governance, similarly, has a variety of depths of detail and application, particularly in IT. For our purposes, the questions can be limited. How will the software be updated? Who will make those decisions? What is the process to initiate or approve a change? New software in any environment, and even established software in a dynamic environment, will face frequent opportunities and requirements to change. Understanding the models through which those changes are considered, approved, and delivered enables organizations to measure and manage their own risk from flux in the software, and in any collateral instability introduced to dependent systems.

Why ask the question? Instability = Insecurity. Haphazard or non-existent governance leads to more frequent changes, less testing time for the solution in place, and to inevitable discontinuities if the software is a component of a larger system. Weak governance also increases the opportunities and likelihood of malicious coding behavior by simply increasing the chaos during the software delivery process.

What does the software do with data?

Data is at the root of almost every application's function and purpose. Whether it exists to generate data, to gather it, or to analyze it, data is not only central to the application, it is often the prime target for an attacker. For that reason, there are multiple facets to consider. What kinds of data does the application gather, where does it come from, and how does it enter the system? Once the data has entered the system, does it get stored, and is it stored with appropriate protection of privacy and integrity? If the data ever moves between components of the system or between multiple systems, is it appropriately protected by the software for privacy and integrity? Does the system restrict access to the data, and is access control sufficiently granular to permit only authorized individuals to enter into the system? Each of these questions naturally results in a series of more technical and specific questions about the behavior of the application, but requiring answers to these high-level queries will mean that these will not be ignored.

Why ask the question? Data is central to the smartness of the Smart Grid, and its protection is expected by subscribers, is in many cases mandated by regulation, and is certainly necessary to ensure reliable operation of the Smart Grid.

How has the software been tested?

The testing of software, particularly for security issues, is still a developing field. There are a variety of approaches and mechanisms, each with their own strengths and deficiencies. What testing has been done, and on what components? What approaches were used, and with what results? Have all components been considered for security issues prior to their inclusion, and how were they vetted prior to selection?

Why ask the question? Understanding the testing process for the software can uncover blindspots to some sets of security issues, and can also identify weaknesses in methodology that can indicate systemic problems from the provider. If the testing ignores a specific area, like data storage or access control, then that lack of attention raises the likelihood that there could have been a similar lack of focus during its construction. Testing has many facets, and security must be among them.

These questions are intended to be a very brief introduction to some of the underlying and quite concrete issues that must be considered during the Grid's evolution to a Smart Grid. In time, each of these areas must be expanded into multiple levels of detail, but for now, this is a start. It is the start of generating more informed awareness, and of describing the types and amount of data that is required to feel secure during the adoption of new Smart Grid technologies.

In return, though, having those answers will certainly bring more confidence, more security, and more opportunity for success in the new Smart Grid.

Image kudos to flickr ( http://www.flickr.com/photos/marcobellucci/ / CC BY 2.0 )

Microsoft Joins the Smart Grid Fray

Only question I can think of is: what took them so long? As with Bing, the Redmond company's long awaited response to Google's dominant search platform, it seems Microsoft is late to the party. Still, it's not clear that Google's early mover status in the nascent Smart Grid market buys it all that much.

Here's Microsoft's smart grid approach described by PCWorld. I wonder how the "blue screen of death" translates in the energy world? Or if we'll be ctl-alt-deleting our homes a few times per week?