Re: audit response

Brian,

That supports my own thoughts. We don't undergo background checks here, but I am thinking to document that we follow 'industry best practices' and that having administrator privileges comes with some accepted risks. Finding such supporting documentation is hard but I'm still looking.

Thanks,
joe

Brian Peasland <dba_at_remove_spam.peasland.com> wrote in message news:<3F213C5A.C94F3CD3_at_remove_spam.peasland.com>...
> I work as a contractor in a govt facility. And we've been undergoing the
> same sort of auditing of the security of our systems. At one point, we
> even had the NSA come in and do an audit, and then try to probe for
> security holes, both internally and externally. The NSA folks asked us
> all sorts of questions about the DBA's roles, privileges, and
> accountability. When questioned, we simply told our management that no
> system in our building does not have an entry point that has complete
> control over that system. There is SYS for Oracle databases, 'sa' for
> SQL Server, root for Unix servers, Domain Admins for Windows servers,
> etc. No matter what you do, knowledgable folks who have these passwords
> can circumvent any security measures that are put into place. So the
> management needs to trust those individuals. Eventually, someone has to
> have accountability for the system with little or no scrutiny. Someone
> has to be trusted, even if it is the president of the company. But then,
> we all go through extensive background checks here too.
>
> HTH,
> Brian
>
> Joe Kazimierczyk wrote:
> >
> > I almost hate to ask this question, but... we recently had an internal
> > audit, and as usual, the auditors cited that:
> >
> > - DBAs can edit or disable application audit trails
> > - DBAs can make unauthorized changes to application data
> > - adequate monitoring of DBA activity is not performed
> > - etc, etc, etc
> >
> > Our management has agreed to address this with more thorough and
> > freqent monitoring of suspicious DBA activity, etc. Now it's my task
> > to come up with a plan for how to do this. (I'm a DBA).
> >
> > DBA currently use personal privileged oracle accounts for most tasks,
> > but still have access to system or sys for the things that need it.
> > We use sudo from our personal accounts for unix access as oracle.
> > While this does help with the question of individual accountibility,
> > there are still ways around it for someone who is determined to do
> > bad.
> >
> > We currently have a good set of audit options enabled, and regular
> > reports showing privileged account usage and attempts to modify audit
> > options. We don't look at application audit trails, since there are
> > dozens of different apps each with their own way of auditing. I think
> > we already have good practices in place, but we realize that a DBA can
> > still do malicious things undetected if they wish to. So can our
> > unix admins, and even some application administrators.
> >
> > Does anyone have realistic ideas for how to address this audit point?
> > (Telling off the auditors is not an option). Other than producing
> > more audit reports which no one will realistically have time to
> > review, and would still not prevent a 'bad DBA' from doing whatever
> > they want, I'm really short on ideas. I may try documenting all of
> > the things that I considered to address their concerns, and why it's
> > not possible or practical to implement a solution, but I'm not sure
> > that that will go over well. Any other ideas would be very
> > welcome...
> >
> > --
> > Joe
> > http://www.joekaz.net/
>
> --
> ===================================================================
>
> Brian Peasland
> dba_at_remove_spam.peasland.com
>
> Remove the "remove_spam." from the email address to email me.
>
>
> "I can give it to you cheap, quick, and good. Now pick two out of
> the three"
Received on Fri Jul 25 2003 - 13:46:42 CDT