In my house, I have a memorized security checklist. Each night, I make a nightly security parade. I go out and ensure the garage door is locked, then the deck, and finally secure the inside doors. I then extinguish the non-security outside lights and go up to bed.
I have to believe that somewhere in our vast treasure trove of antiquities there exists a stone tablet, papyrus, vellum or wall carving of some organization’s security checklist. Maybe there’s one in the Vatican’s extensive collection, or in the cache of the London Museum. Sometime in the dark, distant past, there existed security checklists just like the ones we have now. If you had something to protect, and your defenses were more than a hole under a rock, you likely made of checklist of safeguards.
How many movies have you seen or books have you read where a fortress’s seemingly insurmountable defenses were breached by a small group? The Trojans did it with a wooden horse. Other daring feats include crawling through unsecured sewers, secret passageways, and even access through what medieval English castle builders euphemistically called guarderobes. (I’ll let you look up that last one). The resourceful always seemed to find a way to breach even the most daunting physical obstacles. Were they on some ancient security team’s checklist?
Today, the U.S. government is looking for input to develop a new “framework” for assessing and managing security risks for information technology. The current guidance is a publication from the National Institute for Standards (NIST) that has an addendum with more than 800 entries to check — you know, a checklist. And that’s a lot of checking.
For nearly 15 years, the federal government wrestled with IT security standards by assigning security “grades” to a variety of IT components — operating systems, routers, applications and even protocols. The problems arose when all these elements were interconnected. There was no way assign an appropriate security “level” to the entire system when these components all had differing evaluations. It didn’t work.
In the most recent and updated editions of these standards, there is still an attempt to define hard boundaries around components that define what makes up an “IT system.”
For better or worse, these defined boundaries are being erased every day with cloud computing, bring-your-own-device, and telecommuting to name just a few examples. IT security is not a state and your data cannot be protected by a simple checklist.
IT security is a process. We would all be much better off defining the process to make our data defensible, and leaving the checklists to people defending castles.
John McCumber is a security and risk professional, and author of Assessing and Managing Security Risk in IT Systems: A Structured Methodology, from Auerbach Publications. If you have a comment or question for him, e-mail [email protected].
