Tuesday, July 13, 2010

Policy liability

Watching our office's thoroughly indispensible Sys. Admin. attack a problem is always a thing of wonder. Today was an especially good example, riding shotgun through the debugging of email not being sent by a new Linux development server (set up safely inside our network). In the end, the fix boiled down to two options:

A.) Open a ticket with the (swamped) corporate I/T folks to white-list the test server and wait an indefinite amount of time
B.) Shunt mail off to an email relay under our control and have a fully-functional application ready to demo by next Monday

Gee, bet'cha can't guess which option we chose, huh? Fortunately, Sys. Admin. knows his stuff: Frankly, I'm flat-out embarassed to have ever held a similar title. Thus, it's not a big deal from a security standpoint. But it does highlight the rationale for hiring good I/T folks, keeping them close to the folks they enable, and giving them a wide swath of latitude for exercising their judgment.

Think that I/T (and their pesky habit of asking for more hardware) is merely overhead? Here's a not-unlikely scenario. Suppose that space on a network hard drive is rationed (because hard drives cost money, don't'cha know) and/or I/T isn't supposed to "waste time" setting up limited group access to specific resources. (Absurd, but does it ever happen!) Network hard disk usage stays under its cap: Good job--here's a cookie.

Except that a middling Windows-savvy employee who needs to make files available merely has to share her/his hard drive (or a folder on that drive) to make it available to people with whom they need to collaborate. If the network uses the standard Active Directory setup, absolutely anyone--not just their collaborators--on their network should be able to see whatever they share. Definitely not a good security scenario, that...

What's worse, though, is that if only network drives are being backed up (which is typically the case), if the person sharing files ever loses that hard drive to corruption, bad hardware, etc., the data (and productivity) on which others were relying are gone, quite possibly forever. Oops. Guess it would have made more sense to let I/T spend fifteen extra minutes to give someone and extra five bucks' worth of hard drive space, hey?

The fundamental problem with policy (in which I include overly-formalized processes)--in my biased and considerably less than humble opinion--is that it's almost always geared at a lowest common denominator. When the upper percentiles in skill level are saddled with those limitations, they will probably flout the rules altogether. Which in itself is probably no great harm, except that it also leaves the middle. By which I mean the kind of folks who might've learned a trick at their previous company or picked something up from one of the "technorati," only without the context of when it is and isn't appropriate.

That's a dangerous scenario. And if it blows up, I certainly can't spare any pity. Because it's not a technical failure: It's a failure of leadership and innovation.