NATIONAL COMPUTER SECURITY CENTER
FORT GEORGE G. MEADE, MARYLAND 20755-6000
NCSC-TG-001
Library No. S-228,470
_________________________________ 28 July 1997
Patrick R. Gallagher, Jr.
Director
National Computer Security Center
Acknowledgement is also given to the NCSC Product Evaluations Team who provided the technical guidance that helped form this document and to those members of the computer security community who contributed their time and expertise by actively participating in the review of this document.
The DoD Computer Security Center (DoDCSC) was established in January 1981 for the purpose of expanding on the work started by the DoD Security Initiative. Accordingly, the Director, National Computer Security Center, has the responsibility for establishing and publishing standards and guidelines for all areas of computer security. In 1985, DoDCSC's name was changed to the National Computer Security Center to reflect its responsibility for computer security throughout the federal government.
For Criteria classes C2 through A1 the Criteria requires that a user's actions be open to scrutiny by means of an audit. The audit process of a secure system is the process of recording, examining, and reviewing any or all security-relevant activities on the system. This guideline is intended to discuss issues involved in implementing and evaluating an audit mechanism. The purpose of this document is twofold. It provides guidance to manufacturers on how to design and incorporate an effective audit mechanism into their system, and it provides guidance to implementors on how to make effective use of the audit capabilities provided by trusted systems. This document contains suggestions as to what information should be recorded on the audit trail, how the audit should be conducted, and what protective measures should be accorded to the audit resources. Any examples in this document are not to be construed as the only implementations that will satisfy the Criteria requirement. The examples are merely suggestions of appropriate implementations. The recommendations in this document are also not to be construed as supplementary requirements to the Criteria. The Criteria is the only metric against which systems are to be evaluated.
This guideline is part of an on-going program to provide helpful guidance on Criteria issues and the features they address.
The audit mechanism of a computer system has five important security goals. First, the audit mechanism must "allow the review of patterns of access to individual objects, access histories of specific processes and individuals, and the use of the various protection mechanisms supported by the system and their effectiveness."(2) Second, the audit mechanism must allow discovery of both users' and outsiders' repeated attempts to bypass the protection mechanisms. Third, the audit mechanism must allow discovery of any use of privileges that may occur when a user assumes a functionality with privileges greater than his or her own, i.e., programmer to administrator. In this case there may be no bypass of security controls but nevertheless a violation is made possible. Fourth, the audit mechanism must act as a deterrent against perpetrators' habitual attempts to bypass the system protection mechanisms. However, to act as a deterrent, the perpetrator must be aware of the audit mechanism's existence and its active use to detect any attempts to bypass system protection mechanisms. The fifth goal of the audit mechanism is to supply "an additional form of user assurance that attempts to bypass the protection mechanisms are recorded and discovered."(2) Even if the attempt to bypass the protection mechanism is successful, the audit trail will still provide assurance by its ability to aid in assessing the damage done by the violation, thus improving the system's ability to control the damage.
"The users of the audit mechanism can be divided into two groups. The first group consists of the auditor, who is an individual with administrative duties, who selects the events to be audited on the system, sets up the audit flags which enable the recording of those events, and analyzes the trail of audit events."(2) In some systems the duties of the auditor may be encompassed in the duties of the system security administrator. Also, at the lower classes, the auditor role may be performed by the system administrator. This document will refer to the person responsible for auditing as the system security administrator, although it is understood that the auditing guidelines may apply to system administrators and/or system security administrators and/or a separate auditor in some ADP systems.
"The second group of users of the audit mechanism consists of the system users themselves; this group includes the administrators, the operators, the system programmers, and all other users. They are considered users of the audit mechanism not only because they, and their programs, generate audit events,"(2) but because they must understand that the audit mechanism exists and what impact it has on them. This is important because otherwise the user deterrence and user assurance goals of the audit mechanism cannot be achieved.
Logging in on a system normally requires that a user enter the specified form of identification (e.g., login ID, magnetic strip) and a password (or some other mechanism) for authentication. Whether this information is valid or invalid, the execution of the login procedure is an auditable event and the identification entered may be considered to be auditable information. It is recommended that authentication information, such as passwords, not be forwarded to the audit trail. In the event that the identification entered is not recognized as being valid, the system should also omit this information from the audit trail. The reason for this is that a user may have entered a password when the system expected a login ID. If the information had been written to the audit trail, it would compromise the password and the security of the user.
There are, however, environments where the risk involved in recording invalid identification information is reduced. In systems that support formatted terminals, the likelihood of password entry in the identification field is markedly reduced, hence the recording of identification information would pose no major threat. The benefit of recording the identification information is that break-in attempts would be easier to detect and identifying the perpetrator would also be assisted. The information gathered here may be necessary for any legal prosecution that may follow a security violation.
All systems rated at class C2 or higher shall have audit capabilities and personnel designated as responsible for the audit procedures. For the C2 and B1 classes, the duties of the system operators could encompass all functions including those of the auditor. Starting at the B2 class, there is a requirement for the TCB to support separate operator and administrator functions. In addition, at the B3 class and above, there is a requirement to identify the system security administrator functions. When one assumes the system security administrator role on the system, it shall be after taking distinct auditable action, e.g., login procedure. When one with the privilege of assuming the role is on the system, the act of assuming that role shall also be an auditable event.
The system design should include a mechanism to invoke the audit function at the request of the system security administrator. A mechanism should also be included to determine if the event is to be selected for inclusion as an audit trail entry. If pre-selection of events is not implemented, then all auditable events should be forwarded to the audit trail. The Criteria requirement for the administrator to be able to select events based on user identity and/or object security classification must still be able to be satisfied. This requirement can be met by allowing post-selection of events through the use of queries. Whatever reduction tool is used to analyze the audit trail shall be provided by the vendor.
Audit trail software, as well as the audit trail itself, should be protected by the Trusted Computing Base and should be subject to strict access controls. The security requirements of the audit mechanism are the following:
When the medium containing the audit trail is physically removed from the ADP system, the medium should be accorded the physical protection required for the highest sensitivity level of data contained in the system.
The ADP System Administrator should also be able to audit based on object identity.
The Trusted Computing Base should also provide the capability to audit the use of covert storage mechanisms with bandwidths that may exceed a rate of one bit in ten seconds.
Events that would indicate an imminent security violation would include events that utilize covert timing channels that may exceed a rate of ten bits per second and any repeated unsuccessful login attempts.
Being able to immediately notify the system security administrator when thresholds are exceeded means that the mechanism shall be able to recognize, report, and respond to a violation of the security policy more rapidly than required at lower levels of the Criteria, which usually only requires the System Security Administrator to review an audit trail at some time after the event. Notification of the violation "should be at the same priority as any other TCB message to an operator."(5)
"If the occurrence or accumulation of these security-relevant events continues, the system shall take the least disruptive action to terminate the event."(1) These actions may include locking the terminal of the user who is causing the event or terminating the suspect's process(es). In general, the least disruptive action is application dependent and there is no requirement to demonstrate that the action is the least disruptive of all possible actions. Any action which terminates the event is acceptable, but halting the system should be the last resort.
If a system developer chooses not to implement a general pre/post selection option, there is still a requirement to allow the administrator to selectively audit the actions of specified users for all Criteria classes. Starting at the B1 class, the administrator shall also be able to audit based on object security level.
There should be options to allow selection by either individuals or groups of users. For example, the administrator may select events related to a specified individual or select events related to individuals included in a specified group. Also, the administrator may specify that events related to the audit file be selected or, at classes B1 and above, that accesses to objects with a given sensitivity level, such as Top Secret, be selected.
Although it would not be recommended, the system security administrator may have the capability to select that no events be recorded regardless of the Criteria requirements. The intention here is to provide flexibility. The purpose of designing audit features into a system is not to impose the Criteria on users that may not want it, but merely to provide the capability to implement the requirements.
A disadvantage of pre-selection is that it is very hard to predict what events may be of security-relevant interest at a future date. There is always the possibility that events not pre-selected could one day become security-relevant, and the potential loss from not auditing these events would be impossible to determine.
The advantage of pre-selection could possibly be better performance as a result of not auditing all the events on the system.
The main advantage of post-selection is that information that may prove useful in the future is already recorded on an audit trail and may be queried at any time.
The disadvantage involved in post-selection could possibly be degraded performance due to the writing and storing of what could possibly be a very large audit trail.
Although the preference for several distinct audit trails may be present, it is important to note that it is often more useful that the TCB be able to present all audit data as one comprehensive audit trail.
If the audit trail storage medium is saturated before it is replaced, the operating system shall detect this and take some appropriate action such as:
Still another consideration is the speed at which the medium operates. It should be able to accommodate the "worst case" condition such as when there are a large number of users on the system and all auditable events are to be recorded. This worst case rate should be estimated during the system design phase and (when possible) suitable hardware should be selected for this purpose.
Regardless of how the system handles audit trail overflow, there must be a way to archive all of the audit data.
If a hardware device is available that permits only the writing of data on a medium, modification of data already recorded would be quite difficult. Spurious messages could be written, but to locate and modify an already recorded message would be difficult. Use of a write-once device does not prevent a penetrator from modifying audit resources in memory, including any buffers, in the current audit trail.
If a write-once device is used to record the audit trail, the medium can later be switched to a compatible read device to allow authorized personnel to analyze the information on the audit trail in order to detect any attempts to penetrate the system. If a penetrator modified the audit software to prevent writing records on the audit trail, the absence of data during an extended period of time would indicate a possible security compromise. The disadvantage of using a write-once device is that it necessitates a delay before the audit trail is available for analysis by the administrator. This may be offset by allowing the system security administrator to review the audit trail in real-time by getting copies of all audit records on their way to the device.
Although they are not necessarily part of the TCB, the audit reduction tools should be maintained under the same configuration control system as the remainder of the system.
For events which do require immediate attention, at the B3 class and above, an alert shall be sent out to the system security administrator. In systems that store the audit trail in a buffer, the system security administrator should have the capability to cause the buffer to be written out. Regarding real-time alarms, where they are sent is system dependent.
The audit trail should be reviewed at least once a week. It is very possible that once a week may be too long to wait to review the audit trail. Depending on the amount of audit data expected by the system, this parameter should be adjusted accordingly. The recommended time in between audit trail reviews should be documented in the Trusted Facility Manual.
At class B2 and above, it is required that all detected flaws shall be corrected or else a lower rating will be given. If during testing the audit trail appears valid, analysis of this data can verify that it does or does not accurately reflect the events that should be included on the audit trail. Even though system assurances may increase at the higher classes, the audit trail is still an effective tool during the testing phase as well as operationally in detecting actual or potential security compromises.
The Trusted Facility Manual shall also include a complete description of the audit mechanism interface, how it should be used, its default settings, cautions about the trade-offs involved in using various configurations and capabilities, and how to set up and run the system such that the audit data is afforded appropriate protection.
If audit events can be pre- or post-selected, the manual should also describe the tools and mechanisms available and how they are to be used.
Management should be aware of this risk and should be certain to exercise discretion when selecting the system security administrator. The person who is to be selected for a trusted position, such as the system security administrator, should be subject to a background check before being granted the privileges that could one day be used against the employer.
The system security administrator could also be watched to ensure that there are no unexplained variances in normal duties. Any deviation from the norm of operations may indicate that a violation of security has occurred or is about to occur.
An additional security measure to control this insider threat is to ensure that the system administrator and the person responsible for the audit are two different people. "The separation of the auditor's functions, databases, and access privileges from those of the system administrator is an important application of the separation of privilege and least privilege principles. Should such a separation not be performed, and should the administrator be allowed to undertake auditor functions or vice-versa, the entire security function would become the responsibility of a single, unaccountable individual."(2)
Another alternative may be to employ separate auditor roles. Such a situation may give one person the authority to turn off the audit mechanism, while another person may have the authority to turn it back on. In this case no individual would be able to turn off the audit mechanism, compromise the system, and then turn it back on.
If a mechanical or power failure occurs, the system security administrator should ensure that audit mechanisms still function properly after system recovery. For example, any auditing mechanism options pre-selected before the system malfunction must still be the ones in operation after the system recovery.
For classes C2 and above, it is required that the TCB "be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects."(1) The audit trail plays a key role in performing damage assessment in the case of a corrupted system. The audit trail shall keep track of all security-relevant events such as the use of identification and authentication mechanisms, introduction of objects into a user's address space, deletion of objects from the system, system administrator actions, and any other events that attempt to violate the security policy of the system. The option should exist that either all activities be audited or that the system security administrator select the events to be audited. If it is decided that all activities should be audited, there are overhead factors to be considered. The storage space needed for a total audit would generally require more operator maintenance to prevent any loss of data and to provide adequate protection. A requirement exists that authorized personnel shall be able to read all events recorded on the audit trail. Analysis of the total audit trail would be both a difficult and time-consuming task for the administrator. Thus, a selection option is required which may be either a pre-selection or post-selection option.
The audit trail information should be sufficient to reconstruct a complete sequence of security-relevant events and processes for a system. To do this, the audit trail shall contain the following information: date and time of the event, user, type of event, success or failure of the event, the origin of the request, the name of the object introduced into the user's address space, accessed, or deleted from the storage system, and at the B1 class and above, the sensitivity determination of the object.
It should be remembered that the audit trail shall be included in the Trusted Computing Base and shall be accorded the same protection as the TCB. The audit trail shall be subject to strict access controls.
An effective audit trail is necessary in order to detect and evaluate hostile attacks on a system.
Archive - To file or store records off-line.
Audit - To conduct the independent review and examination of system records and activities.
Auditor - An authorized individual with administrative duties, whose duties include selecting the events to be audited on the system, setting up the audit flags which enable the recording of those events, and analyzing the trail of audit events.(2)
Audit Mechanism - The device used to collect, review, and/or examine system activities.
Audit Trail - A set of records that collectively provide documentary evidence of processing used to aid in tracing from original transactions forward to related records and reports, and/or backwards from records and reports to their component source transactions.(1)
Auditable Event - Any event that can be selected for inclusion in the audit trail. These events should include, in addition to security-relevant events, events taken to recover the system after failure and any events that might prove to be security-relevant at a later time.
Authenticated User - A user who has accessed an ADP system with a valid identifier and authentication combination.
Automatic Data Processing (ADP) System - An assembly of computer hardware, firmware, and software configured for the purpose of classifying, sorting, calculating, computing, summarizing, transmitting and receiving, storing, and retrieving data with a minimum of human intervention.(1)
Category - A grouping of classified or unclassified sensitive information, to which an additional restrictive label is applied (e.g., proprietary, compartmented information) to signify that personnel are granted access to the information only if they have formal approval or other appropriate authorization.(4)
Covert Channel - A communication channel that allows a process to transfer information in a manner that violates the system's security policy.(1)
Covert Storage Channel - A covert channel that involves the direct or indirect writing of a storage location by one process and the direct or indirect reading of the storage location by another process. Covert storage channels typically involve a finite resource (e.g., sectors on a disk) that is shared by two subjects at different security levels.(1)
Covert Timing Channel - A covert channel in which one process signals information to another by modulating its own use of system resources (e.g., CPU time) in such a way that this manipulation affects the real response time observed by the second process.(1)
Flaw - An error of commission, omission or oversight in a system that allows protection mechanisms to be bypassed.(1)
Object - A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are: records, blocks, pages, segments, files, directories, directory trees and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, network nodes, etc.(1)
Post-Selection - Selection, by authorized personnel, of specified events that had been recorded on the audit trail.
Pre-Selection - Selection, by authorized personnel, of the auditable events that are to be recorded on the audit trail.
Security Level - The combination of a hierarchical classification and a set of non-hierarchical categories that represents the sensitivity of information.(1)
Security Policy - The set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information.(1)
Security-Relevant Event - Any event that attempts to change the security state of the system, (e.g., change discretionary access controls, change the security level of the subject, change user password, etc.). Also, any event that attempts to violate the security policy of the system, (e.g., too many attempts to login, attempts to violate the mandatory access control limits of a device, attempts to downgrade a file, etc.).(1)
Sensitive Information - Information that, as determined by a competent authority, must be protected because its unauthorized disclosure, alteration, loss, or destruction will at least cause perceivable damage to someone or something.(1)
Subject - An active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. Technically, a process/domain pair.(1)
Subject Sensitivity Level - The sensitivity level of the objects to which the subject has both read and write access. A subject's sensitivity level must always be less than or equal to the clearance of the user the subject is associated with.(4)
System Security Administrator - The person responsible for the security of an Automated Information System and having the authority to enforce the security safeguards on all others who have access to the Automated Information System.(4)
Trusted Computing Base (TCB) - The totality of protection mechanisms within a computer system -- including hardware, firmware, and software -- the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a TCB to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user's clearance) related to the security policy.(1)
User - Any person who interacts directly with a computer system.(1)
1. National Computer Security Center, DoD Trusted Computer System Evaluation Criteria, DoD, DoD 5200.28-STD, 1985.
2. Gligor, Virgil D., "Guidelines for Trusted Facility Management and Audit," University of Maryland, 1985.
3 Brown, Leonard R., "Guidelines for Audit Log Mechanisms in Secure Computer Systems," Technical Report TR-0086A(2770-29)-1, The Aerospace Corporation, 1986.
4. Subcommittee on Automated Information System Security, Working Group #3, "Dictionary of Computer Security Terminology," 23 November 1986.
5. National Computer Security Center, Criterion Interpretation, Report No. C1-C1-02-87, 1987.