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

wboyes at putman.net wboyes at putman.net
Tue Feb 12 12:28:18 CST 2008


Leif,

Most of the "public facing" server examples you quote are not germane to 
this discussion. I did not intend to talk about Yahoo, or Postini. I was 
speaking specifically about my own area of expertise, that of the 
manufacturing companies and enterprise IT in those industries. If Exxon 
has to take down its public-facing website because it gets hacked, not 
many people would care outside of Exxon, and it probably would rate less 
than a story on the evening news.

Yes, many of the rules are the same for both plant IT and SCADA systems 
and the standard enterprise IT security establishment. THERE IS NOBODY 
ARGUING ABOUT THAT.
Where we differ is that I believe, quite strongly, that there are 
significant differences in both implementation and philosophy between the 
two.

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



Leif Ericksen <lericksen at sbcglobal.net> 
Sent by: scadasec-bounces at news.infracritical.com
02/10/2008 06:45 PM
Please respond to
scadasec at news.infracritical.com; Please respond to
lericksen at sbcglobal.net


To
scadasec at news.infracritical.com
cc

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






Please see in-line comments.

On Sun, 2008-02-10 at 16:42 -0600, wboyes at putman.net wrote:
> 
> 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

Yes SCADA security and enterprise security are can be very different
beasts.  However, I would disagree that enterprise security primarily
reacts to attacks by cutting off devices that the security team thinks
needs to be cut off.

(Keep this in mind as you read this, there is a difference between
perceived attacks, actual attacks in progress, and attacks with a
penetration.)

Now if there is an active attack going on they (the Security) may cut
off access to prevent further damage but then again depending on the
attack they may simply block access to the IPS that are creating the
attack.  This block could mean an entire Class C, Class B, or even Class
A  network, how about even several networks?  For instance if a
companies Internet facing mail servers are under active attack they
will/may not simply shutoff all access to the Internet, rather they may
just block several networks or the offending IPs.  Granted there
might/will be fallout of "GOOD" IPs if you start blocking entire
networks.  But that will be relatively insignificant, if you keep the
servers up and running. 

>  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

No real difference than my sample above.  But we could even change this
to the company's public facing web servers.  If they are under active
attack, the company may only shutdown the offending IPs or networks.
The Servers will still do their jobs, but the offenders will be blocked
until they alter tactics and move to a network that is not blocked.

>  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. 

I would disagree, a company's Internet facing web servers get a lot of
notice.  How about a company that provides Internet E-mail services to
hundred to thousands or more people (GoodMail, Postini SBCGLOBAL/AT&T,
Verizon).  Those shutdowns would get noticed fairly fast.  Even
internally, if a company were to shutdown services it could get noticed
quickly. For instance if a company shuts down its Internet gateway many
people in the company will notice that. 

How the shutdown would impact the company really depends on how long and
how wide spread the outage is.  Will it be local, national or worldwide?
In this modern age it seems that every bit of news eventually makes it
world wide.  You have got to love the Internet!

> 
> 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 
> 

Bottom line we would have to say general internal corporate operations
might have servers that can get shutdown unnoticed.  But if there is any
public facing part it is likely they will try to keep the servers up and
running unless they know the there has been a penetration.  Now if there
has been penetration you will have one ugly mess on your hands.  Not
only will you have an ugly mess, but you will have many upset folks, and
some red faces are possible in the administrator community.  These red
faces are likely caused by administrators *failing to do their jobs* by
keeping the servers patched, or even minimally "secured". 

Now, we all have to remember the rules of security for computers or
other networked devices.

- If you must have a secure system DO NOT purchase a system.
- If you must purchase a system, DO NOT take it out of the box.
- If you must take it out of the box do not power it up.
- If you must power it up DO NOT connect it to a network (or activate
wireless networking)
- If it must be connected and on the network, *YOU MUST* follow all the
basic and advanced precautions to ensure that the system(s) stay safe
and "secure".


 
> ----------------------------------------------
> 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 
> 

There may be some differences in all between SCASA and general
computer/network security.  However, it seems to me that some of the
basic principles can be applied to both.  Although, I am sure that there
are some 'special' cases that have to be dealt with in order to 'secure'
the environment.

--
Leif Ericksen


_______________________________________________
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/cf9f90dd/attachment.html 


More information about the scadasec mailing list