A governance perspective on security audit policy settings
The task of establishing and configuring audit policies is usually left to security experts and/or system administrators who are in charge of implementing security configurations, particularly in small-to-medium enterprises with a lean IT structure. There is usually not much guidance on how these configurations are to be managed.
One common mistake that administrators make is failing to define adequate audit trails to enable early detection of security threats and allow for related investigations. The main reason for this oversight is a failure to balance audit trail needs and systems capacity. Some administrators argue that excessive auditing results in production of huge amounts of event logs that are unmanageable.
Deciding on what to audit and what not to audit, or what may or may not be omitted, is therefore not just a configuration task, but rather a risk assessment task that should be embedded in the governance structures of the organization’s IT security frameworks.
Risk assessment process over audit requirements
The audit needs of the organization are guided by the regulations, security threat models, information required for investigations and IT security policy to which the organization is subjected. Identification of the possible threats that the organization faces is usually carried out as part of risk assessment. Security events derived from audit policy settings are key risk indicators that the organization should use to measure how vulnerable the system is to the identified threats. It is therefore critical that enabling audit policies should not be taken casually.
System auditing should be considered across the platforms the organization uses – that is, operating systems, databases and applications. Due consideration of what information is obtained from the operating system (OS) against databases and/or applications should be used to streamline the volume of audit data collected and to safeguard servers’ storage capacity. Where the organization decides not to record audit trails at any of the system levels – that is, OS, databases or applications – an impact analysis should be carried out to ensure that the costs of missing such logs are quantified against regulation penalties and organizational risk appetite.
In order to facilitate the systematic review of an organization's audit needs, guidelines should be developed and approved at the appropriate level in accordance to the governance structure of each organization. Having a guideline that outlines the audit policy objectives, risks, threats and data collection points will ensure that adequate audit logs are maintained. This will, in turn, facilitate log monitoring for suspicious events and allow for detailed investigations if the need arises.
The guidelines should not only focus on configuration of audit settings but should also provide guidance on the steps that are to be followed when procuring log management software to manage event logs. Different log management software is designed to meet logging needs of different organizations, and as such, software procured should be in line with the audit objectives and needs of the organization. The one-size-fits-all concept should not be applied.
The configurations of audit policies across the organization platforms should be a secondary task implemented through clear guidelines that promote risk assessment of the organization’s audit needs.
(This post originally appeared on the ISACA blog site, which can be viewed here).