The speaker lineup for the Embedded Online Conference is pretty amazing! Sign up with promo code GANSSLE90 and wonderful things will happen like reversal of male pattern baldness, a guest spot on Teen Vogue magazine, and a boost of what JFK called "vim and vigor." It will also get you $100 off the $190 registration fee (which goes up to $290 May 1).
By Jack Ganssle
Summary: Securing a system means a lot more than disconnecting it from the Internet.
Several people responded on-line to my article about SCADA security vulnerabilities (http://www.embedded.com/columns/breakpoint/224202612), and others wrote directly to me. A common thread seems to be "disconnect those machines from the Internet!" While I generally agree with the sentiment, there's more to security than installing an air gap.
One reader who wishes to remain anonymous wrote: "A few interesting thoughts, first disrespect leads to carelessness, carelessness leads to very bad things happening. For example 3Mile Island was caused by a person ignoring the warning systems and halting them from scramming the reactor automatically. They said "this can't be happening". [Note from Jack: That was also true at Chernobyl - experts just didn't believe an explosion was possible, even after the event.] "Tin whiskers on PCB's are another example - they can cause dangerous failures. This became a problem because again people became careless (letting politicians decide technical problems is always extremely dangerous ), they forgot why lead tin solder existed (tin whiskers were a known problem solved by using lead-tin solders). "Security is much the same. Before implementing any changes to a system one must decide what failures can happen with such changes. Vandalism, interference, system noise, etc, these are all contributing factors. People forget security isn't putting a chunk of armor on it or a lock box somewhere. Like 3 Mile Island, people must assume there will be unexpected failures and design workarounds. I myself assume that what I am designing is NOT going to work as expected, and I need to figure out what the failure modes will be before wasting ones employers money on it. "I think all of us can learn from the past in this case. Even software programmers can learn from simple things like locking the door (passwords), shutting the curtains (don't broadcast an available portal), turning on the outside lights (watch for intrusion methods and let the intruders know they are being watched). These are all lessons learned over thousands of years, history only repeats itself if we forget about it. Instead of 'common' sense, I believe I would use the word "wisdom of past failures". Many people fail to learn from others mistakes and repeat them as a consequence."
The last sentence of that paragraph summarizes the history of technology: we learn from disasters, if we chose. Alas, it seems the firmware community is way behind civil engineers at such learning, though.
The airwaves this week have been full of chatter about the Google attacks. Some analysts claim these are coordinated attempts by a foreign power. I wonder if anyone is looking for similar intrusions in our SCADA infrastructure? Published April 21, 2010