Re: audit response

I disagree with Brian, actually. Trust doesn't have to come into it, and if security is really needed, it shouldn't.

For example, in 9i Release 2, you can audit SYS actions (set AUDIT_SYS_OPERATIONS=TRUE). That produces a trace file at the O/S level, and one presumes that it would be possible (and sensible) to arrange for the file to be written to a directory to which the DBA doesn't have rights. In Windows, the audit trail thus produced goes into the Event Viewer... and again, one hopes that the DBA doesn't also have the ability to wipe that.

In other words, by separating the functions of sysadmins and DBAs, and by investing in the latest releases of the software, you *can* audit SYS activity, reliably and securely.

Sure, the DBA could modify the init.ora, and set the audit option to false... but then you make that a disciplinary offence.

Likewise, the routine auditing of everybody's SQL is easily done with AUDIT_TRAIL=DB. Sure, a privileged user could wipe the SYS.AUD$ table to remove the records. But if you create an audit policy such as 'audit delete on SYS.AUD$ by access', wiping AUD$ causes one new record to be added which reads 'JOE DELETED THE AUD$ TABLE!!'... and you'd never be able to get rid of that.

So there are technical ways to do it. And, more importantly perhaps, there are managerial approaches, to job differentiation and acceptable practice, which can do it, too.

In this day and age, any secure system that relies ultimately on trust isn't secure.

~QM

On 25 Jul 2003 11:46:42 -0700, Joe Kazimierczyk <joekazimierczyk_at_netscape.net> wrote:

> 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"
>

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/