Re: Security audit of Oracle databases

  • From: stephen booth <stephenbooth.uk@xxxxxxxxx>
  • To: Paula_Stankus@xxxxxxxxxxxxxxx
  • Date: Mon, 11 Apr 2005 14:41:13 +0100

On Apr 11, 2005 1:49 PM, Paula_Stankus@xxxxxxxxxxxxxxx
<Paula_Stankus@xxxxxxxxxxxxxxx> wrote:
> Guys,
> 
> I have a friend who is going to go through a security audit from an
> outside 3rd party.  He would like to verify his security before they
> come.  Does anyone know of any security opensource software for checking
> integrity of Oracle databases or scripts?

I don't know of any tools explicity for checking security/integrity of
Oracle databases, I have been audited a few times though.

Running export will check the basic integrity of the data, to speed it
up send the output to /dev/null unless you want an export file.

His best bet is to manually check the services that are running and
turn off any that aren't needed.  Similarly check all the usernames in
dba_users and make sure that none of the standard accounts have the
default password.  Last November Pete Finnigan posted the following to
this list:

> The Oracle default password lists can be found here:-
> http://www.petefinnigan.com/default/default_password_list.htm
> and the tool to check for default passwords can be found here:-
> http://www.petefinnigan.com/default/default_password_checker.htm

Check out those links.

It's scary the number of times I've been able to log into a database
as sys/changeoninstall, sys/manager, sys/oracle or sys/[databasename].
 Similarly the number of times I've been able to log onto a server as
oracle/oracle.

Then check what patches have been applied to the database vs what's
available and apply any that are needed or document why they haven't
been applied (remember, the aim here isn't to make the database more
secure it's to pass the audit, two very different things).  Get the
system admins to do the same for the OS, if you like them, otherwise
don't so that you can then deflect any blame onto them.

The most common insecurity problems with scripts are embedded
passwords and access to them by people who should have access to them.
 Scripts should only be accessible to the people who need to run them
(if you don't need to run them then you sholdn't even be able to see
them) and should not have passwords embedded in them.

Another password problem I've seen, especially on single DBA sites, is
that only the DBA knows the passwords.  What if he gets run over,
arrested on terrorism charges, rendered comatose, murdered or simply
goes on a 4 week holiday and is incommunicado?  All important
passwords should be recorded and stored somewhere safe (a piece of
paper in an offsite secure location  (e.g. where you keep your
disaster recovery backups).  BTW, of those 5 examples of why a DBA
might not be available, murdered is that only one that hasn't happened
to a DBA I know (the arrest was found to be an error and he was
released).

Obviously regular backups shold be taken *and periodically restore
tested* with disaster recovery backups stored off site.  One thing
that a lot of sites I've seen seem to miss is the security of the
backup tapes.  One site I worked at discovered that their confidential
financial and customer information was leaking to a competitor. 
Initially suspicsion fell on the DBAs and sysrtem admins, who were
eventualy cleared.  It turned out that the person who drove the backup
tapes from one site to another (about 60 miles away) was timing his
pickups so they happened at the end of the business day and so he
didn't deliver them till the following morning.  Over night the tapes
were being taken to a competitor's site and duplicated.  Until then
no-one had even thought to check how long it was taking for the tapes
to be moved from site to site, it was only discovered when a system
failure happened late in the evening (and entire RAID array died) so
the database had to be restored and it was discovered that the tapes
were not at either site.  This raises two important things:  If you
don't know where your tapes are then you can't restore from them; If
you don't know where your tapes are then you don't know who else might
have them.

Your friend also has to make sure that he gets a copy of the auditors
report when it is submitted, immediately, and reads it.  The auditors
will find problems, it's their job to do so and how they ensure repeat
business (if an auditor doesn't find any problems then managment will
tend to assume that they aren't very good auditors).  For every
problem they identify he needs to be able to respond with the reason
why it is how it is and a containment plan for the risk or a reason
why it's not a risk.

Stephen

-- 
It's better to ask a silly question than to make a silly assumption.
--
//www.freelists.org/webpage/oracle-l

Other related posts: