Network Working Group C. J. Calabrese Internet-Draft The SANS Institute Expires: July 2, 2001 M. Apad Association of Hungarian Linux Users January 2001 Requirements for a Network Event Logging Protocol draft-calabrese-requir-logprot-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on July 2, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document presents requirements for sending system event/audit logs over the Internet. In developing these requirements, it considers the needs for log management, security, high-performance, and compatibility with existing practice. Calabrese & Apad Expires July 2, 2001 [Page 1] Internet-Draft Event Logging Requirements January 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Log Reporting Considerations . . . . . . . . . . . . . . . 4 2.1 Introduction and Rationale . . . . . . . . . . . . . . . . 4 2.2 Identification of Event Threads . . . . . . . . . . . . . 4 2.3 Event Correlation . . . . . . . . . . . . . . . . . . . . 4 2.4 Event Filters . . . . . . . . . . . . . . . . . . . . . . 5 2.4.1 Introduction and Rationale . . . . . . . . . . . . . . . . 5 2.4.2 Filtering By Source . . . . . . . . . . . . . . . . . . . 5 2.4.3 Filtering By Priority . . . . . . . . . . . . . . . . . . 5 2.4.4 Filtering By Facility . . . . . . . . . . . . . . . . . . 5 2.4.5 Filtering By Other Attributes . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . 6 3.1 Introduction and Rationale . . . . . . . . . . . . . . . . 6 3.2 Common Criteria . . . . . . . . . . . . . . . . . . . . . 6 3.3 Implications . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Policies . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2 Access Control Labels . . . . . . . . . . . . . . . . . . 8 3.3.3 Identification/Authentication . . . . . . . . . . . . . . 9 3.3.4 Selective Storage and Protection of Audit Records . . . . 9 3.3.5 Assurance . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.5.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 3.3.5.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.5.3 Availability . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.6 Trusted Mechanisms . . . . . . . . . . . . . . . . . . . . 11 3.4 Protocol Level for Cryptographic Functions . . . . . . . . 11 4. Resource Utilization Considerations . . . . . . . . . . . 13 5. Existing Practice . . . . . . . . . . . . . . . . . . . . 14 5.1 Existing Syslog . . . . . . . . . . . . . . . . . . . . . 14 5.2 Schneier and Kelsey . . . . . . . . . . . . . . . . . . . 14 5.3 Nsyslogd . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4 Secure Syslog . . . . . . . . . . . . . . . . . . . . . . 15 5.5 ULM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6 syslog-ng . . . . . . . . . . . . . . . . . . . . . . . . 15 5.7 SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . 21 Calabrese & Apad Expires July 2, 2001 [Page 2] Internet-Draft Event Logging Requirements January 2001 1. Introduction Computer systems and other network devices often need to "log" or record information about important events. In many systems, these event logs are recorded locally, in persistent storage within the system where the event occurs. These messages may also be transmitted to a remote system where persistent storage takes place. Reasons for such remote transmission include event logging on systems with no local persistent storage and centralization of log record management. This memo concerns itself with the requirements for transmitting log messages over an Internet Protocol network, including requirements for log management, event correlation, security, performance, and compatibility with existing practice. It was originally conceived to guide the workings of the IETF's Security Issues in Network Event Logging Working Group, which is dealing with security issues in the Syslog[2] system. However, the principles apply equally well to other event logging systems. 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[1]. Calabrese & Apad Expires July 2, 2001 [Page 3] Internet-Draft Event Logging Requirements January 2001 2. Log Reporting Considerations 2.1 Introduction and Rationale The ultimate reason for transmitting log messages over the network is so these messages can be examined later to detect and analyze "interesting" events (security incidents, peak server usage, etc.). Although the transmission of the messages itself is not directly related to this examination, the systems related to transmission should aid the process of examination to the largest extent practical. 2.2 Identification of Event Threads Since logging system tend to generate and transmit discrete event messages, one of the most important reporting requirements for a logging system is to be able to figure out how event messages fit together to form a thread of messages about the same incident. Messages in a thread are typically identified by the originating machine, the program or sub-system on the originating machine, and the instance of that program or sub-system. Additionally, some kind of sequence information must be present to determine the order of event messages in the thread. In most cases, the originating machine can be determined by the source IP address of log messages and the sequence determined by the order of arriving packets (UDP) or relative ordering in the transmission stream (TCP). However, the IP address can be forged and is therefore unreliable. Similarly, an attacker could reorder packets in a UDP stream. Furthermore, there is no easy method of determining the program/sub-system and its instance on the originating machine without including such identifying information directly in the message. Therefore, it seems plain that the logging messages must directly contain all these pieces of information in order to facilitate the identification of event threads. This issue is also discussed in the Security section (Section 3.3.3). 2.3 Event Correlation In addition to identifying event messages within the same incident thread from the same source, it is also desirable to correlate messages regarding the same incident from multiple sources. This implies a standard mechanism for identifying incidents based on various criteria such as the time the event occurred, IP addresses of network entities involved, etc. Calabrese & Apad Expires July 2, 2001 [Page 4] Internet-Draft Event Logging Requirements January 2001 2.4 Event Filters 2.4.1 Introduction and Rationale Selecting which events to transmit reduces network load. Selecting which events to accept when transmitted reduces the amount of data that must be processed by higher-level software and which must be persistently stored. The log transmission protocols can help these efforts by making it easy to select events for filtering. 2.4.2 Filtering By Source The most obvious attribute to filter data by in an Internet Protocol network is the source IP address of the data. 2.4.3 Filtering By Priority Another obvious filter would be by message priority so that high priority messages can be posted as alarms, very low priority messages ignored, etc. 2.4.4 Filtering By Facility Not all high priority messages should necessarily be handled the same way. Aside from message priority, the primary method of filtering in the traditional Syslog[2] system is by something called the message Facility (LOG_AUTH, LOG_DAEMON, LOG_MAIL, etc.) 2.4.5 Filtering By Other Attributes Source address, priority and facility are by no means the only pieces of information log messages will need to be filtered by. Indeed, just about any attribute of a log message is fair game, and the potential attributes too many to enumerate here. Some have argued that log messages should be structured to make such filtering easier (and some structure is already needed for thread identification, event correlation, and other reasons). Others have argued that rigid structures are not needed if filters are based on regular expressions.[3] Calabrese & Apad Expires July 2, 2001 [Page 5] Internet-Draft Event Logging Requirements January 2001 3. Security Considerations 3.1 Introduction and Rationale According to the U.S. Department of Defense Trusted Computer System Evaluation Criteria (TCSEC)[4], the fundamental requirements for computer security are: 1. An explicit and well-defined security policy enforced by the system. 2. Access control labels associated with objects. 3. Identification of individual subjects. 4. Selective storage and protection of audit records so that actions affecting security can be traced to the responsible party. 5. Assurance that the computer system enforces security requirements. 6. Trusted mechanisms that enforce these basic requirements that are continuously protected against tampering and/or unauthorized changes. In the case of system event logs, the logs themselves may contain the aforementioned audit records. 3.2 Common Criteria To put it another way, a logging system should meet the following requirements from the Common Criteria for Information Technology Security Evaluation[5]: o FAU (Security audit) * FAU_ARP (automatic response) * FAU_GEN (generation) * FAU_SAA (analysis) * FAU_SAR (review) * FAU_SEL (selection) * FAU_STG (storage) Calabrese & Apad Expires July 2, 2001 [Page 6] Internet-Draft Event Logging Requirements January 2001 o FCS (Cryptographic support) * FCS_COP (operation) o FDP (User data protection) * FDP_ACC (Access control policy) * FDP_ACF (Access control functions) * FDP_DAU (Data authentication) * FDP_ETC (Export to outside TSF control) * FDP_IFC (Information flow control policy) * FDP_IFF (Information flow control functions) * FDP_ITC (Import from outside TSF control) * FDP_ITT (Internal TOE transfer) * FDP_RIP (Residual information protection) * FDP_ROL (Rollback) * FDP_SDI (Stored data integrity) * FDP_UCT (Inter-TSF user data confidentiality transfer protection) * FDP_UIT (Inter-TSF user data integrity transfer protection) o FPT (Protection of the TSF) * FPT_FLS (Fail secure) * FPT_ITA (Availability of exported TSF data) * FPT_ITC (Confidentiality of exported TSF data) * FPT_ITT (Internal TOE transfer) * FPT_RCV (Trusted recovery) * FPT_RPL (Replay detection) * FPT_SSP (State synchrony protocol) Calabrese & Apad Expires July 2, 2001 [Page 7] Internet-Draft Event Logging Requirements January 2001 * FPT_STM (Time stamps) * FPT_TDC (Inter-TSF data consistency) o FRU (Resource utilization) * FRU_FLT (Fault tolerance) * FRU_PRS (Priority of service) * FRU_RSA (Resource allocation) 3.3 Implications 3.3.1 Policies The questions of what policies are appropriate for system logging and how to enforce them are beyond the scope of this memo. However, any protocol for transmitting log messages must take into account the fact that different systems may have different security policies. Therefore, such protocols should not require adherence to any particular policy. 3.3.2 Access Control Labels Access control labels fall into two categories. Integrity labels (think file permissions) and Sensitivity labels (secret, top-secret, etc.). Logging system implementations would use these labels to determine restrictions on access to the data. However, the details of such implementations are beyond the scope of this memo. In the case of system log messages, Integrity labels could be mapped into the Facility tags present in the existing Syslog[2] system. For such a mapping to be useful, however, there should be be a larger and more orthogonal set of Facility tags than the small set in traditional Syslog. The system should also support the ability to specify multiple Facility tags for a particular message. As for Sensitivity labels, if we recognize that logs operating at lower priority also tend to be much more verbose, then we can allow an inverse relationship between Sensitivity labels and log priorities as used in the existing Syslog system (LOG_DEBUG, LOG_INFO, LOG_NOTICE, LOG_WARNING, etc.)[2]. In other words, higher-priority messages may be more widely viewed and less widely created. Conversely, lower-priority messages may be less widely viewed but more widely created. Of course, this is a big assumption. It also implies that message priority must be present in all messages. Calabrese & Apad Expires July 2, 2001 [Page 8] Internet-Draft Event Logging Requirements January 2001 Also note that a strictly TCSEC[4] or U.S. National Security Agency Labeled Security Protection Profile (LSPP)[6] environment would require the protocol and the components operating on it to either act as a multilevel channel or use distinct single-level channels for each set of Sensitivity labels. A true multilevel channel would require much closer mapping to the native Sensitivity labels than the simple mapping described above. Furthermore, the any non-labeled to labeled transitions must be done in a single-level channel only. 3.3.3 Identification/Authentication Ideally, we want to be able to show by strong identification mechanisms (i.e., digital signatures) that a certain log message was generated by a certain program running with certain privileges/user-id on a certain machine at a certain time. This not only allows the exact/authentic subject originating the message to be identified, but also allows non-repudiation of the messages, and easy correlation of events between machines for purposes such as intrusion detection and forensics. The most direct way of implementing such identification is to issue a digital signature key to each program, user, and machine and to require all messages to be thusly signed by the appropriate program/user/machine keys. However, this runs into two major problems. The first is one of key management (i.e., there are too many keys to manage) and the second one of performance (i.e., not all log messages require such identification capabilities and not all machines have the horsepower to supply them). However, if the logging mechanism on the originating machine is part of the system's trusted computing base (TCB), then it is sufficient for TCB to sign the identity of the log messages on the originating program's behalf when directed to do so. Note that it is not necessary for each message to be digitally signed in its entirity. A common practice is to negotiate and sign a session key and then use that key to encrypt a message digest or message authentication code (MAC) of the individual messages[7]. 3.3.4 Selective Storage and Protection of Audit Records The policy side of what audit records need to be stored and how much protection they need is beyond the scope of this memo. On the technology side, we can observe that the general issue of requirements for protecting the audit records of a logging system necessarily refers back to the very same security requirements for a logging system itself (i.e., the logging requirements for a logging system are still logging requirements). Since such security requirements for logging systems are the main topic of this memo, the meta logging issue is already addressed elsewhere in the memo Calabrese & Apad Expires July 2, 2001 [Page 9] Internet-Draft Event Logging Requirements January 2001 and will not be addressed further here. 3.3.5 Assurance Issues such as protocol and implementation evaluation against security policies and requirements are beyond the scope of this memo. However, we can address this issue at a requirements level by observing that all security policies center around confidentially, integrity, and availability. 3.3.5.1 Confidentiality It is generally acknowledged that the only practical way to achieve confidentiality of messages traveling over an open network is through the use of cryptography. 3.3.5.2 Integrity Integrity of log messages boils down to identification of the sender, immutability of messages without detection, and assurance that logs have reached their destination. Identification and immutability can be addressed through digital signatures as discussed in the Identification/Authentication sub-section (Section 3.3.3) above. Therefore this section will deal directly only with assurance of delivery. Essentially this boils down to the requirement that the originator of a log message have the capability to detect that a particular message has or has not reached its destination. This does not necessarily imply that only one copy of the message may reach its destination or that the sender must block waiting for delivery notification, which leaves some room to balance this requirement against issues such as performance[8]. On the other hand, the TCSEC[4], LSPP[6], and the U.S. National Security Agency Controlled Access Protection Profile (CAPP)[9] require security sensitive applications to shut down if they can't log security-related events, so the capability to block waiting for delivery notification must be present in such environments. 3.3.5.3 Availability The following seem reasonable requirements for high-availability: 1. Logging mechanisms should be able to transmit their log messages to multiple destinations, increasing the probability that at least one will be available. 2. Logging protocols should make it easy to filter unwanted Calabrese & Apad Expires July 2, 2001 [Page 10] Internet-Draft Event Logging Requirements January 2001 messages received, reducing the possibility of a denial of service attack on the recipient through the generation of bogus messages. 3. Logging protocols should not require log senders to wait synchronously for positive acknowledgement of messages sent before sending any additional messages, making denial of service attacks on log senders more difficult through the generation of excessive traffic on a particular network link. Note that not requiring applications to wait for positive acknowledgement is not the same thing as precluding them from waiting[8]. Also note that the TCSEC[4], the LSPP[6], and the CAPP[9] require security sensitive applications to shut down if they can't log security-related events, so the capability to block waiting for delivery notification must be present in such environments. 4. Logging protocols should provide the capability to retransmit unacknowledged messages, also making denial of service attacks on log senders more difficult through the generation of excessive traffic on a particular network link. Note that this facility may be provided by lower level protocols such as by the data integrity features of TCP[7]. This implies degraded capabilities when running over other lower level protocols, which may be a reasonable trade-off in many circumstances. High availability protocol and implementation issues such as high-availability clustering, resistance to buffer overrun attacks, etc. are beyond the scope of this memo. 3.3.6 Trusted Mechanisms This area is beyond the scope of this memo. 3.4 Protocol Level for Cryptographic Functions One open issue from the above discussion is whether cryptographic functions for identification signatures and confidentiality should be performed at the network transport layer or at higher-level application-specific protocols. Performing these functions at the network transport layer allows the use of standard transport layer security mechanisms (TLS, IPsec), making implementation easier and possibly leading to higher performance due to hardware assist for standard mechanisms, smaller memory footprint on devices already supporting such mechanisms, etc. It also allows filtering of garbage messages at a lower level, making denial of service attacks more difficult. On the other hand, having identification signatures operate at the Calabrese & Apad Expires July 2, 2001 [Page 11] Internet-Draft Event Logging Requirements January 2001 network transport level means rejecting all unsigned or improperly signed messages since signing information will be lost to the higher protocol layers. Since not all devices generating log messages will have sufficient computing abilities to sign all messages and not all messages will contain information requiring signature, can be problematic. Furthermore, signing and encrypting individual messages facilitates being able to show the confidentiality and integrity of messages without needing to show full chain-of-custody or prove that all links in the chain were appropriately trusted. Therefore, network logging systems should allow cryptographic identification functions to be performed both at the network transport layer and also at higher layers. Cryptographic confidentiality functions, on the other hand, are likely to be more appropriate at the network transport level. Calabrese & Apad Expires July 2, 2001 [Page 12] Internet-Draft Event Logging Requirements January 2001 4. Resource Utilization Considerations From a logging protocol standpoint, the following resources may be considered: 1. CPU/memory utilization on the sending system to marshal internal log messages into the on-the-wire protocol, including any encryption, signing, and/or compression. 2. On-the-wire bandwidth utilization, including amenability of the protocol to be compressed by hardware compressors. 3. CPU/memory utilization on the receiving system decompress, filter, verify the integrity of, and/or store incoming messages. Most of these considerations argue for a simple text based protocol that is easy to marshal and compress where application-level compression, encryption, and signatures are a configurable option. However, the need to filter messages argues for a more structured protocol to make filtering easier. Furthermore, there may be interactions between the encryption mechanism and the ability to compress the message stream. Calabrese & Apad Expires July 2, 2001 [Page 13] Internet-Draft Event Logging Requirements January 2001 5. Existing Practice 5.1 Existing Syslog The Syslog system is probably the most widely deployed mechanism for storing, filtering, and transferring log message over the network. It is ubiquitous in *nix environments, being bundled with all *nix flavors. It is also heavily used by routers, switches, and other "network applicances" where its ability to transmit logs over the network, its simplicity, and the availability of free implementations make it a natural choice. It has even crept into usage in the Microsoft Windows world, where the native logging system does not work well in large networked environments nor can it interoperate with the logging mechanisms of other operating systems. Unfortunately, Syslog also has some very serious and widely recognized weaknesses.[10] 1. Message authenticity is based on easy-to-spoof IP addresses. 2. There is no mechanism to assure message confidentiality or integrity. 3. The protocol does not guarantee delivery of messages, or ordered delivery of messages. 4. The relatively unstructure nature of Syslog messages makes them difficult to filter and/or analyze. Several systems have been devised to improve upon Syslog, and the rest of this section will address these. 5.2 Schneier and Kelsey Bruce Schneier and John Kelsey of Counterpane Internet Security presented a paper at the the Seventh USENIX Security Symposium on cryptographic mechanisms for preserving message integrity and confidentiality when storing log messages on an untrusted system[11]. They also presented a follow-up paper on accessing those logs over a network at the Second International Workshop on the Recent Advances in Intrusion Detection (RAID '99)[12]. To the best of my knowledge, no practical implementations of this system has been built. 5.3 Nsyslogd Nsyslogd is a drop-in Syslog replacement developed by Darren Reed of The Australian National University that sports improved filtering Calabrese & Apad Expires July 2, 2001 [Page 14] Internet-Draft Event Logging Requirements January 2001 based on regular expressions, guaranteed message delivery and ordering through the uses of TCP as a transport mechanism, and on-the-wire privacy through SSL/TLS.[13] 5.4 Secure Syslog Secure Syslog is another drop-in Syslog replacement, this one developed by Core-SDI. It offers message integrity and confidentiality guarantees through the use of Core-SDI's PEO-1 cryptographic protocol.[14] 5.5 ULM ULM is a toolset developed by Herve Schauer Consultants to query Syslog based logs that are stored in a structured format. The original version of this tool used a format described in a now-expired Internet Draft by Abela and Debeaupuis[15]. A newer version uses an XML schema developed by author C. Calabrese and based on the original ULM format.[16] 5.6 syslog-ng Syslog-ng is another drop-in Syslog replacement, this one developed by Balazs Scheidler of BaliBit Computing. Like Nsyslogd, it offers improved filtering and guaranteed message delivery and ordering. Unlike Nsyslogd, it does not offer SSL/TLS support, but it does support message integrity through the use of digital signatures.[17] 5.7 SNMPv3 While not designed purely for logging applications, SNMPv3[21] does provide most of the mechanisms required for secure logging through its User-based Security Model[22] and View-based Access Control Model[23]: o Data encryption to support confidentiality. o Cryptographically based identification of principles (i.e., signing keys). o Cryptographically assured data integrity (i.e., signed message authentication codes). o Ability to detect lost and replayed messages. Looking back at the fundamental requirements for computer security defined in the TCSEC[4], SNMPv3 is still missing the ability to specify access control labels labels associated with each message. Calabrese & Apad Expires July 2, 2001 [Page 15] Internet-Draft Event Logging Requirements January 2001 6. Conclusions Although several systems have been developed to improve upon the ubiquitous Syslog system, none adequately addresses all the requirements identified here. It is hoped that this exercise of identifying these requirements will provide the designers of these and other logging systems with the input they need to address all these issues. In particular, this document and the process behind its development are playing an important role in the development of system logging protocols being carried out by the IETF Security Issues in Network Event Logging Working Group. This process has identified the following as areas that need to be addressed: o Log message format structures to support Identification of Event Threads, Event Correlation, and Event Filters. o Security mechanisms to support log message Access Control Labels, Message Identification, Selective Storage, Message Confidentiality, Message Integrity, and System Availability. So far, the process has generated Internet-Drafts on o How the current Syslog protocol operates [10]. o Reliable delivery of Syslog data between machines.[18] o Confidentiality and integrity of Syslog messages at the Network level.[19] o Confidentiality and integrity of Syslog messages at the Message level.[20] Calabrese & Apad Expires July 2, 2001 [Page 16] Internet-Draft Event Logging Requirements January 2001 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] University of California Computer Systems Research Group, "Unix Programmer's Manual, 4.3 Berkeley Software Distribution, Virtual VAX-11 Version", April 1986. [3] Brown, A., Calabrese, C., Lonvick, C.M., Reed, D. and M. Roth, "Messages on the Syslogsec@employees.org mailing list", mailing list archive available from http://www.mail-archive.com/syslog-sec%40employees.org/, October, November and December 1999. [4] U.S. Department of Defense, Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, available from http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html , December 1985. [5] ISO/IEC, "Common Criteria for Information Technology Security Evaluation Version 2.1", International Standard ISO/IEC 15408:1999, available from http://www.radium.ncsc.mil/tpep/library/ccitse/ccitse.html, August 1999. [6] U.S. National Security Agency, Information Systems Security Organization, "Labeled Security Protection Profile", available from http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html , October 1999. [7] Scheidler, B., "Private correspondence", March 2000. [8] Roth, M., "Private Correspondence", March 2000. [9] U.S. National Security Agency, Information Systems Security Organization, "Controlled Access Protection Profile", available from http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html , October 1999. [10] Lonvick, C.M., "syslog Protocol", draft-ietf-syslog-syslog-03 (work in progress), January 2001. [11] Schneier, B. and J. Kelsey, "Cryptographic Support for Secure Logs on Untrusted Machines", The Seventh USENIX Security Calabrese & Apad Expires July 2, 2001 [Page 17] Internet-Draft Event Logging Requirements January 2001 Symposium Proceedings, USENIX Press pp. 53-62, available from http://www.counterpane.com/secure-logs.html, January 1998. [12] Schneier, B. and J. Kelsey, "Minimizing Bandwidth for Remote Access to Cryptographically Protected Audit Logs", Second International Workshop on the Recent Advances inIntrusion Detection (RAID '99), available from http://www.counterpane.com/auditlog2.html, September 1999. [13] Reed, D., "Nsyslogd home web page", available from http://coombs.anu.edu.au/~avalon/nsyslog.html. [14] Core-SDI, "README file for the Secure Syslog package", available from http://www.core-sdi.com/english/slogging/ssyslog-dl.html, 1998. [15] Abela, J. and T. Debeaupuis, "Universal Format for Logger Messages", May 1999. [16] Jombart, N., "Private correspondence", May 2000. [17] BaliBit Computing, "Syslog-ng home web page,", available from http://www.balabit.hu/products/syslog-ng/. [18] New, D. and M.T. Rose, "Reliable Delivery for Syslog", draft-ietf-syslog-reliable-03 (work in progress), November 2000. [19] Kelsey, J., "Syslog-Auth Protocol", draft-ietf-syslog-auth-00 (work in progress), December 2000. [20] Kelsey, J., "Syslog-Sign Protocol", draft-ietf-syslog-sign-00 (work in progress), December 2000. [21] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [22] Blumenthal, U. and B. Winjen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [23] McCloghrie, K., Presuhn, R. and B. Winjen, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMPv3)", RFC 2575, April 1999. Calabrese & Apad Expires July 2, 2001 [Page 18] Internet-Draft Event Logging Requirements January 2001 Authors' Addresses Christopher J. Calabrese The SANS Institute 26 Wellesley Road Upper Montclair, NJ 07043 US Phone: +1 973 233 1464 EMail: chris_calabrese@yahoo.com Magosanyi Arpad Association of Hungarian Linux Users EMail: mag@lme.linux.hu Calabrese & Apad Expires July 2, 2001 [Page 19] Internet-Draft Event Logging Requirements January 2001 Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Alex Brown, Tony Finch, Chris M. Lonvick, David T. Perkins, Darren Reed, Mark Roth, Herve Schauer, and Balazs Scheidler. Calabrese & Apad Expires July 2, 2001 [Page 20] Internet-Draft Event Logging Requirements January 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Calabrese & Apad Expires July 2, 2001 [Page 21]