In the case of Terry Childs, a network admin who gained notoriety recently for locking the City of San Francisco and his managers out of their own critical network, comic-book style progress has been made, with Childs' attorney inviting the mayor of SF to a secret meeting at the jail, where Childs handed over the passwords he'd previously refused to disclose.
Childs' lawyer, again in typical comic book fashion, has also come out saying that Childs' actions were essentially noble and that he was acting to protect the network he built from his management and peers, whom he characterized as being neglectful and without the proper knowledge to support the network. About what you'd expect from a defense lawyer in a public case, I suppose.
But Childs is in no way a hero. Even if what he says is completely true, he's (allegedly) committed a real crime. He does not own that network even if he helped build it, and regardless of whether the management in his department was capable of exercising its responsibilities, when Childs locked everyone out he crossed a clear line. If it was to make a point, he simply went overboard. The whole unfortunate case just smacks of ego and manic behavior.
But from arm's length the city doesn't exactly look like a helpless victim, either. Any professional management team that creates an environment where one person can control a critical and sensitive network in the manner exercised in this case has missed some of the most crucial and common-sense aspects of IT and security design. In fact, most of the time when cases of one-man-too-much-power crop up, we find that the IT staff is also responsible for security with little or no separation of duties, no checks and balances, and no controls to ensure one bad apple doesn't ruin the whole barrel.
Was Childs right? Absolutely not. Was the City wrong? I don't see how you can argue otherwise.
You'd likely be surprised how many real-world computer networks - big and small, important and less so - are run on the concept of "we just trust that one guy." It's what we call a "Beer Truck" risk problem: If I'm that guy you trust, what if I get hit by a beer truck and killed, or alternatively what if I drink everything on that beer truck and go nuts and wipe out the network? What then?
Systems should be set up to ensure no one person holds all the keys. Over the past few days I've read comments made about this story, in many cases by angry IT-types who say if you hire someone you have to give them access to everything and you have to trust them to do the right thing. Otherwise they cannot do their job, you're a terrible person and your network and systems are doomed. That premise is simply and blatantly false, and in fact following that method puts you in the same boat the City of San Francisco has just found itself in. Please, don't listen to the old-skool IT admin crowd, telling you to hand it all over to them because you obviously don't know what you're doing. Fire those guys and find some real help.
If you want a healthier view of the situation, check out articles written by smart, thoughtful people, like this one by Paul Doyle. Also, Paul Venezia wrote an in-depth article about what went wrong, with some detailed inside information.
To be clear, no one person should control all the systems. Control and authority are not the same thing. Checks and balances are important. The Air Force doesn't allow one person to perform all the steps needed to launch a ballistic missile, right? Apply the same principles to your IT systems.
Case in point: I was the chief security executive at a major online financial services company. I had administrative access to nothing. I couldn't even get in the data center without an escort and records being kept. I had no account access to critical or sensitive systems. And no one person there could make changes in a vacuum. IT workers didn't have access to security systems. Security workers didn't have administrative access to anything by default. And we operated effectively, smoothly, with full knowledge of what was happening on the network and systems. No one person had control. Authority, sure. But actual control of systems? No. To operate otherwise would have been negligent.
I often preach the value of formalizing security management and putting proper process, technology and organization in place to ensure a good, stable system that can effectively support business. One of the pillars of an effective security management system is hiring good people (probably not ones who have been convicted of aggravated robbery in the past, sorry) and separating duties in a way that protects everyone involved - employees included. Doing so is not punishment, it's just good common sense.
If nothing else, lets hope businesses and governments all over learn from this embarrassing public spectacle. There are standards out there (my background and experience is in ISO 27001, an international security management standard), the very purpose of which is to make sure things like this don't happen. It's high time to start using them.
Member discussion: