Internet DRAFT - draft-elliott-ldapext-spdna-recrecs
draft-elliott-ldapext-spdna-recrecs
LDAPEXT D. Elliott
Internet Draft Aventail Corp
Document: <draft-elliott-ldapext-spdna-recrecs-00.txt> N. Greene
Category: Informational Nortel Networks
S. Miklos
Dept of Defense
November 2000
Recommendations for Recording Directory Access Data
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Service Provider Directory-enabled Network Applications WG in
the Directory Interoperability Forum of the Open Group (see
http://www.sp-dna.org) is looking at the use of LDAP-accessible
directories for Service Provider applications. In the course of this
work, we have found a few areas where existing LDAP standards do not
meet all the needs for a directory. This document addresses one such
area - logging and auditing.
SP-DNA directory systems are required to record and log all access
to directory data. This is necessary for three main reasons: to
check that access control on the directory is functioning properly,
to detect and respond to access control policy violation, and to
facilitate recovery and repair of directory data in the event of
data loss.
Our applications are not unique in these areas: we feel that many
other directory applications will run into the same issues. For
example, any mission-critical application that uses a directory will
probably have similar needs for logging and audit. This document
lists some of the requirements we would like to see addressed to
make LDAP better suited to our applications, and to many others with
similar characteristics.
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
Table of Contents
1. Introduction
2. Conventions used in this document
3. Why record directory access events?
3.1 Checking access control
3.2 Detection and response to potential policy violation
3.3 Directory recovery/repair
4. Requirements
4.1 Access to recorded data
4.2 LDAP trackingId
4.3 Configuration of the recording function
4.3.1 General
4.3.2 Kinds of events to record
4.4 What to record
4.5 Storage of recorded information
4.5.1 Local storage
4.5.2 Central storage
4.5.3 Audit data in transit
4.6 Review of recorded info: reports, alarms, automated responses
5. Security considerations
6. References
7. Acknowledgements
8. Authors' Addresses
1. Introduction
The Service Provider Directory-enabled Network Applications WG in
the Directory Interoperability Forum of the Open Group (see
http://www.sp-dna.org) is looking at the use of LDAP-accessible
directories for Service Provider applications. In the course of this
work, we have found a few areas where existing LDAP standards do not
meet all the needs for a directory. This document addresses one such
area - logging and auditing.
Our SP-DNA applications are not unique in these areas: we feel that
many other directory applications will run into the same issues. For
example, any mission-critical application that uses a directory will
probably have similar needs for logging and audit. This document
lists some of the requirements we would like to see addressed to
make LDAP better suited to our applications, and to many others with
similar characteristics.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
Some terminology used in examples (e.g., user, subscriber) is
specific to SP-DNA. These terms are defined in [3]. Other documents
referenced in general are noted in [4], [5], and [6].
3. Why record directory access events?
3.1 Checking access control
The first goal, and most common use of logged directory access
information, is to document the proper functioning of access
controls. Note that this type of reporting only provides a record of
the proper functioning of controls/access decisions. It does not
document access that successfully circumvents controls.
3.2 Detection and response to potential policy violation
Another goal of logged directory access information is to detect
policy violation by analyzing activities related to the directory,
identifying attack profiles, and responding to access policy
violations
3.3 Directory recovery/repair
A third goal of logged directory access information is to record
information that will facilitate the recovery and repair of data.
4. Requirements
4.1 Access to recorded data
The level of security provided for recorded directory access
information must be the same as that provided for the directory data
being recorded.
For example, in an SP-DNA environment, only certain administrative
roles have control of and access to recorded data. Having a set of
standard administrative roles allows applications using the
directory to use roles other than "directory root" for
administration, which increases overall security.
a) It must be possible to assign one designated Administrator (e.g.,
in SP-DNA, the "Directory Administrator"), to have the ability to
configure and control the recording of security-related events to a
log, be able to access the recorded data, and take action based upon
it.
b) It must be possible to assign one Administrator (e.g., in SP-DNA,
the "Service Provider Administrator") to be able to view, but not
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
change, recorded directory access data, and take action based upon
it.
c) It should be possible to allow selective viewing of the data. For
example, one kind of administrator may only be allowed to view data
pertaining to its own users, and not data pertaining to any other
users or subscribers in the directory (e.g., in SP-DNA, the
"Subscriber Administrator"). This would require that the audit logs
be filtered so that only data the administrator is allowed to see
can be viewed.
d) It must not be possible for any user, other than the designated
administrator, to view recorded directory access data or configure
the recorded directory access function.
e) It must not be possible for anyone, including all Administrator
roles, to modify the recorded directory data without detection.
4.2 LDAP trackingId
A long term requirement is to include a trackingId on LDAP commands
to help in following recorded directory access threads across
distributed systems. For example, it may be necessary to synchronize
the logs from the application server, web server and directory
server that were involved in processing one particular LDAP user
request.
4.3 Configuration of recording function
4.3.1 General
a) The system must allow a designated Administrator to configure
which events generate log records (e.g. add/remove/modify), and the
level of detail for each record.
b) Any changes to the configuration of directory logging must
themselves be auditable events.
c) The designated Administrator must be able to enable/disable the
directory logging function
d) The act of enabling/disabling directory logging function must
itself be an auditable event that cannot be disabled.
e) It must be possible to configure how data logs are handled, and
to configure log file location on local and remote host(s).
f) The system must allow the configuration of data log archiving: by
period (hours/days/weeks), by date/time, and/or by maximum size.
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
g) It should be possible to define the total number/size of log
files to be maintained, and what to do in the event these parameters
are reached.
h) It should be possible to perform manual log file rotation.
4.3.2 Kinds of events to record
Some of these events would occur outside the directory. If this is
the case, a logging function would still need a way to record them,
but it cannot be specified as part of the directory system (and thus
how those particular events are recorded is outside the scope of
LDAPext).
These events all occur in relation to the directory, and thus are
within the scope of the LDAPext WG work:
- Startup and shutdown of the recording function;
- Both successful and unsuccessful privileged user logins;
- Audit log failure due to storage exhaustion or network failure;
- Directory service shutdowns and restarts;
- All unsuccessful attempts to access resources;
- Changes to security function that affects what is being recorded;
- Changes to security mechanisms;
- All requests to perform an operation on an object covered by the
Security Policy;
- Access to specified user and operational objects/attributes (e.g.
read, add, delete, modify and related operations)
- It must be possible to configure events to be recorded from the
perspective of both subject and object/attribute;
- All auditable events for a specified data recording level
(minimum, basic, detailed....);
- Both successful and unsuccessful authentication requests;
- Modifications to the group of users that are part of a role;
- All potential policy violations identified by analysis tools (e.g.
detected replay attacks, denial of service attacks, etc.);
- All actions taken by automated response tools.
The following events need to be recorded, but since the recorded
data will not likely be stored as part of the directory, how they
are triggered is outside the scope of and LDAPext WG work:
- Both successful and unsuccessful reading of information from the
audit records;
- Administrative commands, including log control commands (e.g.,
setting disk threshold, manual log file rotation, etc.);
- Changes to the system time.
During normal directory operation the following events should always
be logged:
- Both successful and unsuccessful privileged user logins;
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
- Audit log failure due to storage exhaustion or network failure
- Directory service shutdowns and restarts;
- Administrative commands, including log control commands (e.g.,
setting disk threshold, manual log file rotation, etc.);
- All unsuccessful attempts to access resources.
If the SP-DNA Directory Administrator does disable logging of any of
the above events, that event itself must be logged.
4.4 What to record
Each audit record saved must contain:
a) event date and time - the event record time stamp should be
consistent and reliable (i.e. use NTP) for all event records within
the management domain and across all audit logs (this is
particularly applicable if/when multiple audit logs are used to
differentiate between management and user operations);
b) event type and specific information relevant to this particular
event type;
c)user identity association _ each auditable event must be
associated with the user or application entity that initiated the
event, including the authentication mechanism used;
d) outcome (success/failure), and if failure, the cause and severity
of the failure;
e) Audit record sequence number - must allow at least 64K different
sequence numbers to avoid frequent roll-over (useful in case date
and time are unavailable or unreliable) (Note: this is different
from a trackingId);
f) source and destination addresses;
g) names of resource(s) accessed.
4.5 Storage of recorded information
As stated in an earlier section, the level of security provided for
data collected through directory recording must be the same as that
provided for the actual directory data being recorded.
The following sections state the storage requirements for the log
data, whether it is stored locally, or stored on a central log
server, and requirements for the transfer of this data.
4.5.1 Local storage
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
If a node stores directory data log information locally (i.e. on the
same machine as the directory is stored), then these are the
requirements:
a) Availability of log files: In order to ensure availability of the
log information in the event of failure of the directory or data
store, recorded data should reside outside of the directory service.
b) Integrity: The logs must be protected against unauthorized
deletion and/or modification.
c) Integrity: The system should be able to detect modified or
corrupted data. For example, a simple hash may provide assurance
that the files have not been corrupted accidentally, a signed hash
may provide assurance that the files have not been intentionally
modified (there are obvious issues with processing overhead).
d) Confidentiality: Only authorized persons must have access to the
log data.
e) The system should provide a threshold parameter controlling the
issuance of warning alarms for impending log storage exhaustion.
f) The system should provide a configurable action parameter in the
event of impending log storage exhaustion (i.e. halt or wraparound).
g) Logs must be maintained upon storage exhaustion or when archiving
does not work.
h) The system should avoid repeating the same message many times
(e.g., "previous message repeated 257 times").
4.5.2 Central storage
While a central log server would be outside the scope of a directory
system, requirements for this server to store directory access log
information are stated here for completeness.
a) The log server must store log files in non-volatile storage
b) It must store date and time of any failure of the logging
function in non-volatile storage.
c) It should be possible to configure the log collection system to
prepend log file header information when it creates a new file.
d) Integrity: The logs must be protected against unauthorized
deletion and/or modification.
4.5.3 Audit data in transit
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
a) The directory system must record occurrence of any failure of the
logging function and resume logging when the cause of failure is
corrected.
b) The directory system should send log file header information
after system restart or when a connection is opened to the log
collection system (if the system is not co-located with the
directory system).
c) Availability: the directory system should use a reliable
transport protocol (e.g. TCP).
d) Integrity: the directory system should be able to detect any
modification or corruption of log file data.
e) Non-repudiation: Upon connection set-up with a log collection
system, the directory system should be able to verify the sender of
the log file data.
f) Confidentiality: the data must be kept confidential. For example,
the data must be encrypted when in transit across an environment
that is not physically secure.
4.6 Review of recorded info: reports, alarms, automated responses
This section contains recommendations for methods of reviewing and
using logged information.
a) The Directory audit function should present the audit records in
a manner suitable for the administrator to interpret the
information. To this end, post-processing tools should be provided
to facilitate the review of log file data and generation of audit
reports.
b) The system should provide automated means to analyze system
activity in order to identify real/potential security violations,
and to define alarms and automated responses based on the detection
of real/potential security policy violations. This could involve
virus detection, intrusion detection, examining various aspects of
the material being transmitted for unauthorized content, analyzing
characteristics of user profiles, analyzing audit records, and
alerting operational personnel when misuse is detected or suspected.
Threat actions could include actions or events that would deny
services to authorized users, loss of secure state, and protocol
failures.
The following are examples of tools that can be used to analyze
event data through the use of rules and known attack profiles,
subsequently generating alarms and/or automated responses:
Potential violation analysis
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
The audit log function should support threshold detection based on
defined rule sets. These rule sets would be composed of identified
accumulations/combinations of events known to indicate potential
violations (e.g., repeated failed actions, requests for privileged
information, multiple access requests used to aggregate data,
attempted access of system files, unauthenticated responses known to
indicate a potential security violation).
Profile-based detection
The audit log function may support the maintenance of historical
usage profiles for a given user/group, and be able to determine
variance from this profile in real-time or post-collection. If
monitoring profile variance in real-time, it should be possible to
identify imminent security policy violation(s) and provide an
automated response (e.g. disabling a user account).
Simple and complex heuristics
The audit log function may support the storage of system activity
signatures, and be able to compare these signatures to current
system activity. Signatures may encompass both single and multi-
step system activities, and be initiated by one or more
authenticated entities. Known activity signatures may be identified
in real-time or post-collection, and be used to initiate an
automated response.
5. Security Considerations
This document provides requirements for tracking access to a
directory system. Having a directory access recording function for
directory systems that satisfies these requirements will increase
the level of security of these systems in a measurable way, and
provide information to assist in the recovery of corrupted or lost
data.
6. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3 "SP-DNA Terminology", Directory Interoperability Forum (DIF)
Service Provider Directory-enabled Network Applications (SP-DNA)
WG, May 2000, <ftp://standards.nortelnetworks.com/dif-sp-
dna/docs/latest/SP-DNATerminologyv3.doc>
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
4 CCITT Recommendation X.740, "Systems Management: Security Audit
Trail Function", 1992-3.
5 Common Criteria Implementation Board, "Common Criteria for
Information Technology Security Evaluations v2.1", CCIMB-99-031,
August 1999 - September 2000.
6 Gallagher, Patrick R., Jr., "A Guide to Understanding Audit in
Trusted Systems", National Computer Security Center, NCSC-TG-001,
1987.
7. Acknowledgments
The requirements in this document were discussed within the SP-DNA
WG. In particular, the authors would like to thank Rick Huber and
Mark Wahl for their input.
8. Author's Addresses
Dave Elliott
Aventail Corp
808 Howell St.
Seattle, Washington 98101
(206)215-0062
Email: <delliott@aventail.com>
Nancy Greene
Nortel Networks
Ottawa, Canada
Email: <ngreene@nortelnetworks.com>
Sue (Sandi) A. Miklos
Department of Defense, V51
9800 Savage Rd.
Fort Meade, MD 270550-6730, USA
Email: samiklo@missi.ncsc.mil
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
<draft-spdna-ldapext-recrecs-00.txt> Nov 2000
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
