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

[Matthew Franz]

> The only argument that Matt or myself or any of the IT folks who may
> or may not have yet earned their stripes, is that we understand
> exactly what you're talking about -- it's how we ran networks a decade
> ago when HA was something that you kludged together (Stonebeat
> anyone?) and hoped and prayed would work.  We know the mindset - we've
> all been there.  A network admin in 1997 usually only had stacks of
> unmanaged switches without any realizable redundancy, systems which he
> or she understood in great detail and trusted because they were
> handbuilt and loved.  We've been there, we have those stripes - it's
> just that we're from a different branch. What we're getting into is a
> pissing match over the wrong thing -- my branch is better than your
> branch.  It's like an argument amongst pilots -- since all 4 branches
> of the military have pilots -- WHAT THE HECK ARE YOU ARGUING ABOUT?
>

I think the point is to try to have a reasonable (if heated)
discussion about the technical (or business) requirements vs. clumping
things into flawed dichotomies (and I think Jake's comment about
Superman/Batman is right on the money).

And once we get down to the low level and start talking about specific
requirements and principles (diversity, operator experience) I think
there is more in common not only when you look at the requirements,
but als among engineers that maintain/operate infrastructure, do on
call, get pulled out of bed at night when the shit hits the fan, and
are forced to maintain aging infrastructure, do more with less, are
worried about their jobs getting outsourced, etc.

In my firewalls (just like Jake's PLCs) I want more than one vendor
(for the same reason he does) and the Level 1 folks in an Enterprise
NOC the intricacies of SNMP MIBs are way over their heads. They need
red/green up/down maybe some some 0-100% gauge on utilization.
Enterprise application owners have just as little network knowledge as
their counterparts in EMS land....

But since I first saw Eric Byres presentation (and I raised my hand
and asked a  naive question, long before we did research together or
co-authored articles) on IT vs. Office at Joe's first SCADA conference
in Vancouver back in '03, there is a tendency to pick less than
mission critical IT components as a point of comparison with control
systems (Walt mentioned mail, although obviously some financial
transactions use SMTP and are often critical) which *can* suffer
downtime and have different availability requirements. Obviously there
is no comparison between common desktop IT (file, print, mail) and the
critical IT infrasture (datacenter, ecommerce, telco) where the
financial losses of outages could sometimes be on the same order of
magnitude (or exceed) those of production losses in a plant (but of
course do not have the same *physical* or safety implications)

There needs to be more technical overlap between "IT" people have some
hand-on experience with PLC, RTU, OPC Servers, etc just as Control
Engineers need to have some basic hands-on experience with routers,
switches, firewalls, etc. and I'm sure that is happening within
organizations that are seriously looking at these issues  (which is
different from folks shooting their mouths off on mailing lists,
blogs, conferences, and magazines articles)

At that point there can be productive technical discussions. Things
like are L4-7 load balancer (or WAN optimization gear) even suitable
for use in control system environments?For which applications and
protocols? Do the layer 2/3 QoS features available in Switches/Routers
suitable. How different are the traffic profiles between
Voice/Video/iSCSI/FCIP that are increasingly becoming common in the
Enterprise from Real Time Ethernet IO?


- mdf