Security auditing architecture
- 2. What is Security Auditing? Security auditing is a form of auditing that focuses on the security of an organization’s information system (IS) assets. 2
- 3. Security Auditing Security auditing can – Provide a level of assurance concerning the proper operation of the computer with respect to security. – Generate data that can be used in after-the-fact analysis of an attack, whether successful or unsuccessful. – Provide a means of assessing inadequacies in the security service. – Provide data that can be used to define anomalous behavior. – Maintain a record useful in computer forensics. 3
- 4. Security Audit Terminology Security Audit – An independent review and examination of a system’s records and activities to determine the adequacy of system controls, ensure compliance with established security policy and procedures, detect breaches in security services, and recommend any changes that are indicated for countermeasures. Security Audit Trail – A chronological record of system activities that is sufficient to enable the reconstruction and examination of the sequence of environments and activities surrounding or leading to an operation, procedure, or event in a security-relevant transaction from inception to final results. 4
- 5. Security Auditing Architecture We begin our discussion of security auditing by looking at the elements that make up a security audit architecture. First, we examine a model that shows security auditing in its broader context. Then, we look at a functional breakdown of security auditing. ITU-T2 Recommendation X.816 develops a model that shows the elements of the security auditing function and their relationship to security alarms. 5
- 6. Security Audit and Alarms Model 6
- 7. Event discriminator: This is logic embedded into the software of the system that monitors system activity and detects security-related events that it has been configured to detect. Audit recorder: For each detected event, the event discriminator transmits the information to an audit recorder. The model depicts this transmission as being in the form of a message. The audit could also be done by recording the event in a shared memory area. Security audit trail : The audit recorder creates a formatted record of each event and stores it in the security audit trail. Alarm processor: Some of the events detected by the event discriminator are defined to be alarm events. For such events an alarm is issued to an alarm processor. The alarm processor takes some action based on the alarm. This action is itself an auditable event and so is transmitted to the audit recorder. 7
- 8. Audit analyzer: The security audit trail is available to the audit analyzer, which, based on a pattern of activity, may define a new auditable event that is sent to the audit recorder and may generate an alarm. Audit archiver: This is a software module that periodically extracts records from the audit trail to create a permanent archive of auditable events. Archives: The audit archives are a permanent store of security-related events on this system. Audit provider: The audit provider is an application and/or user interface to the audit trail. Audit trail examiner: The audit trail examiner is an application or user who examines the audit trail and the audit archives for historical trends, for computer forensic purposes, and for other analysis. Security reports: The audit trail examiner prepares human-readable security reports. 8
- 10. Figure shows a breakdown of security auditing into six major areas, each of which has one or more specific functions: Data generation: Identifies the level of auditing, enumerates the types of auditable events, and identifies the minimum set of audit-related information provided. This function must also deal with the conflict between security and privacy and specify for which events the identity of the user associated with an action is included in the data generated as a result of an event. Event selection: Inclusion or exclusion of events from the auditable set. This allows the system to be configured at different levels of granularity to avoid the creation of an unwieldy audit trail. Event storage: Creation and maintenance of the secure audit trail. The storage function includes measures to provide availability and to prevent loss of data from the audit trail. 10
- 11. Automatic response: Defines reactions taken following detection of events that are indicative of a potential security violation. Audit analysis: Provided via automated mechanisms to analyze system activity and audit data in search of security violations. This component identifies the set of auditable events whose occurrence or accumulated occurrence indicates a potential security violation. For such events, an analysis is done to determine if a security violation has occurred; this analysis uses anomaly detection and attack heuristics. Audit review: As available to authorized users to assist in audit data review. The audit review component may include a selectable review function that provides the ability to perform searches based on a single criterion or multiple criteria with logical (i.e., and/or) relations, sort audit data, and filter audit data before audit data are reviewed. Audit review may be restricted to authorized users. 11
- 12. Requirements for security auditing The first requirement is event definition. The security administrator must define the set of events that are subject to audit. A second requirement is that the appropriate features must be available in the application and system software to enable event detection. Next is needed an event recording function, which includes the need to provide for a secure storage resistant to tampering or deletion. Event and audit trail analysis software, tools, and interfaces may be used to analyze collected data as well as for investigating data trends and anomalies. 12
- 13. Implementation Guidelines The ISO3 standard Code of Practice for Information Security Management (ISO 27002) provides a useful set of guidelines for implementation of an auditing capability: 1. Audit requirements should be agreed with appropriate management. 2. The scope of the checks should be agreed and controlled. 3. The checks should be limited to read-only access to software and data. 4. Access other than read-only should only be allowed for isolated copies of system files, which should be erased when the audit is completed or given appropriate protection if there is an obligation to keep such files under audit documentation requirements. 13
- 14. Implementation Guidelines 5. Resources for performing the checks should be explicitly identified and made available. 6. Requirements for special or additional processing should be identified and agreed. 7. All access should be monitored and logged to produce a reference trail; the use of time stamped reference trails should be considered for critical data or systems. 8. All procedures, requirements, and responsibilities should be documented. 9. The person(s) carrying out the audit should be independent of the activities audited. 14
- 15. 15
Editor's Notes
- #10: Audit trail collector: A module on a centralized system that collects audit trail records from other systems and creates a combined audit trail. Audit dispatcher: A module that transmits the audit trail records from its local system to the centralized audit trail collector.