LDAPEXT D. Elliott Internet Draft Aventail Corp Document: 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. 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]. 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 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. 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; 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 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 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 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, 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: Nancy Greene Nortel Networks Ottawa, Canada Email: 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 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.