exception handling

[mike.patterson at unb.ca (Mike Patterson)]

Dave Hull wrote on 1/6/09 10:20 AM:
> On Mon, Jan 5, 2009 at 6:11 PM, Don Berry <don_berry at comcast.net> wrote:
> > Paper?
>
> I second. Document all exceptions on paper. Security shouldn't be the
> one making the call on exceptions. You want to push that to the
> affected business unit, or system owner that's asking for the
> exception. The people needing the exception need to be on the hook for
> it when something goes wrong as a result. Security's job is to present
> the vulnerability summary, explain what could happen as a result of
> the exception. Sometimes we push back on requests that we think are a
> really bad idea and these can escalate these all the way up to the
> executive management level, putting C-level execs on the hook.

We don't have a regular corporate-style setup here, this being a
university.  Exception requests are made and I've assumed for the
purposes of my question that we're granting the request.  But we still
need to be able to, in a year, go "wtf did we grant an exception there?"
and find the answer quickly and easily.  Paper does that, but only if we
happen to be in the same building.  Also, my manager needs to be able to
find the info, and vice versa.  (HIS manager isn't likely to care.)

Previously the security-d00d just kept it in his email archives.  Now
that he's gone, we no longer have access to them.  As it happens, I was
the one who made about 25% of the exception requests in the job I just
left, so I know what a lot of them are for, or can pull out *my* copy of
the email.  But that's not really helpful.

Anyway, thanks for the feedback, I was hoping that somebody was going to
say "oh, we use xyz for that, works great."  :-)

Mike