Internet DRAFT - draft-calabrese-requir-logprot
draft-calabrese-requir-logprot
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]
