Security Watch

Whose Responsibility Is It, Anyway?

Keep records of your security recommendations to management or you might be left holding the short end of the stick.

• By Russ Cooper
• 06/28/2006

The story seems to stand out as somewhat unique because of the level of the people being suspended. One might expect to hear that some worker bee was let go and management was left intact. I don't have any details beyond what was reported, but it would seem to me that the university put the blame where it most likely should've been placed -- with the decision makers.

Certainly there are instances where some staff hadn't done his or her job, or purposely altered something so as to create significant risk, but more often than not the risk comes from exceptions.

As worker bees, we have all run into situations where we've warned that a system has been granted more access than it needs; the rules have been loosened to accommodate a project, individual or department that absolutely can't live without unfettered access. We cringe and cross our fingers and hope it doesn't result in our worst-case scenario.

We cringe because we know full well that should something bad happen, we'll be the ones blamed, as if it's our fault they bought an application that has to run as Administrator or requires Microsoft file sharing ports opened to the world! We're always blamed for being too draconian in our approach and not appreciating the need.

Of course, we know they aren't appreciating the risks.

For their part, they don't want to know about the risks, they just want to hear what we're going to do to eliminate them -- without taking away their precious access, of course.

It's this impasse that should create the exception.

The exception documents the risks you've identified, what mitigations you've been able to put in place, and the business reasons the risk must be present. All the worker bees sign off, and it gets passed up the management chain for review and signatures. It should then be reviewed regularly, by all parties, to ensure the business drivers still outweigh the risks, and to look for new mitigation strategies.

Exceptions can be used for many things, from documenting lax firewall rules to acknowledging that your priorities aren't being acted upon. More importantly, they're your explanation when a bad thing occurs.

Some of you might be laughing at the idea of getting all of the signatures and review to happen. Several years ago I attended a meeting at the White House in which corporate executives were reminded that they had fiduciary responsibility for the security in their companies. The reminder was intended to be a wake-up call to these execs that they can be held personally responsible for the actions of those reporting to them on the security of their networks. So there should already be a vested interest in exception reports.

So, if you're a security person, pay attention and keep copious notes from management when they refuse the protective measures you recommend. They may make the difference between a paid vacation and a few weeks of unpaid leave.