Oracle security maintenance and monitoring

I have been asked to identify some best practice "post implementation" (i.e. DB servers in production) routine security maintenance and monitoring tasks that a good DBA should be performing on routine basis. I was thinking along the lines of ensuring latest patches applied, occasional vetting DB level accounts and permissions once per quarter, ensuring no config changes have been made outsid change cotnrol etc. Can you give some pointers on any self audits you do to routinely reverify the security configuration of your Databases, and how often you do such checks.

Who is Participating?

1. There are templates available to audit a system for irregularities, such as directory permissions, grants, your "routine" hardening. I am partial to the DoD's STIG guidance, searchable on the web. A STIG audit might be (should be?) run as part a new deployment, or similar change to your production environment.

2. If you can run OEM, or Grid Control, there are many, useful event and threshold triggers scripted in. Quest's FOGLIGHT is similar, and others. I am far more productive, letting my system alert me to a problem, rather than to manually run maintenance scripts and scan the output.

3. What does the customer require -- and is willing to pay for? We all have to decide what risk (versus cost) is acceptable.

4. My personal fave: when was the last time the different recovery plans and scripts were tested? A "typical" DBA might check that backups completed -- but that's a small part of the picture. You should be able (and willing) to stand up your environment, in full, and to ensure that the time and effort was acceptable to management and client.

I appreciate there are hare hardeninig guides for when building systems, but I was more after what security checks you still need to perform after build stage when its put into production. It cant be a case of build in line with best practice and "set it and forget it".

Many, many directions for that point to be pursued <smiles>. All systems may be hacked, given sufficient resources. Perhaps the biggest gap after a breech is to determine not just that data may have been changed, but to validate that no latent bugs were planted. For example, the users' profiles have a package to control password rules. During a backup recovery, who checks to confirm that the package hasn't changed?