Just a week or two ago, I heard about a security conference where the organizers inadvertently distributed a virus-infected USB stick to the attendees. Of course, everyone was shocked and amazed, and I’m sure the organizers put the fire out quickly and professionally.
(I won’t bother naming/embarrassing the conference because, let’s face it, it could have been any of “us,” right? There but for the grace of…)
When I heard about the infection, I immediately—ok, after I stopped giggling—thought back to similar incidents with tainted commercial software media circa 1990 or so.
I asked myself: how could this happen in 2008?
Seriously, how could this happen in 2008? Was it an act of ignorance?
I think not, these guys are truly good, despite the momentary lapse. Was it an act of hubris? I seriously doubt it? Complacency, perhaps? I just don’t know, but I think the situation is worth exploring a little deeper, and worth looking beyond this one unfortunate incident.
If you’ve ever sat through one of the classes I teach, you’d probably recognize a Keynote slide I use often. The slide contains an old photo of the Tacoma Narrows Bridge collapsing in November 1940 (Watch the YouTube video here). The caption I use reads, “We’re really bad at learning from history.”
We are really bad. I can’t think of a single other discipline that is so gosh darned pathetic at learning from its mistakes. Perhaps it’s my engineering degree and background. Perhaps it’s from growing up around the aviation industry, with a retired 747 pilot for a father. But I’ve watched other disciplines and seen that those guys study their failures and improve from them.
Isn’t that a novel concept?
Think about it for a bit in the context of information security. The world saw a major buffer overflow in a C program on November 2nd, 1988 in the form of the so-called “Internet Worm.” The buffer overflow was in the Berkeley UNIX finger daemon program, and it and a couple other problems enabled Robert T. Morris’s worm program to rapidly spread across the Internet.
Just a few months later, the Communications of the ACM, a highly respected academic journal, published an entire edition devoted to analysis of the worm and its aftermath. I remember working at another university at the time and thinking, “this is great stuff; now we all understand buffer overflows and won’t see any more of those in our software.”
Boy, was I naïve.
In a more modern context, consider cross-site scripting (or “XSS”) attacks on web applications, SQL injection, or just about any of the OWASP Top-10 list of web application vulnerabilities (see http://www.owasp.org).
We keep making the same mistakes over and over. How can that be?
Are we even too stupid to come up with new mistakes? I sure hope not.
So, to help us get into the right frame of mind, and to stop dwelling on how dumb we all are, let’s consider a couple simple but positive steps we can take—starting right now—to prevent the same problems from cropping up time after time.
1.) Study and learn.
Do you give your techies and software developers the time to learn security lessons? Training is a good starting point, but it has to go beyond that. They also have to learn. (It’s the difference between transmitting and receiving.)
If you work with web technologies, start by getting them each a copy of OWASP’s free WebGoat and WebScarab tools, and have every one of them work through every single exercise in WebGoat. In the training I do, I’ve found no more effective learning tool than this excellent piece of free software from OWASP. Do it. No excuses.
2. Use checklists.
Here’s the son of a pilot part of me showing up, I suppose, but checklists are vital. For all the repeated, mundane tasks you do—perhaps producing USB sticks for conference attendees, or putting together software you’re selling to your customers—come up with a simple checklist and follow it.
Make sure you’re following a 2-person rule in following the checklist: one person checks and the other person verifies and marks each step completed.
Sounds tedious, doesn’t it? Well, I can assure you infecting your customers—or conference attendees—with malware or some other nasty is anything but tedious, at least for the first 24 or 48 hours. After that, it might become tedious when your customers go to your competitors.
So, if it’s excitement you crave, don’t bother with checklists. Don’t bother learning from history. None of this stuff is for you. It is mundane. It can be downright boring.
But next time you’re reading about your company and your former customers on CNN, perhaps you’ll start to yearn for the tedium. At the very least, I’m willing to bet your customers will prefer it.