Navigant Research Blog

Cloud Security Reaches New Heights

— June 12, 2014

I have consistently taken the contrarian position that cloud computing is more secure than in-house deployments.  That’s only contrarian in terms of public opinion – to me it makes perfect sense that a cloud service provider will be more attentive to cyber security than a utility.  For a cloud provider, cyber security is a core competency.  For a utility, it is not.

This week I stumbled upon what I hope will be compelling evidence that cloud computing is secure enough for utilities.  Namely: a complete do-it-yourself cybercrime service, which even includes 1 year’s hosting.  That means: the criminal activities run in a cloud.  And don’t worry, clicking on that link will only take you a story about the DIY service, not the service itself – so you won’t end up on an FBI watchlist.

Cybercrime marketplaces have been around for years.  What strikes me about the current DIY offering is that it includes cloud-based hosting.  Now, utilities may have worries about the security of cloud computing, but criminals have much bigger worries.  While I would never say that utility control systems are completely defended, there is an awful lot of resiliency built into transmission and distribution networks.  Those networks can withstand powerful attacks, as we all learned with the Metcalf Substation Attack in 2013.  On the other hand, criminals have to worry about being caught.  Not only by law enforcement agencies, but also by other criminals, who typically have a different set of operating principles than law enforcement agencies.  So when a cloud is offered as bulletproof to this audience, we may assume that it really is strongly protected.

Good Enough for Crooks

And that’s the crux of the issue: if cloud computing can be made secure enough that criminals will use it, then it can be made strong enough for private industry – which at least has the law on its side.  Meanwhile, some of the more recent developments in smart grids, especially data analytics, almost require cloud computing to work.  In-house deployments of petabyte- and exabyte-sized databases are impractical, even before wondering where a utility would find qualified staff to maintain those databases.

So could we finally answer the question: Is cloud computing secure enough?  If it’s secure enough for criminals to risk their lives and their families’ lives with it, then maybe it will work for utilities too.  Just maybe.

I should point out that a number of the links in this blog are the work of Dancho Danchev, one of the best respected security researchers in the industry.  He will go where angels (and the rest of us) fear to tread.


Data Analytics Bring Integrity Challenges

— June 6, 2014

The only thing worse than making no decision is making the wrong decision.  As utilities embark into analytics-driven decisions, they must keep this in mind.  When the analytics are down and there is no data at all, utilities can go into human intervention mode, which they did for the first 100 years of their existence.  But when the data is available but wrong, that’s when havoc may be wreaked.  The increase of automation enables fast and fine-grained control that utilities have never before enjoyed.  Yet, that automation assumes accurate data.  Inaccurate data leads to inaccurate decisions.

In other words, data, like people, needs integrity.

Integrity simply means that the data has not been modified without detection.  Less frequently discussed than confidentiality and availability, data integrity suffers from a sort of middle-child syndrome.  Whether we talk about enterprise IT security or control system security, integrity sits sandwiched between confidentiality and availability.  Yet, integrity is nearly as critical as availability.

Available and Integral

To their credit, the data analytics experts that I speak with often mention security.  It’s usually the last topic they cover, but they do cover it.  That’s okay.  We security practitioners are always last on the agenda and we expect to be last on the agenda.  Unless there are auditors in the room – then they go last.

The most important security aspect of data analytics for utilities is availability.  If your data is not available when you need it, then it is useless.  Timing is critical.  Grid reliability may need to act on data generated within, oh say, the last 4 milliseconds.  On the other hand, time-of-use rate design has less strident requirements.  No matter what, the right data must be available when it’s needed.  Nearly everybody gets that.

But data integrity is nearly as important as availability.  One key to ensuring data integrity is data encryption.  Often associated with confidentiality, encryption also ensures data integrity via the use of message digests, calculations that indicate whether or not a data record has been modified.  Modern grid sensors usually have built-in encryption capability, using standards-based approaches.  However, many legacy devices (read, old) do not have the computing power to implement encryption.  Some have essentially no computing power at all.

The Devil in Legacy Devices

Yet, legacy devices remain critical to the stable operation of distribution networks.  There is no absolute protection for these devices yet.  Control system vendors sell bump-in-the-wire devices – which can be placed right next to a legacy device to encrypt its data.  But the device itself is still unprotected.  National labs and commercial vendors have launched ambitious research programs to identify new ways to ensure data integrity from legacy devices.

And therein lies the problem: data from legacy devices is every bit as important as data from modern devices.  Under the norms of cyber security paranoia, we must assume that legacy device data is compromised.  Until – if ever – we can rest assured that legacy devices are adequately protected (or replaced en masse), we need something to ensure that legacy sensor data is reasonable and unmodified.  Massive volumes of data suggest that only automated inspection can accomplish this – human intervention need not apply.

All of which means: do not overlook the data integrity solution when you assess the data analytics solution!


In Mergers, Security Risks Arise

— May 6, 2014

While my colleagues analyze a couple of recent big acquisitions – GE’s announced acquisition of much of Alstom and Exelon’s announced acquisition of PEPCO – I’m going to examine mergers and acquisitions (M&As) from a cyber security perspective.  This is one of those rare cases where security has a longer timeline than other disciplines.  Usually we get the call just after the disaster.

An M&A, almost by definition, introduces a great amount of variance into what was once a stable environment.  Two corporate cultures must merge.  Two sets of business processes must merge, frequently with substantial overlap in areas such as back-office processes.  Two sets of operational processes must merge.  Two IT architectures must merge, or at least be made to coexist.

Each of these sub-mergers introduces variation and uncertainty that can create prime targets for cyber attackers.  Sophisticated attackers are aware that stable, day-to-day operations are likely to be best protected.  Exceptional situations, such as system mergers or transitions, can present attack windows where normal protections are not present.

They’re Watching

A key attack point lies in the transition from old to new processes or systems.  Many M&A transactions are justified in part by the reduced operating expenses of the combined entity.  Redundant administrative functions can be eliminated, separate IT systems can be merged, control of operating networks such as SCADA can be centralized to a single control center.  During these mergers, security is often lax because the transitional situation will only endure for a short time period.  There is a temptation to overlook security and gamble that system conversions or migrations will be completed before anyone notices.  But attackers start taking notes when the acquisition is first announced.  When the M&A involves publicly traded companies, the transaction may take months to finalize – and all of this time can be used to plan an attack during the transition period.

Meanwhile, employees unfamiliar with new business processes can be susceptible to social engineering attacks, wherein the attacker may pose as someone performing the transition activities and ask for passwords or other sensitive information in the name of speeding up the conversion.  As with many other social engineering attacks, this one often works because the scenario is plausible.

Watch the Exes

There are many steps to mitigate these risks.  Here are three of the most important:

  1. Build security into all transitions – business processes, IT, control systems, everything.  Think about what kind of protections will disappear when old processes or systems are decommissioned and plan for how those protections will remain present during the transition.
  2. Conduct a thorough employee awareness program to ensure that all employees of both companies understand what transitions are taking place and what their roles are in protecting the resulting merged entity during the transition.  It is especially important to notify employees that no one will call them and ask for passwords or other sensitive data.
  3. Have a backup plan in case something goes wrong during the transition to ensure that the business can continue to operate.  Like most business continuity planning, this is often an arduous but critical activity.

Usually transitions associated with M&As do not all happen at once.  Enterprise IT systems and operations control systems sometimes are not merged until years after the transaction.  Unfortunately, one of the first transaction activities is to terminate the employment of administrative employees made unnecessary by the M&A.  Even in this case, there should be sufficient protection against hostile activities by disgruntled employees.


Honeypots Teach Us About Attackers

— April 11, 2014

Security researchers will try almost anything to find out who is attacking their clients and how.  One of their best-loved and most effective techniques is a honeypot.  First developed about a decade ago, a honeypot is a decoy system or network – a tempting target for attackers that is not really a target at all, but a trap.  The objective is to lure attackers into the honeypot and then watch how they work.  Attackers’ methods are almost like fingerprints; researchers who are familiar with a number of attackers can often identify the attackers simply by watching their step-by-step process of discovery through the honeypot.  Researchers do have other methods as well, such as tracing IP addresses or even fingerprinting the attackers’ browser – adding source code to the attackers’ browser that reveals more about their identity.

Attackers are, of course, aware that honeypots exist, so preparation of an effective honeypot must be extremely detailed.  To set up a honeypot requires a fair bit of planning to make the target look as realistic as possible.  Eventually, the attackers will realize that they’ve been had, so the objective is to keep them in the honeypot as long as possible to gather as much information as possible about their methods and their identity.

One security researcher described one of his honeypots in a talk at the SANS 9th Annual ICS Security Summit.  Kyle Wilhoit of Trend Micro described a scenario in which he set up juicy but fake targets on five continents and then watched them be attacked.   Each was a model of a control system for a small municipality water pump.  Connected directly to the Internet and with insufficient protection, this water pump looked like easy pickings, and it was attacked nearly 100 times.  Again, the attackers were not attacking an actual water pump but were instead sending commands to a simulation of a water pump – the honeypot.

Disturbing Motives

Perhaps most disturbing to me is that most of the attacks that Wilhoit reported were attempted sabotage, not data exfiltration.  Nearly all of my recent research indicates that large-scale persistent attacks against control networks have been data exfiltration for competitive advantage.  In this case, however, data exfiltration attempts were a minority of all attacks.  Even some well-known attack teams supported by hostile nation-states attempted to disable the water pump, not simply exfiltrate its data.  For me, this requires a rethink:  Is all that data exfiltration really just for competitive advantage or are attack plans being prepared?  As ever, only the attackers know, but this one project suggests that there may be more attack planning than has been assumed.

You might think that attackers seeing a control device connected directly to the Internet would say, “Nah, this is too good to be true.”  And then seeing a control device directly connected to the Internet with little or no security – “It just has to be fake, right?”  Sadly, no.  Attackers are accustomed to discovering real systems like this all day long – directly connected to the world and with no protection.

My conclusion is mixed.  Honeypots are an effective tool for learning about our adversaries.  Yet, honeypots work because the unprotected systems that they mimic are commonplace in our industry.


Blog Articles

Most Recent

By Date


Clean Transportation, Electric Vehicles, Energy Storage, Policy & Regulation, Renewable Energy, Smart Energy Practice, Smart Energy Program, Smart Grid Practice, Smart Transportation Practice, Utility Innovations

By Author

{"userID":"","pageName":"Bob Lockhart","path":"\/author\/blockhart","date":"8\/1\/2014"}