Re: Security audit of Oracle databases

On Apr 11, 2005 1:49 PM, Paula_Stankus_at_doh.state.fl.us <Paula_Stankus_at_doh.state.fl.us> 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.
--
http://www.freelists.org/webpage/oracle-l