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

Tue Feb 12 06:45:05 CST 2008

Matt, I think this point is sort of like asking whether Superman or
Batman would win if they got in to a fight.  There is no point in asking
the question because neither character is real.

The bottom line is what tools has IT developed already, how much
practical experience and training is required for these tools, and what
gaps remain where the needs are actually different.  

You'll note that I'm assuming that someone else is going to rub the
rough edges off of the tools.  For those who haven't figured this out,
Process Engineering is a very conservative field.  We have an installed
base of something that is known to work.  What we're trying to do is
make improvements.  As such, the first rule is very similar to the
Hippocratic Oath: "First, do no harm."  

IT departments are often pushed in a white heat of development to use
bleeding edge software and hardware on brand new applications.  As
control systems engineers, we don't often see that clean sheet of paper.
And further, because of the risk to life and limb, we don't go there
unless there is a damned good reason to.  It should be obvious why we
aren't pounding down the door to use the very latest and greatest tools
from the IT world.  

Nevertheless, security changes.  We need to develop ways to shorten the
distance between the R&D side of things and the Production Systems.  But
we can't go blindly throwing new apps and security tools at an existing
SCADA system any more than you'd casually patch the firmware in a
router.  

Jake Brodsky

________________________________

From: scadasec-bounces at news.infracritical.com
[mailto:scadasec-bounces at news.infracritical.com] On Behalf Of Matthew
Franz
Sent: Monday, February 11, 2008 11:44 PM
To: scadasec at news.infracritical.com
Subject: Re: [SCADASEC] IBM is offering 'SCADA security best
practices'...
Importance: Low

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/20080212/09d05332/attachment.html 