The security discussion Bob Lewis and I are having on this page reminds me of one of the categories my local video store
has for its movies (see "
Keep security in-house
").
This particular video store ignores the usual conventions of "action," "drama," and "comedy" in favor of more esoteric classifications.
One of the more creative categories lends itself nicely to this debate: "one-man army." You know the genre: Someone like Chuck
Norris is dropped into a jungle, where he manages to single-handedly fight off battalion after battalion of enemy troops and
local evil-doers to rescue some of his old war buddies from a POW camp. By the end of the movie, everyone is safely back on
American soil sporting a few Band-Aids and eating heaping helpings of apple pie.
In my opinion, organizations (especially those with a small staff, as Bob notes) that try to manage all security matters
in-house are the IT equivalent of Chuck Norris parachuting into hostile territory -- short a few rounds of ammunition. Your
organization will most certainly need reinforcements when it comes to security. To be successful at managing security, your
staff needs to understand all layers of the problem: physical, network, application, and operating system. These issues must
be managed continually regardless of business hours, holidays, or vacations because the volume of potential security issues
mounts daily. Just today, I checked the BugTraq mailing list (
http://online.securityfocus.com/archive/1
), which is the place to keep up with security alerts, and already there are nine vulnerabilities listed, covering issues
that span a wide variety of operating systems and applications: BIND, Internet Explorer, a Perl module, SNMP, Solaris, and
many more. And it's still early in the day as I write this. As Web services take hold, auto-updating software will make it
even more challenging to keep up with what you are running.
None of this means that a CTO or CIO should hand off security to a third party and forget about it. As Bob notes, "watching
the watchers" is critical to success, and as most intelligent IT people know, your relationships with key outsourcers must
be tended to almost as carefully as your relationships with your internal staff. The internal staff needs to clearly communicate
perceived vulnerabilities to the outsourcer since the internal staff knows what systems are running, and for what purposes.
Bob does make a valid point about achieving the security/functionality balance with an outsourcer, but I find that striking
this balance is sometimes difficult even when managing security with internal staff. Mark it up as a perennial IT problem.
I have to agree with Bob that IT needs to make the business and its functions more effective, but the "one-man army" approach
is a lot more entertaining on the silver screen than in the corporate datacenter. Engaging a capable security outsourcer is
a good idea for the long term.