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 glasssome 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 messbut 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 keysoften called "k of n" sharing, after the usage in the 1979 paper by Adi Shamir of MIT that originated the ideato let some subset of a trusted group unlock critical assets when an individual asset owner cant or wont do it.
Encryption and backup go hand in hand. Click here to read more.
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 firstname.lastname@example.org.
Check out eWEEK.coms for the latest news, reviews and analysis on IT management from CIOInsight.com.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.