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.

In the process of conducting an IT Audit, the auditor needs to confirm whether a specific IT General Control (ITGC) is operating effectively.  In order to verify this, a combination of procedures needs to be utilized. These include but are not limited to inquiry, observation, inspection of evidence obtained from the performance of the ITGC. The IT Auditor also needs to identify the critical controls. Critical controls can be identified by looking at applications that support controls for significant accounts with a higher risk of material misstatement.

The manual or automated nature of an ITGC can have an impact on the evidence available to support the functioning of the ITGC and the nature of the audit process needed to obtain reasonable assurance regarding whether the ITGC is operating effectively through period of the audit. It should be noted that in addition to evidence available regarding the performance of the ITGC, it is essential to obtain evidence regarding the effectiveness of the control as well.

The population to be used for selecting a sample and the evidence used to support automated ITGCs should be systematically generated from the relevant technology source. If system-generated evidence cannot be obtained, other additional procedures will be needed to verify the effectiveness of the controls.

It is possible that the same ITGC exists for multiple applications of the IT environment; here it might be possible to select a single testing sample for the entire population of items affected by the ITGC. While testing, one must consider that the testing is being conducted by process rather than by technology and therefore the sample selected must be consistent in that direction. This approach allows the auditor to lower the number of samples while still testing for relevant applications and other components of the IT environment. 

The period over which ITGCs are to be tested will vary depending upon the type of ITGCs being tested, policies related to the ITGC as also the frequency with which the controls operate. For example, some controls operate continuously (e.g. password configuration settings applied to an application) while others operate periodically (User access reviews).

Conclusion:

While performing testing of ITGCs, it is important to note that if the auditor relies to a greater degree on the given ITGC, it will be essential for the auditor to obtain greater confidence that the given ITGC is operating appropriately and effectively through the audit period.