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

[wboyes at putman.net]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://news.infracritical.com/pipermail/scadasec/attachments/20080210/2b2c26ab/attachment.html