As I hiked into our final campsite, above Gem Lake in Californias Ansel Adams Wilderness, the three Boy Scouts whod gotten there ahead of me pointed out an appalling mess. Scattered over an area that we later estimated at 2,000 square feet were chips and splinters of broken glass—some of it in pieces large enough to be identifiable as fragments of beer and liquor bottles, combined with other evidence suggesting a session of drunken pistol practice. It wasnt a pleasant sight as we neared the end of a 30-mile backpacking week.
After lunch, our six-man party went over the site, a few square yards at a time, collecting what turned out to be about 8 pounds of glittering garbage to carry out the next day. That gave us almost an hour and a half to trade witty insults concerning the kind of people who do this kind of damage. One of the Scouts, toward the end of the effort, then added the thought that gave rise to this column: “It probably took only a couple of minutes to make this mess, but youd need a week to clean up every last bit.”
Our backpack trips always end with a group discussion of “lessons learned,” and that seems like a lesson worth applying to many places other than the wilderness.
Anyone whos tasked with any kind of asset protection should be especially aware of asymmetric threats: things that can cause expense or time loss hugely out of proportion to the size of an innocent mistake or to the effort involved in a deliberate attack. Whether youre protecting your systems and yourself against accident or malice, looking for such asymmetric situations can be a good way to focus your efforts.
One sharp-edged example that immediately comes to mind is the threat created by crypto proliferation. During the last few years, a huge number of IT elements have incorporated some kind of encryption facility to maintain security or privacy or as part of a digital rights management scheme. Todays essentially unbreakable crypto algorithms, used casually and without proactive management, are pistol shots in the gallery of crucial data.
A document thats encrypted by a user who later turns out to be either unavailable or uncooperative is obviously a potentially time-consuming mess—but how many sites take the logical step to protect themselves against this threat? Do you have in place the password-cracking tools or an established account with a password-cracking service to recover a Word document or other such asset when an unwelcome “password” prompt comes up on the screen?
Better still, Id argue that no enterprise system should allow end-user password assignment to anything unless theres a fallback to some hierarchical master-password system. If you dont like the idea of any one party having access to everything in the store, use a system of split master keys—often called “k of n” sharing, after the usage in the 1979 paper by Adi Shamir of MIT that originated the idea—to let some subset of a trusted group unlock critical assets when an individual asset owner cant or wont do it.
For that matter, even a cooperative user may not be able to gather up the shards of an encrypted file. Paul Rubin, a celebrated GNU hacker and contributor to the widely used Emacs text editor, once described a crypto trap that users could spring on themselves with the text editor known as “ed.” Rubin noted that the “x” command in some versions of that program would invoke a mini screen editor, but the same command in other versions would encrypt and save the file.
“You hit a bunch of keys at random to see why the system seems to have hung; you dont realize that the system has turned off echo so that you can type your secret encryption key,” Rubin wrote, adding, “Ive seen people try for hours to bang the keyboard in the exact same way.”
To some extent, everything that Ive said so far is a critique of passwords in particular rather than crypto in general. Broader use of tokens or biometrics would mitigate some of these issues, but they would not eliminate the need for considered management of privileges.
There are lots of good reasons to use crypto pervasively and deeply in enterprise systems. Plan ahead, though, to avoid someones pulling a trigger that turns useful data into rigorously randomized trash.
Technology Editor Peter Coffee can be reached at [email protected].