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

Mark Fabro fabro at loftyperch.com
Mon Feb 11 09:35:32 CST 2008


Thanks Walt, I am sure there will be lots of postings regarding your
'insights'.

 

All:

 

The area of forensics in control domains is becoming a hot discussion
topic. Just to put it out there, what are the thoughts on kernel hashing
to help uncover activity? Many agree that forensics must be done in real
time, so what are the mechanisms that people can use to embed a
capability prior to an event? Also, how are people suggesting to handle
the issue of disparate clocking/timing channels? There has been some
chatter, figured I would pick it up again.

 

 

________________________________

From: scadasec-bounces at news.infracritical.com
[mailto:scadasec-bounces at news.infracritical.com] On Behalf Of
wboyes at putman.net
Sent: Sunday, February 10, 2008 5:43 PM
To: scadasec at news.infracritical.com
Subject: Re: [SCADASEC] IBM is offering 'SCADA security best
practices'...

 


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/20080211/c332ba43/attachment.html 


More information about the scadasec mailing list