[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: [Cryptography] Smart electricity meters can be dangerously insecure, warns expert
From:       Arnold Reinhold <agr () me ! com>
Date:       2017-01-16 13:06:54
Message-ID: 57FC9984-389B-49CF-9472-3080C02582F5 () me ! com
[Download RAW message or body]


> On Jan 14, 2017, at 4:05 PM, Ian G <iang@iang.org> wrote:
> 
> 
> 
> On 04/01/2017 16:41, Arnold Reinhold wrote:
> > Late last century I had a gig at Foxboro Corporation, a well-respected \
> > manufacturer of industrial instrumentation and control systems. The stuff I was \
> > working on was electronic and computer based, but they had been in business since \
> > 1908 and had developed many intricate, mechanical and pneumatic sensors and \
> > control systems, which they still supported. After the Iran-Iraq war, Foxboro got \
> > a flood or orders for the older, non-electronic devices from refineries and \
> > chemical plants in the Middle East because they had proved more resilient in war \
> > time than the newer electronic systems. We need to heed that lesson in the \
> > context of cyberwar.
> 
> Were the failures due to electrical failures?  Or was there a specific cyber attack \
> element that was taking out the gear? 

As far as I know there was no cybersecurity in industrial controls back then, hence \
the effectiveness of Stuxnet. And it wasn't just electrical failures, it was overall \
robustness in situations where refineries and the like came under conventional attack \
(bombs, shelling). The mechanical stuff was more likely to keet working and could be \
more easily repaired after an attack. 


> > More to the point, however:
> > 
> > > So ... I think the power guys are just out of their depths here.  It'll take a \
> > > while for them to develop the necessary expertise to integrate modern \
> > > processors properly. 
> > One skill essential to any good engineer is knowing when you are out of your \
> > depth and finding engineering resources with the necessary skills. So in this \
> > regard the power guys are likely in better shape than the vast majority of \
> > commercial, government and non-profit enterprises, who have few if any \
> > traditional engineers on the payroll, and probably none in management. (I'm not \
> > counting the IT department, which every enterprise has.) The problem I see is \
> > where does our power engineer go to to get reliable advice on a security design? \
> > There is so much snake-oil security out there. Vendors have their products to \
> > sell, right or wrong, government security agencies want to protect their \
> > offensive capabilities, standards bodies are not specialized in computer security \
> > and treat it as one more chapter in stove-piped specs. Who would you recommend?
> 
> I recommend the good engineer acquire the necessary skills and do it herself.
> 
> Because of the issues you (and Peter and Jerry) list, the success rate of \
> outsourcing to experts isn't high, so can a good engineer learn enough to leap a \
> rather low bar?  Typically, yes.  Is it state of the art?  No.  Is state of the art \
> available?  No. 
> Is the alternate a secure system, or a standards system that delivers too late and \
> too little, or nothing? 
> What's the compromise?  Typically, it takes a couple of good engineers to put \
> together a cheap & cheerful security protocol for a narrow use case.  Or it takes \
> an industry to make a standard that's over generalised and introduces security \
> impedance mismatches so it typically can't also ever meet state of the art.  Clear \
> economics point to "do it yourself." 

I've seen too many bad security products designed by people who thought they knew \
enough, but didn't, to accept telling engineers to "do it yourself" as the answer to \
the question I posed. Your right that industry standards tend to be too late and too \
bloated, (and possibly sabotaged by state actors). I think we need some sort of \
professional organization to develop lighter weight standards  that can become \
components in engineered systems. NaCl is a start. But why not develop a few simple \
use cases, e.g. simple machine to machine message passing, and designing solutions \
around them? 

Arnold Reinhold


_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


[prev in list] [next in list] [prev in thread] [next in thread]