Virtualization and SCADA, mini-SCADAs

Ever feel like a broken record? I get that feeling when "my" last 2 good post ideas came from following the crowd. Looking back, I haven't yet posted on SCADA security in response to the flurry of blog activity on the topic and the alleged "SCADA Internet attacks on the power grid" where the CIA keeps coming up - again and again. I've seen how the media quotes "the government", my 19 year old Seaman recruit sailor was "A Navy Spokesperson". The reporter was attractive - he didn't stand a chance.

Well, this post is supposed to be about Virtualization, an old topic in computing with renewed vigor! Other bloggers are talkin' about it, so why shouldn't I? The basic idea behind virtualization in this context is to work on logical hardware in a bit of a sandbox. Another nice feature is working from images (snapshots) instead of entire hard drives and machines. Imagine building your HMI exactly how you want, then taking a snapshot. With virtualization, you can run multiple instances of this. Your SCADA installation is an image file that can be run on any computer! Maybe you want to consolidate hardware, or maybe you want a similar environment for your QA department, or for development. The concept of "create once, use many" applies here.

Unless you're a software developer or running a computer lab, it's probably your servers that have the most to gain from virtualization. Servers are notorious for being resource underutilized, and are often fickle - how many of you would be comfortable "cutting over" most of the services that any one of your servers provide to another machine? You might not mind installing something new on a server, but I doubt that you nonchalantly move things around on production machines.

Let me paint a picture. You're starting a sizable new plant from scratch. You decide to buy a single $50k server from Dell as the main workhorse. It will be running "8 servers", (domain controller, database, web, email, etc) each with their own: memory, IP address(es), etc. Once the system is up, you decide that you don't want to install anything without testing it first. Fine, you use the same image on a different machine, install and test the software, then copy that image onto 'ol beefy. Suppose your email server needs more memory - you simply assign 4 gigs of the 32 total to that "instance" instead of 2. Now suppose that you're supporting something that's architecturally heavy, like Wonderware or RSView via thin clients on a Terminal Server. All of a sudden you need most of the processing power of your beast. Well, you can "move" instances to other servers. If we take this one step farther, you can actually have a virtualized infrastructure that would allow you to add hardware without changing anything. This type of setup can be cheaper, more flexible, and efficient than its traditional counterpart.

So we've covered how virtualization helps with servers in general. It can be a big help in supporting legacy HMI/SCADA technologies. It's really good for programs that are tough to configure (ah choo-Linux setups-oo). It seems less important for FactorySQL and FactoryPMI - they're already pretty good about being easy to install or move and having a lightweight footprint - especially on the client end with Java Web Start. You could set up a virtualized "production" and "testing" environment, both on the same computer, but this is pretty pointless since each installation would be better separate, and each could support the entire network on a desktop PC. I could see bigger setups greatly benefit from running virtualized instances.