Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: audit response
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 - 09:19:06 CDT