Cloud Strategies for Automation – Part 2 of XX – Squashing Stuxnet with Clouds

Recently I had the joy of listening to Kim Zetter’s (@kimzetter)  book Countdown to Zero Day.  In it she recaps how Stuxnet was able to infect the Natanz facility and the ingenious methods it used to manipulate the software and processes, namely replacing a key dll in the Siemens software stack to manipulate data between the S7 processor and the engineering workstation.  As someone who is thinking more and more, at least in public forums, about security I thought how would I have defended against this.  The thought that comes to mind is persistence… or lack thereof.  What if our operator and engineering workstations had no persistence?  In other words what if every time we started them up we got a completely fresh copy, perfectly configured.  When we shut down the image we were working on is destroyed and our next session is a new machine.  This is not a totally foreign idea and with the likes of technologies such as Docker and VMware Horizon (with View) most of the really hard parts have been solved.  Instead I think it might just take getting the right infrastructure in place and then working out the finer points.

Before you go all factual on me I am well aware of the fact that Stuxnet jumped from box to box and there is no guarantee that destroying and recreating some engineering workstations would have eradicated the virus but it’s more a thought experiment.  What if we didn’t worry about persistent viruses because every time we started up received a freshly minted OS that has been well protected, patched, and thoroughly scrubbed?  Also by definition you couldn’t have an APT because you have no persistence?  At least on your workstations.  We can address servers in a different light later.

I’m interested in your thoughts on the matter.

Oh, and I’m very proud of myself for sticking to a short post length.. this is good 🙂


Cloud Strategies for Automation – Part 1 of XX

Over the course of the next XX posts, mainly because I have no idea how many posts I will make about this topic, I’d like to lay out my thoughts on cloud computing as it relates to our industry.

Before I begin there is one point I should make crystal clear.  When I say cloud I am referring to a general set of technologies that focus on two key areas.  First, a cloud based system should allow you to simply say “I need to spin up another data server” and after a few checkbox and dropdown selections your new server is up and running with all of the required software in a standard, validated, and repeatable manner.  In an ideal world it is so easy you actually forget how to install the software manually.  I liken it to loading CD-ROM drivers by hand to install Windows 95.  Can you do that today?  No because it is all done for us.  Second is a focus on the pets vs. cattle concept.  Here is a good article introducing the concept.  I won’t waste my time rehashing.  In our automation systems we need more cattle, fewer pets.  As you move down the stack closer to Layer 0 (yes I call it layer 0.. the actual physical process) this gets much more difficult but we can sure get down to at least Level 2 in the ISA S-95 model.  Level 1 would be theoretically possible with the advent of new electronic marshalling concepts where the I/O is decoupled from the controller and the backplane but we’ll leave that for another day and another discussion.

So before you get all flustered and frothing at the mouth ready to shred me I said nothing about public vs private vs hybrid vs on site vs hosted vs offsite vs unicorns.  I think too many people confuse the concepts of cloud computing with using a credit card for a few AWS machines.  Instead I will discuss cloud as a set of enabling technologies, not any specific implementation of those technologies.

And with that, let’s get started.


A new approach to posting – the mini post

I was introduced to Seth Godin by an EMC Executive, Chad Sakac a few years ago.  His social presence on the web was very inspiring but even more impressive to me was the attitude of his team.  I remember one particular exchange, I believe it was on a podcast, where one of his former direct reports made a statement that went something like “Once an EMC specialist, always a specialist.  This guy is my brother and even though we don’t work for the same company anymore I will do anything for him, anytime.”.  Chad led a team of virtualization specialists at EMC, an enterprise storage company, that was affectionately dubbed “Chad’s Army”.  And the statement by one of his former employees really made me think about working in a place that developed a sense of brotherhood and trust similar to what one must experience when they are in the armed services and especially after going into battle with each other.  While I have never served I have played football and I can say that it’s difficult to explain to someone who has never been there what it means to know that you will go down fighting for that peer to your left and to your right.  Why would you do this?  Because they would do the same for you.  And why would they do the same for you?  Because the two of you have “been in the trenches” and “bled” together.  For the purely technical folks, if you have every been on a death march project or had to put in late night after late night to solve a problem that has been kicking everyone’s tail you know a similar feeling.  So all of that is a long form introduction to a question I asked Chad a few years ago and he was gracious enough to answer.  I wanted to know what his favorite books were on the topic of leadership.  At the time I was ascending to my own leadership role, although not in title but certainly in deed.  I wanted what he had.  His immediate response was Tribes: We Need You to Lead Us, by Seth Godin.  If you are a leader or aspire to be a leader this book is a must read.  It may even be so good you should read it once every few years.

So what does all of this have to do with the title of my post? If you read Seth’s blog you should immediately notice something atypical.  Almost all of his posts are very short.  Nothing like what I am used to posting in years past.  Sometimes a good blog post would take me multiple days between interruptions and research to confirm technical accuracy.  You know what happens to people like me?  They don’t have enough time to keep up posts like that and eventually their posts just start to fade away and the blog dies.

So with that in mind, and humbly accepting the fact that I will never be as cool as Seth or Chad, I am going to embark on my own journey of miniature blog posts with a single idea that’s more of a thought and less of a thesis.  At this point in my career I think I’ve passed the stage of feeling like I have to wow everyone with my technical prowess.  Not saying it’s so good that I don’t even need to prove it, but more along the lines of looking for engagement moreso than approval.

Let’s see how it goes.