--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
INTERNET DRAFT C. Calabrese
Expires: ??? Merck-Medco Managed Care, L.L.C.
<xml-log.html> 29 Oct. 1999
XML for Secure System Logs
----------
Status of this Memo
This document is rough sketch/draft of an Internet Draft. Distribution of this memo is
unlimited.
----------
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
----------
Table of Contents
* Overview
* Specification
* Examples
* Deviation from Pure XML
* Implementation Considerations
* Discussion
* Security Considerations
* References
* Author's Address
----------
1. Overview
One of the most important aspects of system, application, and security administration
is event logging. Such logging involves capturing information about important events,
possibly transmitting that information to a centralized logging facility,
timestamping/filtering/manipulating the information, recording the information to
persistent storage, and finally filtering, retrieval and analysis by events by an
off-line program or person.
This memo concerns itself with the ability to the presentation layer and application
layer issues of expressing logging information transport over a network or for
persistent storage while maintaining ensuring log privacy and authenticity.
In particular, this memo introduces an Extensible Markup Language (XML) encoding to
deal with the problem of expressing log entries as well as authentication and
encryption of those entries [W3C98].
----------
2. Specification
The scheme employed for basic log entries is, for the most part, an "XML-ization" of
the Universal Format for Logger Messages (ULM) [ULM99].
Privacy and authenticity for log entries is handled by "wrapping" the basic log
entries in privacy and authenticity XML elements much the same way that network
traffic may be wrapped in IPsec, SSL, TLS, etc. This would most likely be done using
standard for XML digital signatures being worked on by the IETF and W3C [W3C99].
However, an alternative scheme could be developed if this standard turns out not to
meet the needs of secure system logging.
Finally, intermediate-hop and final-hop hosts may put their own mark on the logs by
putting their own privacy, authenticity, or timestamp wrappers around the messages
they receive.
2.1. XML Specification
Note: While the author is developing a formal XML specification, it has been omitted
from this draft version of this memo.
2.2. Explanation
2.2.1. Basic Log Entry
The log:EVNT element contains information generated by the original process generating
the log entry.
log:SEV
Severity of the event as an integer in the space 0..99, with 0 as the lowest severity.
Note: log:SEV is a required log attribute. Note: A future draft of this memo should
contain a standard mapping from syslog and SNMP severity levels into the 0..99 space
of log:SEV.
log:PROC.NAME, log:PROC.ID, log:PROC.USR, log:PROC.MAIL, log:PROC.GRP, log:PROC.PRIV,
log:PROC.TTY
Information identifying the program/process generating the event. Respectively, they
are:
* The name of the program generating the event. Can either be a simple name
("Sendmail"), or a hierarchy identifying the program and it's facility
("Mail/MTA/Sendmail", "Audit/Tripwire", "Kernel/FS/Buffer_Cache"). Note: log:PROC.NAME
is a required log attribute. Note: A future draft of this memo should specify standard
facility hierarchies.
* An identification of the instance of the program/process that generated the
event. On a Unix system, this would by the process identification (PID) plus the
thread identifier for multi-threaded processes ("2207.3"). Note: log:PROC.ID is a
required log attribute.
* The user/login/account the process is running as ("chris", "id748").
* An e-mail address associated with the usr/login/account the process is running
as.
* The group(s) the process belongs to ("bin,mail").
* Other special priveleges the process has ("EUID-root, EGID-kmem, DAC_READ")
Note: A future draft of this memo should specify standard nomclementure for Unix
setuid and setgid priveleges, for Window NT priveleges, and for IEEE 1003.1e/2c
priveleges.
* The TTY or other description of the user's physical connection to the host
generating the event.
log:EVENT.TYPE
Gives a further taxonomy of the type of event that occurred. Allowed values given
under log:Event_Type_Enumeration.
XML:LANG
The language used for any textual messages in the standard XML LangCode format
[W3C98].
log:DUR
Duration of the event being logged in seconds.
log:SRC.ADDR, log:SRC.PROT, log:SRC.FQDN, log:SRC.NAME, log:SRC.USR, log:SRC.MAIL
For events representing network traffic, these attributes represent information about
the source of the traffic. Respectively, they are
* The network source address in log:Address_Format.
* The network protocols/ports used in log:Protocol_Format ("IP/TCP/25/ESMTP",
"IP/ICMP/Source_Quench").
* The fully qualified domain name for the source host.
* Some other unique identifier for the source host.
* The source user/login/account.
* An e-mail address associated with the traffic source.
log:DST.ADDR, log:DST.PROT, log:DST.FQDN, log:DST.NAME, log:DST.USR, log:DST.MAIL
Attributes representing the traffic destination.
log:REL.IN.ADDR, log:REL.IN.PROT, log:REL.IN.FQDN, log:REL.IN.NAME, log:REL.IN.USR,
log:REL.IN.MAIL, log:REL.OUT.ADDR, log:REL.OUT.PROT, log:REL.OUT.FQDN,
log:REL.OUT.NAME, log:REL.OUT.USR, log:REL.OUT.MAIL,
Attributes representing inbound and outbound traffic to a relay or proxy.
log:VOL, VOL.SENT, VOL.RCVD
Total data volume in octets, volume sent, and volume received.
log:CNT, log:CNT.SENT, log:CNT.RCVD
Total data volume in records, records sent, and records received.
log:PROG.FILE, log:PROG.LINE
The name of the program source file and line number within the source file. Typically
used for debugging and assert messages.
log:DOC
Name of an accessed document/file, such as an FTP file, a newsgroup, or a URL.
log:CMD
Issued command that generated the event. For example:
<log:EVNT log:PROC.NAME="cron" log:PROC.USR="news" log:PROC.GRP="news"
log:CMD="/usr/local/news/bin/news.daily/exprire delayrm" DUR=927>
log:MSG
Free form message text.
2.2.2. Receiving Identifiers
The log:RCVD element contains information generated by logging subsystems. When a
program generates a log:EVNT, the receiving logging subsystem (most likely part of the
trusted computing base on the same machine) will wrap it with its own identifiers.
When one machine transmits a log stream to another, the receiving machine may also
wish to wrap the log stream received with its identifiers.
Note: The log:RCVD element could also be extended to provide authenticity and
non-repudiation guarantees by adding digital signature elements. However, these
capabilities have not been specified in the the current draft of this memo because it
is assumed they will be provided the forthcoming standard for XML digital standards
[W3C99].
log:HOST
The host receiving the log.
log:DATE
The date/time at which the log was received in ISO.8601:1998_Date_Format.
log:SEQ
A sequence number other than date/time used to serialize logs received by the host and
for detecting deleted logs.
2.2.3. Data Types
log:Severity_Type
('0'|'1'|...|'99')
ISO.8601:1998_Date_Format
(YYYY '-' MM '-' DD 'T' hh ':' mm [':' ss ['.' f+]]('+' | '-') zzzz)
log:Event_Type_Enumeration
('AUTH.FAIL'|'AUTH.SUCCESS'|'PROC.FAIL'|'PROC.START'|...)
Seconds.Decimal
(s+ ['.' f+])
log:Address_Format
(IPv4_Address|IPv6_Address|IPX_Address|...)
log:Protocol_Format
( ('IPv4/' ('UDP'|'TCP') '/' IPv4_Port_Number ['/' CDATA]) | ('IPv4/ICMP/'
IPv4_ICMP_Message_Type) | ... | ('IPX' ['/SPX/' IPX_Port_Number ['/' CDATA]) )
----------
3. Examples
3.1. Nested
log:RCVD
Entries
This example shows nested log:RCVD elements used to place timestamp/sequence
information on log entries by successive machines:
<log:RCVD log:HOST=central_log_server.somewhere.com
log:DATE=1999-10-27T3:00 log:SEQ=403409 >
<log:RCVD log:HOST=log_relay.somewhere.com
log:DATE=1999-10-27T2:59 log:SEQ=56789 >
<log:RCVD log:HOST=originating_host.somewhere.com
log:DATE=1999-10-27T2:58 log:SEQ=12324 >
<log:EVNT log:SEV=80
log:PROC.NAME="Audit/Tripwire" log:PROC.ID=1234
log:MSG="unexpected file" log:DOC="/a/b/c"/>
</log:RCVD>
</log:RCVD>
</log:RCVD>
3.2. Nested
log:EVNT
Entries
At first blush, it's not obvious why we need a MSG attribute when we could use
something like:
<log:EVNT ...>this is the text</log:EVNT>
The reason is to allow log:EVNT elements to nest. One possible interpretation of
nested log entries is to be able to represent complex relationships in the data.
Instead, here we use nesting to collapse redundant data. For example, the following
are considered equivalent:
<log:RCVD log:HOST=myhost log:DATE=1999-10-27T2:58>
<log:EVNT log:SEV=80
log:PROC.NAME="Audit/Tripwire" log:PROC.ID=1234
log:MSG="unexpected file" log:DOC="/a/b/c"/>
<log:EVNT log:SEV=80
log:PROC.NAME="Audit/Tripwire" log:PROC.ID=1234
log:MSG="unexpected file" log:DOC="/a/b/d"/>
<log:EVNT log:SEV=80
log:PROC.NAME="Audit/Tripwire" log:PROC.ID=1234
log:MSG="unexpected file" log:DOC="/a/b/e"/>
</log:RCVD>
<log:RCVD log:HOST=myhost log:DATE=1999-10-27T2:58>
<log:EVNT log:SEV=80
log:PROC.NAME="Audit/Tripwire" log:PROC.ID=1234
log:MSG="unexpected file">
<log:EVNT log:DOC="/a/b/c"/>
<log:EVNT log:DOC="/a/b/d"/>
<log:EVNT log:DOC="/a/b/e"/>
</log:EVNT>
</log:RCVD>
As a result, only inner-most log:EVNT elements are log entries. Outer log:EVNT
elements set attributes common to the contained entries.
----------
4. Deviation from Pure XML
Although XML is a good fit for the structure needed to describe system logs, it is not
a perfect fit. In particular:
* In the interest of compactness, logs will be considered complete even if they do
not contain the standard XML prolog containing the XML version, element declarations,
etc.
* Also in the interest of compactness, log message streams not beginning with <
will assume to be bracketed by '<log:' and '>'. This way, the existing syslog behavior
of sending a single log entry inside a single UDP packet may be preserved.
* Some might argue that having the free-form messages as log:MSG attribute values
is somewhat messy from an XML standpoint and that "proper" XML would be to unravel the
nesting and put the message text in as the "payload" of the log:EVNT elements.
Implementations may contain a tool to generate 100% XML compliant "documents" from log
files so that the logs may be processed by standard XML tools.
----------
5. Implementation Considerations
5.1. Network Communications
5.1.1. Transport
5.1.1.1. Transmission Over UDP
5.1.1.2. Transmission Over TCP
5.1.1.3. Non-IP Transport
5.1.2. Session, Transport, and Network Layer Security
5.1.2.1. TLS/SSL
5.1.2.2. IPsec
5.1.3. Delivery Guarantees
5.2. Event Filtering
5.3. Event Viewing/Reporting
5.4. Logging API's
5.5. Backward Compatibility
5.5.1. Syslog
5.5.2. NT Event Logger
----------
5.6. Discussion
----------
5.7. Security Considerations
5.7.1. Privacy of Log Messages
5.7.2. Authenticity of Log Messages
5.7.3. Non-Repudiation of Log Messages
5.7.4. Immutability of Log Messages Without Detection
5.7.5. Denial of Service Attacks Against Log Servers
----------
5.8. References
[ULM99]
J. Abela and T. Debeaupis, "Universal Format for Logger Messages." The Internet
Society, May 1999. Available from
<ftp://ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt>ftp.ietf.org/internet-drafts/draft-abela-ulm-05.<ftp://ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt>txt.
[W3C98]
World Wide Web Consortium, "Extensible Markup Language (XML) 1.0." February 1998.
Available from
<http://www.w3.org/tr/rec-xml>www.w3.org/TR/REC-<http://www.w3.org/tr/rec-xml>xml.
[W3C99]
World Wide Web Consortium, "Digital Signature Initiative Activity Statement." October
1999. Available from
<http://www.w3.org/signature/activity.html>www.w3.org/Signature/Activity.<http://www.w3.org/signature/activity.html>html.
----------
5.9. Author's Address
C. Calabrese Merck-Medco Managed Care, L.L.C. 1900 Pollitt Drive Fair Lawn, NJ, USA
07410
Phone: (201) 703-7218 EMail:
<mailto:[EMAIL PROTECTED]>christopher_calabrese@merck.<mailto:[EMAIL PROTECTED]>com
