Some Observations About Audit Trails

Feb 06, 1998

Abstract

Computer systems harbor valuable information and resources, and losses can be sustained through natural disaster, hardware malfunction, faulty software, user mistakes, or malicious misuse, a list in roughly decreasing order by ease of detection. Since techniques do not exist to completely eliminate any of these categories of risk, provisions must always be made for detection and recovery after the fact.

Enough information must be at hand to answer the questions: Is something bad happening? What? What failed, allowing it to happen? What data or resources were damaged or compromised, and how should recovery proceed? If malice is involved, evidence may also be needed to support prosecution. A comprehensive system activity log, or audit trail, is a valuable source of such information. Usually, software provided with an operating system determines the format of the log and contributes the bulk of its content.

No single format has been widely adopted across systems; even within the UNIX world, logs are vendor-specific. Consequently, software packages that scan logs to detect problems are closely tied to specific systems, even though many forms of mistake or misuse can be described in more general terms (e.g. exploitation of a time-of-check-to-time-of-use flaw in a program with amplified rights). The duplication of development effort affects cost and time-to-market of detection tools, and a proliferation of similar but incompatible tools ill serves the administrators of heterogeneous systems.

Should a standard format be proposed, it should address deficiencies of existing formats, some of which have been identified in prior COAST research. Many are related to inherent trade-offs between completeness of the log, economy of storage, and speed of processing, which do not have Right Answers but engineered compromises which, ideally, suit local configuration and policy. A proposed standard should be flexible enough to accomodate various compromises.

In January 1997, a working group with representatives from several organizations began to develop a Common Intrusion Detection Framework (CIDF). The proposal is still in the works and the working group welcomes comments. We will talk about the status of the project and the issues it does and (so far) doesn't address.