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.
Interesting turn of events at Ohio University last week as they suspended two
of their IT staff, a director and a manager, over
recent
break-ins in which thousands of records of sensitive personal information
may have been stolen.
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.
| Want
More Security? |
This
column was originally published in our weekly Security Watch
newsletter. To subscribe, click here. |
|
|
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.
About the Author
Russ Cooper is a senior information security analyst with Verizon Business, Inc.
He's also founder and editor of NTBugtraq, www.ntbugtraq.com,
one of the industry's most influential mailing lists dedicated to Microsoft security.
One of the world's most-recognized security experts, he's often quoted by major
media outlets on security issues.