Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 482
  • Last Modified:

oracle database auditing

I appreciate this falls into the realms of "it depends on company policy" etc. But when it comes to enabling auditing on oracle databases that process PII data, are there any best practices on what exactly you should be auditing, or what specific events you should monitor for access abuse/misuse, data theft etc. I didnt no whether there are any best practices in this area, or any examples on what you log and monitor in your databases.
0
pma111
Asked:
pma111
2 Solutions
 
Praveen Kumar ChandrashekatrDatabase Analysist Senior Commented:
0
 
DavidSenior Oracle Database AdministratorCommented:
Perhaps my best practice approach is to identify risk, and mitigate it -- not particularly an audit issue.  Or rather, one may turn on, and might even have the personnel to track, all manner of audit -- but that's not the target -- data integrity is, or should be.

Another view, auditing reports what happened, but doesn't do a blessed thing to prevent the attack from happening.

The sfisaca paper had a lot of marketing fluff but did mention some good points.  For example, data that is encrypted at rest, and encrypted in transit, is going to address the major part of your risk.  Hardening the system, and the network, to least access, follows next.  The U.S. federal government publishes their security technical implementation guides (STIG) at http://iase.disa.mil/stigs/ (unclassified).  Before a new server can be staged in production, for example, it is tested for federal best practices -- one of which, for example, is that the oracle installation user and o/s group must exclude the oracle DBAs.  The DBAs can read logs, etc., but don't need to modify nor execute the binaries.  

Another good point about the DISA checklist is that they provide gradients:  a category one violation is a showstopper to us; twos require a formal, management approved exception, and threes are more likely to be documented if they can't be resolved.  Under this approach one may focus upon covering (auditing) the risk of known weaknesses.

In some shops, developers may want a copy of production data in test and QA environments, so that they "can work with current conditions".  Non-production environments may relax security requirements -- no one willingly maintains a 16-character password every 30 days.......  As a former developer, I am aware of how easily Oracle can provide profiles and execution plans from production, and workload playback, to simulate those conditions.  In Oracle 12c, PII data can be (should be) masked and / or redacted to change PII data into simple random strings.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now