ORACLE provides a vast option for enabling audit. However most companies struggle to understand how to use the options and what options need to be enabled in order to be compliant. There is also the question of what are the audit options that need to be enabled without any compromise on the performance of the systems. The solution to that is to strike a balance between properly configuring auditing and only auditing appropriate tables that will not have any measurable performance impact and therein lays the challenge.
Below are some of pointers that organization should keep in mind in order to make best use of the options that ORACLE provides for audit and at the same time not compromise the performance.
Initial Steps
One of the most simple of ways to audit is to ensure that a basic set of audit trails is enabled all the time. These could be as basic as ensuring that system logs capture the user access and the privileges that are assigned to the various users. Also ensure that logs capture the changes that are being made to the database schema and the users who are making the changes. Although this may not be the most comprehensive of audits this will ensure that attacks can get detected and other detailed audits can be enabled.
Auditing Users
Oracle’s standard audit commands allow all system privileges to be audited along with access at the object level to any table or view on the database for select, delete, insert or update. Audit can be activated either for successful attempts or failures or for both. Audit trails can also be enabled for individual groups and it can also be done for groups or privilege levels. In case of an action level audit individual record is created per action. At a session level one record is created for all audit actions per session.
Tackling Performance Issues
The common misunderstanding is that enabling audit generally makes the system slower and affect performance negatively. Although this feeling may not be without reason, the real reason may also be unawareness of how to balance audit and performance. If all audit trails are enabled yes the performance may get affected. However it is also true that this will churn out an audit trial which really may not make too much sense. It will be extremely difficult to manage and interpret such huge amounts of data into something that can be used as an effective control mechanism. The key word factor here is to “Keep It Simple”. As mentioned earlier organizations need to identify the critical tables and for starters enable only audit trails only on those tables. In case any attacks are detected it can be probed further. So also for user level auditing. Organizations need to decide on wanting to turn on action level or session level audit without affecting the performance of the systems. Although too much may be said about performance it is also true that audit needs also need to be catered to and the balance between both is typically where organizations struggle.
Finally organizations should realize that there is no one standard one size fits all approach to auditing any application or database. What works for one organization may not be good for you and what used to work earlier may no longer be good today. With the growth of technology as well as cyber crimes you need to keep updating your triggers as well as audit trials. Row level audits may not be the solution to all audit questions. Management inclination for better audit is a must. It needs to be complimented by better reporting and governance structures in order to ensure that information is secure.
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5