NCSC-TG-001
VERSION-2
NATIONAL COMPUTER SECURITY CENTER
A GUIDE TO
UNDERSTANDING
AUDIT
IN
TRUSTED SYSTEMS
1 June 1988
NATIONAL COMPUTER SECURITY CENTER
FORT GEORGE G. MEADE, MARYLAND 20755-6000
NCSC-TG-001
Library No. S-228,470
This publication, "A Guide to Understanding Audit in Trusted Systems," is
being issued by the National Computer Security Center (NCSC) under the authority
of and in accordance with Department of Defense (DoD) Directive 5215.1.
The guidelines described in this document provide a set of good practices
related to the use of auditing in automatic data processing systems employed
for processing classified and other sensitive information. Recommendations
for revision to this guideline are encouraged and will be reviewed biannually
by the National Computer Security Center through a formal review process.
Address all proposals for revision through appropriate channels to:
- National Computer Security Center
- 9800 Savage Road
- Fort George G. Meade, MD 20755-6000
- Attention: Chief, Computer Security Technical Guidelines
_________________________________ 28 July 1997
Patrick R. Gallagher, Jr.
Director
National Computer Security Center
Special recognition is extended to James N. Menendez, National Computer
Security Center (NCSC), as project manager of the preparation and production
of this document.
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.
CONTENTS
- FOREWORD
- ACKNOWLEDGEMENTS
- PREFACE
- 1. INTRODUCTION
- 1.1 History of the National Computer
Security Center
- 1.2 Goal of the National Computer Security
Center
- 2. PURPOSE
- 3. SCOPE
- 4. CONTROL OBJECTIVES
- 5. OVERVIEW OF AUDITING PRINCIPLES
- 5.1 Purpose of the Audit Mechanism
- 5.2 Users of the Audit Mechanism
- 5.3 Aspects of Effective Auditing
- 5.3.1 Identification/Authentication
- 5.3.2 Administrative
- 5.3.3 System Design
- 5.4 Security of the Audit
- 6. MEETING THE CRITERIA REQUIREMENTS
- 6.1 The C2 Audit Requirement
- 6.1.1 Auditable Events
- 6.1.2 Auditable Information
- 6.1.3 Audit Basis
- 6.2 The B1 Audit Requirement
- 6.2.1 Auditable Events
- 6.2.2 Auditable Information
- 6.2.3 Audit Basis
- 6.3 The B2 Audit Requirement
6.3.1 Auditable Events
- 6.3.2 Auditable Information
- 6.3.3 Audit Basis
- 6.4 The B3 Audit Requirement
- 6.4.1 Auditable Events
- 6.4.2 Auditable Information
- 6.4.3 Audit Basis
- 6.5 The A1 Audit Requirement
- 6.5.1 Auditable Events
- 6.5.2 Auditable Information
- 6.5.3 Audit Basis
- 7. POSSIBLE IMPLEMENTATION METHODS
- 7.1 Pre/Post Selection of Auditable Events
- 7.1.1 Pre-Selection
- 7.1.2 Post-Selection
- 7.2 Data Compression
- 7.3 Multiple Audit Trails
- 7.4 Physical Storage
- 7.5 Write-Once Device
- 7.6 Forwarding Audit Data
- 8. OTHER TOPICS
- 8.1 Audit Data Reduction
- 8.2 Availability of Audit Data
- 8.3 Audit Data Retention
- 8.4 Testing
- 8.5 Documentation
- 8.6 Unavoidable Security Risks
- 8.6.1 Auditing Administrators/Insider
Threat
- 8.6.2 Data Loss
- 9. AUDIT SUMMARY
- GLOSSARY
- REFERENCES
Throughout this guideline there will be recommendations made that are not
included in the Trusted Computer System Evaluation Criteria (the Criteria)
as requirements. Any recommendations that are not in the Criteria will be
prefaced by the word "should," whereas all requirements will be prefaced
by the word "shall." It is hoped that this will help to avoid any confusion.
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.
The main goal of the National Computer Security Center is to encourage the
widespread availability of trusted computer systems. In support of that
goal a metric was created, the DoD Trusted Computer System Evaluation Criteria
(the Criteria), against which computer systems could be evaluated for security.
The Criteria was originally published on 15 August 1983 as CSC-STD-001-83.
In December 1985 the DoD adopted it, with a few changes, as a DoD Standard,
DoD 5200.28-STD. DoD Directive 5200.28, "Security Requirements for Automatic
Data Processing (ADP) Systems" has been written to, among other things,
require the Department of Defense Trusted Computer System Evaluation Criteria
to be used throughout the DoD. The Criteria is the standard used for evaluating
the effectiveness of security controls built into ADP systems. The Criteria
is divided into four divisions: D, C, B, and A, ordered in a hierarchical
manner with the highest division (A) being reserved for systems providing
the best available level of assurance. Within divisions C and B there are
a number of subdivisions known as classes, which are also ordered in a hierarchical
manner to represent different levels of security in these classes.
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.
An important security feature of Criteria classes C2 through A1 is the ability
of the ADP system to audit any or all of the activities on the system. This
guideline will discuss auditing and the features of audit facilities as
they apply to computer systems and products that are being built with the
intention of meeting the requirements of the Criteria.
The Trusted Computer System Evaluation Criteria gives the following as the
Accountability Control Objective:
- "Systems that are used to process or handle classified or other sensitive
information must assure individual accountability whenever either a
mandatory or discretionary security policy is invoked. Furthermore,
to assure accountability the capability must exist for an authorized
and competent agent to access and evaluate accountability information
by a secure means, within a reasonable amount of time and without undue
difficulty."(1)
The Accountability Control Objective as it relates to auditing leads to
the following control objective for auditing:
- "A trusted computer system must provide authorized personnel with
the ability to audit any action that can potentially cause access to,
generation of, or effect the release of classified or sensitive information.
The audit data will be selectively acquired based on the auditing needs
of a particular installation and/or application. However, there must
be sufficient granularity in the audit data to support tracing the auditable
events to a specific individual (or process) who has taken the actions
or on whose behalf the actions were taken."(1)
Audit trails are used to detect and deter penetration of a computer system
and to reveal usage that identifies misuse. At the discretion of the auditor,
audit trails may be limited to specific events or may encompass all of the
activities on a system. Although not required by the TCSEC, it should be
possible for the target of the audit mechanism to be either a subject or
an object. That is to say, the audit mechanism should be capable of monitoring
every time John accessed the system as well as every time the nuclear reactor
file was accessed; and likewise every time John accessed the nuclear reactor
file.
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:
- (1) The event recording mechanism shall be part of the TCB and shall
be protected from unauthorized modification or circumvention.
- (2) The audit trail itself shall be protected by the TCB from unauthorized
access (i.e., only the audit personnel may access the audit trail).
The audit trail shall also be protected from unauthorized modification.
- (3) The audit-event enabling/disabling mechanism shall be part of
the TCB and shall remain inaccessible to the unauthorized users.(2)
At a minimum, the data on the audit trail should be considered to be sensitive,
and the audit trail itself shall be considered to be as sensitive as the
most sensitive data contained in the system.
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.
This section of the guideline will discuss the audit requirements in the
Criteria and will present a number of additional recommendations. There
are four levels of audit requirements. The first level is at the C2 Criteria
class and the requirements continue evolving through the B3 Criteria class.
At each of these levels, the guideline will list some of the events which
should be auditable, what information should be on the audit trail, and
on what basis events may be selected to be audited. All of the requirements
will be prefaced by the word "shall," and any additional recommendations
will be prefaced by the word "should."
The following events shall be subject to audit at the C2 class:
- Use of identification and authentication mechanisms
- Introduction of objects into a user's address space
- Deletion of objects from a user's address space
- Actions taken by computer operators and system administrators and/or
system security administrators
- All security-relevant events (as defined in Section 5 of this guideline)
- Production of printed output
The following information shall be recorded on the audit trail at the C2
class:
- Date and time of the event
- The unique identifier on whose behalf the subject generating the event
was operating
- Type of event
- Success or failure of the event
- Origin of the request (e.g., terminal ID) for identification/authentication
events
- Name of object introduced, accessed, or deleted from a user's address
space
- Description of modifications made by the system administrator to the
user/system security databases
At the C2 level, the ADP System Administrator shall be able to audit based
on individual identity.
The ADP System Administrator should also be able to audit based on object
identity.
The Criteria specifically adds the following to the list of events that
shall be auditable at the B1 class:
- Any override of human readable output markings (including overwrite
of sensitivity label markings and the turning off of labelling capabilities)
on paged, hard-copy output devices
- Change of designation (single-level to/from multi-level) of any communication
channel or I/O device
- Change of sensitivity level(s) associated with a single-level communication
channel or I/O device
- Change of range designation of any multi-level communication channel
or I/O device
The Criteria specifically adds the following to the list of information
that shall be recorded on the audit trail at the B1 class:
- Security level of the object
The following information should also be recorded on the audit trail at
the B1 class:
- Subject sensitivity level
In addition to previous selection criteria, at the B1 level the Criteria
specifically requires that the ADP System Administrator shall be able to
audit based on individual identity and/or object security level.
The Criteria specifically adds the following to the list of events that
shall be auditable at the B2 class:
- Events that may exercise covert storage channels
- Change of range designation of any single-level or multi-level communication
channel or I/O device
- No new requirements have been added at the B2 class.
In addition to previous selection criteria, at the B2 level the Criteria
specifically requires that "the TCB shall be able to audit the identified
events that may be used in the exploitation of covert storage channels."
The Trusted Computing Base shall audit covert storage channels that exceed
ten bits per second.(1)
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.
The Criteria specifically adds the following to the list of events that
shall be auditable at the B3 class:
- Events that may indicate an imminent violation of the system's security
policy (e.g., exercise covert timing channels)
- No new requirements have been added at the B3 class.
In addition to previous selection criteria, at the B3 level the Criteria
specifically requires that "the TCB shall contain a mechanism that is able
to monitor the occurrence or accumulation of security auditable events that
may indicate an imminent violation of security policy. This mechanism shall
be able to immediately notify the system security administrator when thresholds
are exceeded and, if the occurrence or accumulation of these security-relevant
events continues, the system shall take the least disruptive action to terminate
the event."(1)
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.
- No new requirements have been added at the A1 class.
- No new requirements have been added at the A1 class.
- No new requirements have been added at the A1 class.
The techniques for implementing the audit requirements will vary from system
to system depending upon the characteristics of the software, firmware,
and hardware involved and any optional features that are to be available.
Technologically advanced techniques that are available should be used to
the best advantage in the system design to provide the requisite security
as well as cost-effectiveness and performance.
There is a requirement at classes C2 and above that all security- relevant
events be auditable. However, these events may or may not always be recorded
on the audit trail. Options that may be exercised in selecting which events
should be audited include a pre-selection feature and a post-selection feature.
A system may choose to implement both options, a pre-selection option only,
or a post-selection option only.
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.
For each auditable event the TCB should contain a mechanism to indicate
if the event is to be recorded on the audit trail. The system security administrator
or designee shall be the only person authorized to select the events to
be recorded. Pre-selection may be by user(s) identity, and at the B1 class
and above, pre-selection may also be possible by object security level.
Although the system security administrator shall be authorized to select
which events are to be recorded, the system security administrator should
not be able to exclude himself from being audited.
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.
If the post-selection option to select only specified events from an existing
audit trail is implemented, again, only authorized personnel shall be able
to make this selection. Inclusion of this option requires that the system
should have trusted facilities (as described in section 9.1) to accept query/retrieval
requests, to expand any compressed data, and to output the requested data.
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.
"Since a system that selects all events to be audited may generate a large
amount of data, it may be necessary to encode the data to conserve space
and minimize the processor time required" to record the audit records.(3)
If the audit trail is encoded, a complementary mechanism must be included
to decode the data when required. The decoding of the audit trail may be
done as a preprocess before the audit records are accessed by the database
or as a postprocess after a relevant record has been found. Such decoding
is necessary to present the data in an understandable form both at the administrators
terminal and on batch reports. The cost of compressing the audit trail would
be the time required for the compression and expansion processes. The benefit
of compressing data is the savings in storage and the savings in time to
write the records to the audit trail.
All events included on the audit trail may be written as part of the same
audit trail, but some systems may prefer to have several distinct audit
trails, e.g., one would be for "user" events, one for "operator" events,
and one for "system security administrator" events. This would result in
several smaller trails for subsequent analysis. In some cases, however,
it may be necessary to combine the information from the trails when questionable
events occur in order to obtain a composite of the sequence of events as
they occurred. In cases where there are multiple audit trails, it is preferred
that there be some accurate, or at least synchronized, time stamps across
the multiple logs.
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.
A factor to consider in the selection of the medium to be used for the audit
trail would be the expected usage of the system. The I/O volume for a system
with few users executing few applications would be quite different from
that of a large system with a multitude of users performing a variety of
applications. In any case, however, the system should notify the system
operator or administrator when the audit trail medium is approaching its
storage capacity. Adequate advance notification to the operator is especially
necessary if human intervention is required.
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:
- 1. Notifying the operator that the medium is "full" and action is
necessary. The system should then stop and require rebooting. Although
a valid option, this action creates a severe threat of denial-of-service
attacks.
- 2. Storing the current audit records on a temporary medium with the
intention of later migration to the normal operational medium, thus
allowing auditing to continue. This temporary storage medium should
be afforded the same protection as the regular audit storage medium
in order to prevent any attempts to tamper with it.
- 3. Delaying input of new actions and/or slowing down current operations
to prevent any action that requires use of the audit mechanism.
- 4. Stopping until the administrative personnel make more space available
for writing audit records.
- 5. Stopping auditing entirely as a result of a decision by the system
security administrator.
Any action that is taken in response to storage overflow shall be audited.
There is, however, a case in which the action taken may not be audited that
deserves mention. It is possible to have the system security administrator's
decisions embedded in the system logic. Such pre-programmed choices, embedded
in the system logic, may be triggered automatically and this action may
not be audited.
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.
For the lower Criteria classes (e.g., C2, B1) the audit trail may be the
major tool used in detecting security compromises. Implicit in this is that
the audit resources should provide the maximum protection possible. One
technique that may be employed to protect the audit trail is to record it
on a mechanism designed to be a write-only device. Other choices would be
to set the designated device to write-once mode by disabling the read mechanism.
This method could prevent an attacker from erasing or modifying the data
already written on the audit trail because the attacker will not be able
to go back and read or find the data that he or she wishes to modify.
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.
If the facilities are available, another method of protecting the audit
trail would be to forward it to a dedicated processor. The audit trail should
then be more readily available for analysis by the system security administrator.
Depending upon the amount of activity on a system and the audit selection
process used, the audit trail size may vary. It is a safe assumption though,
that the audit trail would grow to sizes that would necessitate some form
of audit data reduction. The data reduction tool would most likely be a
batch program that would interface to the system security administrator.
This batch run could be a combination of database query language and a report
generator with the input being a standardized audit file.
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.
In standard data processing, audit information is recorded as it occurs.
Although most information is not required to be immediately available for
real-time analysis, the system security administrator should have the capability
to retreive audit information within minutes of its recording. The delay
between recording audit information and making it available for analysis
should be minimal, in the range of several minutes.
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 exact period of time required for retaining the audit trail is site
dependent and should be documented in the site's operating procedures manual.
When trying to arrive at the optimum time for audit trail retention, any
time restrictions on the storage medium should be considered. The storage
medium used must be able to reliably retain the audit data for the amount
of time required by the site.
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.
The audit resources, along with all other resources protected by the TCB,
have increasing assurance requirements at each higher Criteria class. For
the lower classes, an audit trail would be a major factor in detecting penetration
attempts. Unfortunately, at these lower classes, the audit resources are
more susceptible to penetration and corruption. "The TCB must provide some
assurance that the data will still be there when the administrator tries
to use it."(3) The testing requirement recognizes the vulnerability of the
audit trail, and starting with the C2 class, shall include a search for
obvious flaws that would corrupt or destroy the audit trail. If the audit
trail is corrupted or destroyed, the existence of such flaws indicates that
the system can be penetrated. Testing should also be performed to uncover
any ways of circumventing the audit mechanisms. The "flaws found in testing
may be neutralized in any of a number of ways. One way available to the
system designer is to audit all uses of the mechanism in which the flaw
is found and to log such events."(3) An attempt should be made to remove
the flaw.
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.
Starting at the C2 class, documentation concerning the audit requirements
shall be contained in the Trusted Facility Manual. The Trusted Facility
Manual shall explain the procedures to record, examine, and maintain audit
files. It shall detail the audit record structure for each type of audit
event, and should include what each field is and what the size of the field
is.
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.
There are certain risks contained in the audit process that exist simply
because there is no way to prevent these events from ever occurring. Because
there are certain unpredictable factors involved in auditing, i.e., man,
nature, etc., the audit mechanism may never be one hundred per cent reliable.
Preventive measures may be taken to minimize the likelihood of any of these
factors adversely affecting the security provided by the audit mechanism,
but no audit mechanism will ever be risk free.
Even with auditing mechanisms in place to detect and deter security violations,
the threat of the perpetrator actually being the system security administrator
or someone involved with the system security design will always be present.
It is quite possible that the system security administrator of a secure
system could stop the auditing of activities while entering the system and
corrupting files for personal benefit. These authorized personnel, who may
also have access to identification and authentication information, could
also choose to enter the system disguised as another user in order to commit
crimes under a false identity.
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.
Although the audit software and hardware are reliable security mechanisms,
they are not infallible. They, like the rest of the system, are dependent
upon constant supplies of power and are readily subject to interruption
due to mechanical or power failures. Their failure can cause the loss or
destruction of valuable audit data. The system security administrator should
be aware of this risk and should establish some procedure that would ensure
that the audit trail is preserved somewhere. The system security administrator
should duplicate the audit trail on a removable medium at certain points
in time to minimize the data loss in the event of a system failure. The
Trusted Facility Manual should include what the possibilities and nature
of loss exposure are, and how the data may be recovered in the event that
a catastrophe does occur.
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.
Administrator - Any one of a group of personnel assigned to supervise all
or a portion of an ADP 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.
|
