Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: audit suggestion

Re: audit suggestion

From: <>
Date: Mon, 24 Jan 2005 10:52:52 -0800
Message-id: <>

A few comments inline below...

| wrote:

|>We just completed an external audit and one of the findings from the
|>auditors is that DBAs should not have cron rights in Unix.

This just confirms our impression that they're making things up as they go along. No auditor has ever suggested this to us.

|Let me start with moderate and reserved statement that your auditor is
|an idiot. Actually he or she
|is an idiot to the fifth degree, but I am not allowed to say that.

|> The finding
|>basically stated that a DBA could schedule something to run malicious code
|>from cron and therefore is a security threat.
|Of course, being able to connect as sysdba does not enable him to do
|anything dangerous to anything other then to the company data. He
|neglected to mention the danger coming from the auditors having IQ
|smaller then the shoe size. Also, there is a package that "it" has
|apparently never heard of: DBMS_JOB which allows the DBA to
|do pretty much the same thing without ever running cron.

One thing here...I think we have to be cautious and not volunteer too much information or it'll just give them more ideas. They would go into shock if they knew that all the oracle DB account password gyrations don't prevent "connect internal" or "/ connect as sysdba". I actually had one include "connect internal" as part of his password checks and get excited when the oracle os account logged in WITHOUT a password prompt. Huh?? I did manage to calm him down (I hope) by demonstrating that an account not in the right group would be prompted for a password. But then he wanted to make sure the password would expire and be changed on a regular basis...sheesh..


|> Frankly, I don't see how
|>that's much different from just running the script interactively. Unless
|>the DBA is kicked off the Unix server period.....
|This was a Microsoft sales person in disguise. His recommendation is
|that you don't need a DBA.
|Oracle database allegedly has sufficient artificial intelligence to
|offset the human stupidity. That, I am
|afraid, is not the case.

|>I'm curious if other sites have restricted DBA's access to such a point
|>that they no longer are allowed to develop and promote shell scripts for
|>databases. This is supposed to be a 'segregation' of duties, but it seems
|>to me that if you are going to run a script that is in the 'DBA' group
|>then what's really happened is that access is now opened up to the UNIX
|>administrators (considering they are a separate job).

|Technical auditors are supposed to be qualified persons. Unfortunately,
|management frequently hires "well known" auditing companies like DLJ
|which have so many audits that they cannot event begin to cover them
|with even moderately technically competent auditors, so they cover some
|of the "audited" companies with incompetent cheap morons. Management
|should insist that the DBA auditing the company have OCP and five years
|of provable experience in the field. So many of those "auditors" are
|blithering idiots who all behave in the same way: they keep quiet and
|mysterious, first "documenting" everything and then making
|I was once able to challenge an auditor that opened his mouth and let me
|know that he has 6 months of experience
|with Oracle RDBMS and yet he was doing audits. Your auditor was
|obviously a bird of the feather. I would advise against following his
|recommendations. Your company management should create a ruckus at the
|auditing company HQ and require either a technically competent auditor
|or their money back. SoX and HIPAA auditing has become a "grab the money
|and run" type affair.
|If you want to hear what I really feel, contact me privately, but this
|should suffice.

|Mladen Gogala
|Oracle DBA
|Ext. 121


Received on Mon Jan 24 2005 - 14:12:07 CST

Original text of this message