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

Tue Feb 12 12:38:10 CST 2008

I do NOT want you doing security for the refinery down the block.

----------------------------------------------
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/11/2008 10:44 PM
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'...

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/ 
_______________________________________________
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/20080212/9f299e0e/attachment.html 