[SCADASEC] Implications of SuiteLink's flaw

[Brodsky, Jake]

I wanted to take my time to respond somewhat more thoughtfully than
usual,  because Matt brings up some strong points to consider.  


"So you are saying that in the organizations in question that don't
have this awareness and are not tracking vulnerabilities in
traditional  IT platforms. Microsoft, Cisco, Oracle, etc?"

Yes, I am.  I'm saying that, while there are a few people who do
understand this stuff, and while it's conceivable that you might find
one on the plant floor, they're so rare that we can't make policy based
upon their existence.  The vast majority of asset owners simply do not
know how to patch a SCADA system.  


"It is different problem if some folks are already managing
vulnerabilities and have appropriate workflow in place for *some*
platforms vs. nobody knowing anything about *any* of their platforms."

Agreed.  These are packaged systems, often delivered as part of a much
larger construction project.  I've described before how these sorts of
contracts often get perpetrated.  


"Then this isn't (entirely) the fault of the Operations guys.
Security/Compliance organizations have a responsibility to know what is
running on their networks. And is a more fundamental issue above and
beyond their control systems."

This is accurate.  It goes back to the question of how do we build up a
control system security model that even an asset owner can understand
and manage.  


"My problem with public disclosure is that if vulnerabilities are only
disclosed through customer support channels (which the compliance
organizations don't have access to, right?) then there is no way they
can monitor compliance or make risk decision (with the input from the
platform owners). There is no oversight. When I ran product, I was
*GLAD* to get that little note/ticket for a vuln that had been
disclosed. I usually knew about them myself, but if I only have access
to vuln data on the products I run (and the compliance org doesn't)
this is a case of the fox watching the henhouse."

I agree completely.  I'm advocating an organization for control systems
security.  It's a half baked notion in that it won't keep the
intelligence agencies out.  Red Teams will most certainly hear about
these flaws.  However, there is a fighting chance that high school kids,
and casual hackers (such as those from extreme political groups) will be
kept at bay.  


"I would agree that the advisories didn't have much background
information in particular. Probably because the finders didn't have
experience. I would guess that if the vuln had been submitted to
US-CERT (or a control system CERT, which I generally oppose) and it
had been *their* advisory it might have had more explicit information.
But this came from the finder.

This is a great idea for those in the club. But those that aren't in
the club aren't going to play by the rules."

Look, we have Black Hats, Grey Hats, and White Hats.  What I envision is
a group of Control Systems White Hats who will discuss the ramifications
and defenses among the community in relative confidentiality.  I can't
control the Black Hats.  But I have no desire to hand them any more
information than they deserve.  Thus far, most of the papers in Black
Hat conferences are relatively ignorant and benign.  I don't care to
speculate how long that situation will stay that way.

If we don't attempt to form this group, the White Hats will have no
other place to turn to.  We'll simply have to expose all SCADA systems
publicly.  That will make for some very busy, unstable SCADA patching
--or at the very least it will make SCADA systems very isolated and
difficult to communicate with.  

This is about uptime, folks.  Remember the key difference between
Control Systems and Office IT is that the priorities of confidentiality
and availability are inverted.  

I suspect we're going to see a flood of critical patches very similar to
the ones we saw for Microsoft around 2003 and 2004.  The spotlight is
upon us.  We need to think about how we're going to handle this.  

If we are forced to deploy a flurry of patches across the servers and in
to the field, we're going to have some very serious availability
problems.  I'm trying to suggest a temporary way of mitigating that
disaster to get us over the hump of stability and to give us time to
work out patching policies and distribution channels right to the
embedded systems in the field.  

I'm trying to apply some lessons learned from the IT world.  Is this
notion crazy, misguided, unworkable (even in the short term)?  Or do you
think this can work?  

What are the practical logistical problems you envision with this?  


Jake Brodsky