Navigant Research Blog

Security Flaws Are Safety Issues, and They Need to Be Fixed

— August 7, 2015

Connected vehicles hold tremendous potential for improving road safety while simultaneously reducing energy consumption and road congestion through data sharing over the next 10–15 years. Unfortunately, that potential may never be realized unless there is a dramatic change in the way automakers and suppliers handle cyber security. The recently revealed security vulnerability in Fiat Chrysler Automobiles (FCA) products with Uconnect telematics systems demonstrates some of the flaws in the current landscape.

Wired.com recently ran a report highlighting a flaw in the Uconnect telematics system discovered by noted white hat security researchers Charlie Miller and Chris Valasek. The pair worked out how to remotely connect to the vehicle’s cellular modem, a key component of Uconnect and all other telematics systems. From there, they were able to access a port in the vehicle network that provided entry to vehicle control systems, including steering, braking, and other functions. The article noted that Miller and Valasek notified FCA and waited until a fix was developed before publicly disclosing the flaw. So far, so good.

A Bloomberg Business story claims that FCA was actually notified of the vulnerability in January 2014 and waited a full 18 months before notifying the National Highway Traffic Safety Administration (NHTSA). However, according to FCA spokesman Eric Mayne, “Prior to last month (July 2015), the precise means of manipulating a vehicle as demonstrated for the media was not known.” FCA notified NHTSA, developed a fix to eliminate the attack vector, and subsequently issued a recall for 1.4 million vehicles. Despite determining that the vulnerability didn’t constitute a safety defect according to current regulations, FCA and NHTSA decided to conduct the campaign as a recall to protect customers.

Potential Safety Defects

Cyber-attacks on banks and retailers can be annoying and costly, but they are unlikely to ever prove life-threatening. All potential automotive cyber security flaws should be treated as potential safety defects until proven otherwise. While the information FCA officials had in early 2014 may not have represented a safety defect, we need a standard mechanism for reporting and tracking potential vulnerabilities.

Navigant Research’s Connected Vehicles report projects that by 2025, 80%–90% of new vehicles in North America and Western Europe will be equipped with vehicle-to-external (V2X) communications technology, a market with potential revenue of more than $36 billion globally. Automakers and suppliers have claimed that they take security seriously, but with few exceptions—notably Tesla Motors, and to a lesser degree, Hyundai— they seem more intent on keeping information out of the public eye.

General Motors (GM) in particular joined John Deere earlier this year to push for protection of their vehicle software under the Digital Millennium Copyright Act (DMCA). GM has not publicly stated why they were seeking protection, but since the DMCA prohibits tampering with or removing protections from software, it seems likely that at least part of the rationale is to keep researchers from legally investigating these systems.

Design for Security

If automakers and suppliers continue to suppress information about automotive cyber security, they will erode both consumer and regulatory confidence in connected vehicles. Software security is an extremely difficult problem, especially for networked systems. It’s best to design the architecture for security from the start rather than patching it in later. However, product development lead times last 3–5 years or more, and legacy systems need to be protected as well.

Automakers need to acknowledge that cyber security vulnerabilities are indeed genuine safety issues now, and they need to be open to both responsible disclosure and prompt updates. If not, we are at serious risk of missing out on the benefits of both connectivity and increasing levels of vehicle automation.

 

Security Risks of Smart Meters Not New

— August 5, 2014

Recently, the Insurance Journal weighed in on the threats introduced by smart meters.  While I agree that smart metering presents risks both cyber and financial, I submit that many of those risks are merely new flavors of risks that have existed for decades.  And smart meters also introduce benefits that more than offset those threats.

The article seems to equate smart meters with the Internet, though we have yet to find any utility that is actually connecting its meters to the Internet.  (There are utility control systems connected to the Internet, most of which are known to hostile nation-states.)  And it also conflates a number of unrelated topics.  For example, the author cites the recent Havex Trojan, which attacks SCADA systems, not smart meters.  Likewise, the article mentions Stuxnet, which was directed at uranium enrichment centrifuges.  Stuxnet is a cautionary tale for anyone managing a control system, but smart metering networks are not control networks.  Still, the Insurance Journal explores situations worth considering.

Uneasy in the Islands

The successful meter attack described, citing Brian Krebs’ excellent analysis (written 2 years ago), occurred in Puerto Rico.  In that case, former employees of a local utility offered to reprogram residents’ smart meters via the meters’ optical diagnostics port.  For a fee ranging from $300 to $1,000, the technicians would reprogram the meters to under-report energy usage, resulting in a lower electricity bill every month.  This attack had nothing to do with the Internet.

The key to dealing with cyber risks is taking a big picture view of the situation.  In Puerto Rico, the fraud would have been easy to detect.  Utilities can put an additional smart meter at each transformer to measure total energy distributed to the customers on that transformer’s circuit.  When the total energy metered for all the individual customers is less than the total measured at the transformer, clearly something is wrong.  It may or may not be fraud, but it can be identified quickly by the technology described in Navigant Research’s report, Meter Data Management.  The $400 million lost in Puerto Rico indicates that the fraud may have persisted for months or years.  That sum is about 10% of Puerto Rico Electric Power Authority’s (PREPA’s) annual revenue – which seems awfully large to fly under the radar.

Finding Walter White

Smart meters provide other fraud detection capabilities that their electromechanical forebears do not.  One example is credit and collections.  Smart meters typically report energy consumption every 15 minutes.  So, for a customer who is already delinquent and is currently having a large spike in energy consumption (this is a common attribute of illegal activity, such as meth labs), smart meters enable utilities to detect these situations and initiate collection or disconnect activities immediately.  This approach is impossible with monthly-read electromechanical meters.  Plus, remotely disconnecting criminal activities is safer for the utility workforce.

For sure, smart meters introduce attack vectors that did not exist before.  This is a common byproduct of new technology.  Identity theft was much more challenging before we had the Internet – yet, there are few, if any, movements to shut down the Internet because of identity theft.

The Insurance Journal article does quote Navigant Research’s market forecast for global smart meter deployment.  The 1.1 billion smart meters expected to be deployed by 2022 should indicate that it’s time to stop worrying about smart meter security and just get on with it.

 

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!

 

Blog Articles

Most Recent

By Date

Tags

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

By Author


{"userID":"","pageName":"Cyber Security","path":"\/tag\/cyber-security","date":"9\/3\/2015"}