Improved Event Logging for Security and Forensics: developing audit management infrastructure requirements
Atif Ahmad & Anthonie Ruighaver
University of Melbourne , Australia
Abstract
The design and implementation of audit configurations is often constrained by the audit management interface, which typically models operating system structures rather than real world behavior. This paper argues for the need for improved audit management technology as part of an overall top-down approach in the establishment of IT event-logging policies and practices. We propose that audit management technology should be improved to allow security administrators and forensic investigators to set event log configurations that reflect the security and forensic needs of an organization as defined in security policy. This paper outlines some of the necessary functionality that must be supported by audit management infrastructure in order to facilitate the collection and retention of event data appropriate for different types of real world behaviour.
Keywords: Event Logs, Auditing, Security, Forensics, Audit Configuration
Introduction
In the past, IT security in the corporate environment has often been the responsibility of systems administrators (Neumann, 1989) and, as a result, systems security has been a major focus. Within the context of systems security, audit logs have played an important role since they are the primary source of intrusion related information (Vaccaro, 1989). Hence, audit logs have traditionally been configured by systems administrators independently of corporate security policy, which even if it exists at all generally does not provide adequate guidance in setting up and maintaining security and audit configurations for IT systems.
Originally, the main use of audit logs was to monitor performance and to detect intrusions originating from an external source (Anderson, 1980). With the passage of time however, the term “intrusion” has begun to express a wider meaning closely related to security policy. Security policies have become more comprehensive and frequently include guidelines addressing acceptable behaviour. Any violation of the security policy will now be classified as an intrusion. Although developments in internet connectivity fuel the importance of using audit logs to detect violations of security policy and, more recently, to collect forensic data to support security objectives (Sommer, 1997), in practice event logging is often poorly configured or not configured at all (PWC, 2002).
Audit configuration has, until now, mainly been a bottom -up process. Audit management tools have unfortunately constrained the design and implementation of audit configurations due to their modelling of operating system structures rather than real world behaviour. We propose that audit management technology should be improved to
allow security administrators and forensic investigators to set event log configurations that reflect the security and forensic needs of an organization as defined in security policy. This approach ensures that audit configuration across the organization will be consistent to some degree, and supports the organization’s security objectives.
This paper begins by referring to a gap between stated objectives of organizational security policy and audit configuration of event logs which we reported in a previous paper (Ahmad, 2002). We briefly discuss the top-down approach we proposed to bridge this gap and will then identify the limitations imposed upon administrators by the audit management infrastructure currently available in most Operating Systems. Finally we will detail the main issues in the planning of event data collection and its subsequent management.
A Top-Down Approach Towards Improving Audit Management infrastructure
Where a corporate security policy exists, there is often a significant gap between the stated objectives of organizational security found in this security policy and the audit configuration of event logs present on systems. Even when the system administrator responsible for the configuration of the audit logs tries to adhere to the relevant objectives of the organization’s security policy, the translation of these objectives to a system audit configuration is far from straightforward. The ensuing configuration is frequently inaccurate and incomplete, resulting in insufficient and irrelevant data being collected.
To further complicate this process organizations are beginning to require the collection of forensic data for the purposes of litigation. Forensic data collection is the domain of experts; administrators generally do not retain the knowledge necessary to determine which sets of data must be selected to support the need for forensic data collection (Sommer, 1992). Furthermore the process by which data is collected and preserved must meet strict guidelines to be admissible in court. While these guidelines are known to specialists in this field, most administrators are not trained in issues related to the gathering and preservation of forensic data.
To reduce the gap between organizational security policy and audit configuration and to align the gathering of audit data with the organizational definition of “intrusion”, we proposed that organizations should develop an organization wide high-level audit policy (Ahmad, 2002). This document will set mandatory audit directives that support the organization’s security objectives and ensure that the security of systems will reflect the needs of the organization as defined in the security policy. These directives must stipulate the gathering of data for intrusion detection and/or forensic purposes (fig 1). Other organizational needs, like the collection of data for performance monitoring, may also be included in the audit policy. The aim of such a document is to provide administrators with a defined audit policy that can then be used to design audit configurations for various IT platforms, thereby maintaining consistency across the IT domain.
Figure 1: Top-Down approach towards translating security policy to event log configuration
The content and structure of the high-level audit policy will obviously not only depend on the organizational goals and objectives identified in the audit policy development process, but also on the capabilities and functionality of the Audit Mana gement Interface. As we will discuss in the next section, the current audit configuration interfaces and tools available in both the Unix and Windows operating systems are severely limiting the translation of audit policy objectives into a high-quality audit configuration. This forces the audit policy development process to take into account many low -level issues, making this process more complicated and costly as well.
The Need for an improved Audit Management Interface
The process of enforcing organizational policy objectives involves deciding upon a number of issues regarding the behaviour of users and systems in the corporate IT environment. For example, precisely what kinds of user behaviour must be audited? What kinds of real world events violate security policy? Once a comprehensive set of security policy violations is described, administrators can then configure systems to enable their detection.
The ability of an administrator to configure event logs on IT systems to identify security policy violations often relies upon the auditing interface and its underlying functionality provided by operating systems. These facilities are typically unable to efficiently map real world events to entries in the audit log. Instead, administrators are presented wit h a collection of switches representing operating system actions upon operating system objects. Hence administrators find themselves changing perspective to the complex and mechanical view of an operating system. Arising from the operating system view is a distinctly different set of questions such as what subjects, objects and actions must be audited? How much data is enough? How long must the data be kept? What protection
mechanisms must be in place to prevent availability, integrity, and confidentiality attacks?
Auditing user behaviour is made even more complex because not all the actions executed by a user-initiated process may be according to the user’s intention. Operating systems view activity in terms of three elements, subjects, objects and the actions initiated by subjects on objects (Denning, 1986). For example a process may have been created upon the direct instruction of a real world user and subsequently a number of actions may be executed before the process is terminated. From the view of the operating system the process (in this case the subject) is responsible for all actions committed. However, users frequently initiate processes whose subsequent actions are dictated by pre-arranged instructions (scripts, dlls, etc) written by third partie s. These actions may or may not be in accordance with the intentions of the user when he/she initiated the process. It is therefore difficult to distinguish between operating system actions that are intended by the user and those that are not.
Understanding user behaviour is even more difficult when there is no direct support in the operating system for the logging of user input events. Hence, when forced to view real world actions from the perspective of an operating system, investigators often find it difficult to identify a user’s intentions. Separating user intentions from system behaviour can be improved by collecting additional sets of audit data that links users to the actions they are directly responsible for. However, the precise audit configuration required to achieve this goal may be too complex for most administrators to conveniently design and implement without a well-designed high-level audit management interface.
To assist administrators in translating high level audit policy to audit configuration, operating systems must have an audit management interface that allows administrators to select suggested sets of audit data appropriate for certain types of real world behaviour via an easy to use management interface. High-level audit policies that incorporate intrusion detection must identify the types of behaviour that are considered intrusive or in violation of security policy directives. For example users running a certain combination of network applications at the same time or in sequence to access particular Internet sites may be violating security policy directives. Audit data collection for such types of behaviour may incorporate forensic as well as security elements. The precise set of data that must be collected is not easily determinable. Frequently administrators are unsure of what audit configuration to set and end up collecting considerable amounts of event data during the period when suspected users are expected to be exhibiting anomalous behaviour. Post-incident analysis becomes a time consuming activity after which the logs often reveal that a small percentage of relevant data was collected.
A useful audit management interface needs to assist administrators in controlling the type and amount of data they would like to record relating to real world events. The audit management interface must present the administrator with models of typical user behaviour often identified by audit policies as intrusive and suggest associated audit configurations. For example, the installation of software by a user may be a breach of the security policy. An audit management interface should allow administrators to select
“Log software installation”. As a result, the underlying event management infrastructure will be configured to collect at least the minimum acceptable amount ( base-line) of event information which satisfies security and forensic requirements:
Log username, date/time, copy of executable, workstation id, path
ON (minimum recommended status)
Registry Action Status
Log any changes to HKEY_LOCAL_MACHINE only
ON (minimum recommended status)
Log any changes to CURRENT_USERS OFF
Log all changes to the registry OFF
File Server Action
Log any changes to the system directory ON (minimum recommended status)
Log any changes to the file system OFF
….
Table 1: Sample base-line event logging for the violation “Attempt to Install Software”
Hence, at a minimum, selecting “Log software installation” will include the logging of the username, current date/time, workstation id. And any changes to the HKEY_LOCAL_MACHINE key of the registry and the system directory. Additional recommended options by security and forensics experts may be provided to facilitate additional event logging.
Issues to be Addressed by An Improved Audit Management infrastructure
Having extensively argued in the previous sections on the need for an improved Audit Management Interface, we will now discuss some of the functionality and requirements for such an interface. As shown in figure 2, we will discuss what is needed to support the selection of event data, the possible reduction of redundancy in this event data, what needs to be done to secure the event logs and finally how to manage the storage and retention of event logs.
Planning Event Collection
The collection of event data to log is the central issue facing administrators. Event data must reflect security and forensics guidelines and must detect and deter violations as well as providing evidence for forensic use. In the past administrators have exhibited a tendency to simply configure event -logging technology to record what might possibly be useful, without considering precisely what event data was needed as defined by security and forensic objectives.
Correct planning of event collection is more than just configuring the existing event-logging interface in the operating system. Frequently the set of event data that must be collected to meet each of the aforementioned requirements cannot be recorded by existing technology provided with the audit domain. In such a case administrators must implement additional gathering mechanisms to attempt to satisfy security and forensic requirements (figure 3).
Figure 3: Possible events generated by a computer system in a networked environment
There are a number of issues that relate to the collection of a minimum set of audit data that fulfils stated objectives (figure 4). For example, audit events may not provide sufficient context without related files (Schaen, 1991). Audit events may lack sufficient detail needed to provide a vivid picture of what may have happened, and the logs may not identify the real world incident in any useful way (Sommer, 1998). Recording that a file was modified by an unauthorized user at a particular date and time is useful however without preserving the before and after versions of the file it may be difficult to determine what the user was attempting to do to the content of the file.
Event data collection requires determining where in the operating system and network audit data may be found and when it is accessible. It is necessary for event data collectors to ensure that such data is not easy to manipulate within the operating system and that the data is securely retrieved into the audit log.
In general, the kinds of data that must be logged for each event are mentioned below (ACSP, 1998):
• Time and date of activities
• User ID
• ID of local terminal or remote computer
• System job number/process number
• Error conditions like failed attempts at executing a task
Figure 4: Event data acquisition environment
Reducing Event Data
The increasing size of hard disks and the decreasing cost of data storage have removed one of the main limitations of event logging. There is no real reason anymore to limit the size of the event logs and operating system performance should be the only remaining consideration in deciding how much event data should be generated. Future event-logging technologies can exploit this new situation and attempt to reduce overheads in the event -logging processes by applying more intelligence at the point where event data is generated. An example would be to allow the event logging procedure to make the final decision on whether a certain event needs to be logged based on either simple heuristics or based on the current “panic level” of the operating system.
With the main limitation on the size of event logs removed, the argument for audit reduction now focuses on the capacity of security and forensic personnel to read and make sense of lengthy audit logs. The execution of a single real-world action will frequently result in the recording of multiple sets of similar log records, which on further investigation may prove to be uninteresting and/or irrelevant. However, any changes in the pattern of these sets of log entries would definitely be of interest to an investigator and simply not recording these similar sets at all is definitely not acceptable
It may be possible to reduce the redundancy of an event log by analysing the generated audit records. The aim would be to combine several related events into a single new event that identifies particular real world behaviour in a meaningful way. This technique of replacing multiple log records that pertain to a single real world action is a useful way of increasing comprehension and reducing volume simultaneously. However it may be difficult to prove such processes to be forensically neutral (Sommer, 1998). It may also be difficult to demonstrate that the integrity of such reduction (and expansion) remains consistently sound.
Security
Audit management infrastructure must address the confidentiality, integrity and availability of audit data to the organization (Schaen, 1991). Access control, encryption and other controls may need to be enforced on collected audit data to prevent unauthorized access.
Event data progress through a lifecycle starting from the time of collection to time of retirement. During this timeframe the confidentiality, integrity and availability of the event data must be maintained rega rdless of the environment where it is kept. Whether it is stored in a part of the operating system, whether it has been integrated into a centralized database, or whether it is in transit to a court where it is to be presented. Operating systems typically rely on rudimentary access control mechanisms to protect event logs. Encryption may be used to protect the integrity of the event logs starting from the point of event collection (Schneier, 1999).
Issues regarding the security classification of audit data existing at varying degrees of sensitivity must also be addressed. In addition, logs may be related to each other based on the context in which they were recorded. Security classification must take into account the possibility that one log may contain information that may be relevant (and revealing) to another log of a higher sensitivity rating.
As a minimum audit management technology must include:
• Access control requirements on audit trails (Confidentiality, Integrity)
• Organizational procedures on obtaining access to audit trails and setting up sensitivity rating along with contextual relationships
Storage and Retention of Event Data
The Audit Management Infrastructure must provide controls to regulate minimum retention periods for sets of audit data. In addition, the possibility that the elimination of one set of audit data may affect the usefulness of another must also be taken into consideration.
Storage of audit logs must also be controlled as in whether logs should be stored locally or in a centralized location. Separation between security levels of data must be taken into
account as well as the impact of encryption on consolidation. Backup media itself must be protected and disposed off securely when retired (Schaen, 1991).
The statement below is a catch-all phrase that is frequently used in security policies to control the use of backup media, but it’s presence may not be sufficient to ensure that security administrators apply the same guidelines to audit data (ISP, 1997).
“All backup media will be stored in a safe, secure environment, in accordance with the manufacturer’s specifications. Media which has been used to store sensitive data will be disposed of securely and safely when no longer required.”
Audit infrastructure must control:
• The precise storage environment where audit data must be kept
• Whether audit data will be stored in a centralized location or distributed location
Conclusion
Traditionally, administrators have been responsible for the implementation of audit configurations on IT systems that support security directives established by the organization. However, frequently organizational security policies do not normally incorporate clear audit directives. This leaves the administrator with the task of interpreting security directives and using them to formulate system audit configurations. In addition operating systems constrain administrators when auditing intrusive behaviour that violates the security directives specified in organizational security policy. Operating systems view real world events from the perspective of its inner workings. Administrators are therefore forced to view user behaviour in terms of operating system subjects, objects and actions. The result of which is frequently an inadequate audit configuration that does not reflect the security policy set out by management.
To bridge this gap, the audit management interface to an operating system needs to allow administrators to select appropriate sets of audit data targeting the types of user behaviour considered intrusive by high-level audit policies. The collection of event data to log is the central issue facing administrators. Event data must reflect security and forensics guidelines that must be observed when collection is planned and event data is subsequently managed. A number of issues have been discussed pertaining to the selection, reduction, security, storage and retention of event data. Of these, support for planning, support for retention, and improved security must be taken into consideration when designing improved audit management infrastructure for security and forensic use.
References
Ahmad, A., and Ruighaver, T. (2002), A Top-Down Approach Towards Translating Organizational Security Policy Directives to System Audit Configuration, Proceedings of the 17th IFIP TC 11 International Conference on Information Security, Cairo, Egypt, 7-9 May, 2002.
Anderson, J. P. (1980), Computer Security threat monitoring and surveillance. Technical Report. James P. Anderson Co., Fort Washington, PA, April 1980.
Denning, Dorothy (1986), An Intrusion-Detection Model, IEEE Computer Society Symposium on Research in Security and Privacy, pp 118-31.
ISP (1997), Information Security Policy, University of New South Wales, 1997. P. W. C. (2002), Information Security Breaches Survey 2002, Technical Report, Price Waterhouse Coopers, 2002
Neumann, P., Parker, D. (1989), A Summary of Computer Misuse Techniques,
Proceedings of the 12th National Computer Security Conference, Baltimore, Maryland, 10-13 October, 1989.
Schaen, S., I.,McKenney, B.W. (1991), Network Auditing: Issues and Recommendations.
IEEE: 66-79.
Schneier B. and Kelsey J., Secure Audit Logs to Support Computer Forensics, ACM Transactions on Information and System Security, v. 2, n. 2, May 1999, pp. 159-176. Sommer, P. (1992), Computer Forensics: an Introduction, Compsec '92, Elsevier, 1992. Sommer, P. (1997), Downloads, Logs and Captures: Evidence from Cyberspace, Journal of Financial Crime, October, 1997, 5JFC2 138-152;
Vaccaro, H.S., Liepins, G. E. (1989), “Detection of anomalous computer session activity”, In 1989 IEEE Symposium on Security and Privacy, pages 280--289, Oakland, CA, USA, May 1989. IEEE Piscataway NJ USA.
Wee, C. (1996), Policy Directed Auditing and Logging, PhD Thesis, UC Davis, Dept. of Comp. Science, 1996.
