On security - SCADA sofware defect (Siemens' WinCC)

[Lennart Sorensen]

On Sat, Sep 25, 2010 at 12:30:18AM -0400, Christopher Browne wrote:
> I've got a brother who works for Omron, one of the significant vendors
> of PLC hardware, and thru his purview of some of the competitive
> behaviour that takes place, there's an extra "stack" of complexity
> that makes this harder, I suppose to the point of perhaps being
> "inherently broken by design."
> 
> The vendors are pretty notorious for being mighty proprietary,  They
> may have some layer of "interoperable stuff," to satisfy some
> requirements, but they want you to buy into Their Stuff, so there's
> liable to be really cool interfaces intended to allure you via
> improved performance and improved functionality to use Omron-only, or
> Siemens-only, or Fanuc, or whomever's lineup.
> 
> In a big, hairy, complex system like a nuclear reactor, it's not
> unlikely that there's enough subsystems that you're forced to buy into
> multiple of these vendors.  Considerable risk of there being weird
> islands of different proprietaryness within the same overall system.
> 
> And if there are lots of pieces talking to each other, any one
> component's password may have to get copied over to dozens of other
> components that legitimately need to speak to it.
> 
> Now, you've got a significant "security information" management
> problem.  Hundreds of devices, talking various protocols, not
> uniformly "TCP/IP everywhere," and if you set a different name or
> password for a particular component, propagating that to the diverse
> set of places where it needs to go is a non-trivial matter.
> 
> On "24", they'd make up tech talk about "we're changing the
> authentication info and reconfiguring the network."  Which isn't
> nonsensical.  (And then talk nonsense about "I need a socket opened
> for this."  I don't think they ever knew what a socket actually is...)
> 
> That communications process might take minutes or more to work, and
> mightn't necessarily be of comfortable reliability.  If it's a
> time-sensitive system, trouble could readily come up during those
> "minutes or more."
> 
> With that as context, I can readily see process engineers, that aren't
> forcibly security wonks by interest, training or practice, not being
> terribly interested in securing this with highly-localized
> authentication data.  It could cause them reliability heartburn on the
> average day.
> 
> You don't rewrite your whole network's DNS configuration on the fly
> just because it's Tuesday; you're as likely to drop a big chunk of the
> network on the floor as you are to fix security holes.  And I suspect
> that's something like the relevant analogy.
> 
> Certainly, there's a grand problem here that there's a lot of
> not-very-secure infrastructure.  I don't think it's as easily solved
> as "oh, just change some passwords."

My point was that they should never have installed anything with default
passwords in the first place.  Everything should require as part of
deployment setting a non-default password.  Apparently Siemens is
telling people that they should always leave certain passwords as default.
That's insane.  That's not a password anymore, just a hardcoded value.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists