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

Tue Feb 12 13:13:05 CST 2008

The bottom line in where this thread has gone is that there is no right or
wrong answer as to how different SCADA security is from IT Security or
whether or not security should be sacrificed over availability or the other
way around.  It is a situational decision with multiple factors and
variables that are all part of a larger equation no matter what environment
you are dealing with.  IMHO, there should be no "philosophy" taken into
account when dealing with any systems security, as any such preconceived
notions can corrupt the overall end objective.  When performed properly, a
risk analysis can be completely void of any labels such as SCADA and IT
because the weight of each variable and factor involved will dictate the
ultimate strategy based on the individual needs of the environment.    

Clint 

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

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
 <mailto:wboyes at putman.net> wboyes at putman.net
Read my blog, Sound Off, at  <http://www.controlglobal.com/>
www.controlglobal.com 

"Matthew Franz" < <mailto:mdfranz at gmail.com> mdfranz at gmail.com> 
Sent by:  <mailto:scadasec-bounces at news.infracritical.com>
scadasec-bounces at news.infracritical.com 

02/09/2008 11:36 AM 

Please respond to
 <mailto:scadasec at news.infracritical.com> scadasec at news.infracritical.com

To

 <mailto:scadasec at news.infracritical.com> 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>
http://news.infracritical.com/mailman/listinfo/scadasec

To review our privacy statement, please visit:
 <http://www.infracritical.com/privacy.html>
http://www.infracritical.com/privacy.html

 <mailto:scadasec at news.infracritical.com> scadasec at news.infracritical.com
 <http://news.infracritical.com/mailman/listinfo/scadasec>
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/aee5dea5/attachment.html 