[SCADASEC] IBM is offering 'SCADA security best practices'...

Mon Feb 11 22:43:50 CST 2008

Security is security. Period. It doesn't wear a hard hat or a baseball cap.
The scale might different (subseconds to seconds, minutes to hours, hours to
days) but the thought process is the same.

And if you compare the gold standard of IT best practices (the ones you are
sick of having shoved down your throat) with the reality of 10-15 year old
control system networks, sure you can maintain the fantasy of difference.
But if you compare 5-10 year old IT networks that might not always live up
to best practices the glass starts to shatter and the differences start to
fade away.

It is about the A being more important than the C or the I.

That is true whether you are in a plant or a data center or the Internet
core you don't casually upgrade shit, you don't upgrade routers or swtiches
at the drop of a hat every time Nortel or Cisco comes out with an advisory.
You think long and hard about a patch. You test it. You hope and pray your
development environment similar enough to prod.

And if you've got 600-700 days up time on a UNIX box you obviously haven't
been patching. So you mitigate. You have redudancy and failover in your
infrastructure to avoid outages or so you can patch a node at a time within
impacting the A. You build it in the power, in the switcher, routers,
servers, apps, all the way up.

I will admit that Critical IT Infrastructure might not have the S (safety)
unless maybe you shut down the HVAC in a large data center. In "IT" there
might not be a fire/explosion but there is definitely heat when your
customers/clients CIO calls up your CIO. And shit rolls downhill and fingers
start pointing and the dollar signs start being thrown around: "because you
won't open up port so and so you are costing me $$$/hr) and possibility some
exploit can easily become an Academic point compared to reality of data
loss.

And to your point about the consistency of firmware. Maybe, maybe not when
it comes to routers/switches but I guarantee you the firmware on high end
servers (for example the lights out software that allows virtual KVMs) is
*harder* to install than an that IO module where you are lucky to have an
RS-232 andt a minute or two outage. On servers you might be stuck with stuck
with flashing via USB and that could take 10-20 minutes of an outage.

Call me dangerous....

- mdf

> If what you are doing is SCADA security, instead of IT Enterprise
> security, I would like to offer two observations.
>
> The first is that SCADA security has a somewhat different purpose than
> enterprise security. Both are certainly aimed at protecting the assets of
> the corporation or utility from attacks, whether interior or exterior. But
> enterprise security seeks to protect the servers primarily, and reacts to
> attacks by cutting off what external or edge devices the security people
> think they need to.  SCADA security, however, seeks to protect operating
> systems _while they are continuing in operation_ and cannot shut down edge
> devices (the definition of these is somewhat different, too, between SCADA
> or plant security and IT enterprise security) unless nothing else will do.
> When we structure a defense position, then, we must look at this critical
> difference. You can shut down most, if not all, enterprise functions for
> significant periods of time with little harm. You cannot shut down a plant
> or a SCADA node without critical repercussions.
>
> The second is that it is vital to IT Enterprise security (and quite
> rightly so) that every guarded entity, be it a server, a switch, or a
> computer, have the same level of software revision, and firmware revision.
>  On the plant floor, or in a SCADA implementation, it not only is not
> necessary to do this, it can very seriously be not only counterproductive
> but also actively harmful to do this.
>
> At the ARC Forum last week, Boeing IT experts, Craig Dupler and Steve
> Venema, explained in detail how Boeing realized the truth of these two
> observations, and what they have been doing for the past five years to
> differentiate and distinguish plant and enterprise security systems. I hope
> to have them present this in article form in _Control_ in the coming months.
>
> Any security expert who has not carefully internalized these significant
> differences between enterprise IT security requirements and plant and SCADA
> security requirements can actually be an active danger to the plant or SCADA
> implementation-- as dangerous as an uncontrolled attacker.
>
> Walt
>
> ----------------------------------------------
> Walt Boyes
> Editor in Chief
> CONTROL magazine
> ControlGlobal.com
> 555 W. Pierce Road, Ste. 301
> Itasca, IL 60143
> 630.467.1301 x 368
> wboyes at putman.net
> Read my blog, Sound Off, at www.controlglobal.com
>
>
>  *"Matthew Franz" <mdfranz at gmail.com>*
> Sent by: scadasec-bounces at news.infracritical.com
>
> 02/09/2008 11:36 AM
>  Please respond to
> scadasec at news.infracritical.com
>
>   To
> scadasec at news.infracritical.com  cc
>   Subject
> Re: [SCADASEC] IBM is offering 'SCADA security best practices'...
>
>
>
>
> >
>
> > That's fine for automated attacks / scans, but doesn't help you a bit
> for
> > somebody who targets you. And even automated tools can be scanning every
> > port to see if the required service is available on any port.
> >
> > Doing port changes to your services is one thing to do, but do not think
> you
> > are then secure. IMHO, this is still security through obscurity.
> >
>
> Obviously.
>
> Sure it would be foolish to *just* do these sorts of obfuscatory
> actions (another one many folks would consider "security through
> obscurity" would be removing banner/version info from applications,
> right? doesn't make an app less vulnerable) but to intentionally avoid
> adding additional hurdles that eliminate some % of the attacker
> population just to just avoid a security cliche, seems even more
> foolish.
>
> But if this position is "security through obscurity" call me its #1
> proponent.
>
> - mdf
>
> _______________________________________________
> To unsubscribe from this mailing list, please visit:
> http://news.infracritical.com/mailman/listinfo/scadasec
>
> To review our privacy statement, please visit:
> http://www.infracritical.com/privacy.html
>
> scadasec at news.infracritical.com
> http://news.infracritical.com/mailman/listinfo/scadasec
>
>
>
> _______________________________________________
> To unsubscribe from this mailing list, please visit:
> http://news.infracritical.com/mailman/listinfo/scadasec
>
> To review our privacy statement, please visit:
> http://www.infracritical.com/privacy.html
>
> scadasec at news.infracritical.com
> http://news.infracritical.com/mailman/listinfo/scadasec
>

-- 
Matthew Franz
http://www.threatmind.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://news.infracritical.com/pipermail/scadasec/attachments/20080211/3175a41d/attachment.html 