[SCADASEC] How to Tame Virtualization Sprawl

[Myrcurial]

Based on all of the Dilbert pieces I've seen regarding security, Scott
Adams must've spent time not only at the telco he admits to, but also
a large utility and a large financial -- these problems are endemic
where-ever you have a single company with 10,000+ workers and
especially when the empire building has been let to run rampant for
more than 50 years.

On the topic of virtualization -- I think it's partially in response
to the "one app / one server" mentality of the app developers -- it
seems they've forgotten moore's law -- after you've been up and
running for a few years and you do a hardware refresh, suddenly you've
got utilization rates in the single digit percentages.  This is
perceived as a way to more appropriately manage the investment in
hardware.

I think that it can make sense if you remember a few rules:

1/ works only if you commit to it and comprehend the sorts of single
contingency risks you're facing.

2/ thou shalt not span security zones within a single virtualization server

3/ two vm's on a single server are NOT redundant

4/ vm sprawl is just as bad - if not worse - than server sprawl.

Ultimately, we will return to wide scale implementation of
virtualization (notice I said return) as the methodology for operation
and containment was well understood in the Big Iron days.

If you haven't seen a properly designed VMWare + EMC Symmetrix do a
"VMotion" from one site to another without dropping the client
connection (2 or more TCP re-transmits required), you haven't seen
some of the best engineering to come out of silicon valley in a few
years.

Of course, properly designed and implemented is the same problem in
the IT world as in the Control world -- "experts" who really couldn't
find their way out of a wet paper bag with a CO2 laser.

~Myrcurial

On 2/14/08, Brodsky, Jake <jBrodsk at wsscwater.com> wrote:
> Man, this stuff is a hoot!  I'm not sure where Scott Adams gets his
>  inspiration from, but it is a wonderfully diseased place.
>
>  But seriously...
>
>  Remove the humorous props and ask yourself: is this what your boss is
>  thinking when people talk about virtualization?  What are we trying to
>  do here?  Minimize servers?  Because if that's all this is about, then
>  I'll come right out and say it: there aren't enough servers on a typical
>  plant to make it worthwhile ripping out what they have and replacing
>  them with these monsters.
>
>  Furthermore, we need to consider the failure modes.  Many plants have
>  redundant servers on various power supply and network subsystems so that
>  if one fails the other may still be left standing.
>
>  What I'm getting at is the number of servers isn't likely to change.
>  What CAN work well is that should one of the two servers go down, the
>  other instance can be run on the remaining server.  But the whole reason
>  for wanting two instances in the first place was so that there would be
>  a backup.  It serves no useful purpose to put both instances on the same
>  server.
>
>  Thus, I'm left to conclude that Virtualization may be good for
>  diagnostics, it may be good for testing patches.  But it isn't all that
>  useful in most SCADA systems for load balancing or that sort of thing.
>
>
>  Jake Brodsky
>
>
>
>  -----Original Message-----
>  From: scadasec-bounces at news.infracritical.com
>
> [mailto:scadasec-bounces at news.infracritical.com] On Behalf Of ljknews
>  Sent: Thursday, February 14, 2008 5:14 AM
>  To: scadasec at news.infracritical.com
>
> Subject: Re: [SCADASEC] How to Tame Virtualization Sprawl
>
>  At 12:01 PM -0500 2/13/08, ljknews wrote:
>  > At 10:35 AM -0600 2/13/08, Bob Radvanovsky wrote:
>  >
>  >> ** MODERATOR'S NOTE:  There was discussion about virtualizing control
>  and plant operations systems.  This article parallels some of the
>  concerns surrounding 'virtualization', which I don't feel, is ready for
>  primetime...yet.
>  >
>  > If you have trouble understanding virtualization projects,
>  > there are explanations available here:
>  >
>  >
>  http://www.dilbert.com/comics/dilbert/archive/images/dilbert201833620802
>  12.gif
>  >
>  http://www.dilbert.com/comics/dilbert/archive/images/dilbert200122241802
>  13.gif
>  >
>  > :-)
>
>  <STEVE_JOBS_MODE>
>
>  But wait, there's more:
>
>  </STEVE_JOBS_MODE>
>
>  http://www.dilbert.com/comics/dilbert/archive/images/dilbert200891681021
>  4.gif
>  --
>  Larry Kilgallen
>
>  _______________________________________________
>  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
>