FYI, I was working on similar stuff a while back. It was an XML model based on Abela and Debeaupuis' ULM model, and Nicolas Jombart had modifed HSC's ULM-ified syslog to deal with it. There was also some vendor interest.
I'm too busy with Center for Internet Security stuff to work on this actively, but feel free to borrow/steal liberally (just give me credit where due).. Marshall Glen wrote: >Thanks, Chris. > >Yes, mine is an independent effort and not a document for this Working >Group. I just provided it here as an example of the sort of payload that >could be carried by a syslog message. > >Some of the people I'm working with would like to implement RFC 3195 as the >message transport, but the message itself is specified in a way that makes >it transport-independent. There are two basic cases: > >1) Dedicated-function devices such as clinical monitors and digital medical >imaging would like a simple but reliable method to report audit data (and, >conceptually, other system events) to a central event processing and >repository service. This is where syslog is seen as the best solution >direction. > >2) Some multi-function systems, such as healthcare information systems and >distributed networks, could use a standard method that enables >two-interaction for audits (e.g., security alarm actions) and system events >(e.g., enabling partial failure operating modes). In this case a messaging >transport such as ebXML might be a better choice. > >Having only recently started following the listserv traffic in this group, I >don't know if these sorts of distinctions have been discussed previously. > >Best, >Glen > >-----Original Message----- >From: Christopher Lonvick [mailto:[EMAIL PROTECTED]] >Sent: Thursday, December 19, 2002 1:52 PM >To: Marshall Glen >Cc: [EMAIL PROTECTED] >Subject: Re: Syslog Payload (was "What Can Be Changed in syslog") > > >Hi Glen, > >I don't mind if you ask this WG for input on your ID. However, our >charter won't allow it to become a document of this Working Group. >The same goes for any other proposal related to the formatting of >the payload of syslog messages. > >All: Glen would like to get this ID through the process so it may >become an RFC. Having it reviewed by like-minded people helps that >process. If you have time+effort, please send comments either to >the list or to Glen. > >Thanks, >Chris > >On Tue, 17 Dec 2002, Marshall Glen wrote: > > > >>Relative to syslog payload format, that may be partly a function of >>application domains. I'll call your attention to a draft I posted at the >>beginning of this month: >> >>http://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt >> >>Conceptually, this defines what could be a security audit payload for RFC >>3195 in the healthcare application domain. >> >>Best, >>Glen F. Marshall >> >> >>-----Original Message----- >>From: Christopher Lonvick [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, December 17, 2002 17:41 >>To: [EMAIL PROTECTED] >>Subject: What Can Be Changed in syslog >> >> >>Hi, >> >>I appreciate the thoughts of everyone on the topics brought up so far. >> >> >Let's > > >>make sure that we all understand what we can do within the current scope >> >> >of > > >>the WG. >> >>TIMESTAMP This field may be changed in syslog-sign. We'll have to rev >> 3195 to accept this after syslog-sign is accepted as an RFC. >> >>non-US-ASCII characters in the payload. This may be addressed in >> syslog-sign, or specified in another Internet Draft (which will >> be accepted as a WG document if there are enough people >> supporting the idea). Just for reference: >> ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt >> A Tangled Web: Issues of I18N, Domain Names, and the >> Other Internet protocols >> >>payload length. It's up to the WG to change this. It may be changed in >> syslog-sign if that's the concensus of the WG. In that case, >> syslog-sign will have to have dire warnings of trying to push >> the new format through old-style (3164) relays or collectors. >> We'll have to do that anyway if we change the TIMESTAMP. >> >>payload format. Out of scope. I'll allow discussion on the WG mailing >> list (here) but anything coming from that cannot be a document >> of this WG. After we accomplish our Charter Goals, we may ask >> the ADs to allow the WG to reCharter the WG to address that. >> ..but not at this time. >> >>I'll ask anyone interested in making changes to any of these to post notes >>to the WG list preferably with a suggestion of modifications to the >> >> >current > > >>IDs, or a suggestion to write a new ID (with the commitment of being the >>author. :) >> >>Let's separate these components apart from the discussion topic of a >> >> >"light" > > >>reliable transport. >> >>Thanks, >>Chris >> >> >> >> >> >---------------------------------------------------------------------------- >--- > > >>This message and any included attachments are from Siemens Medical >> >> >Solutions > > >>Health Services Corporation and are intended only for the addressee(s). >>The information contained herein may include trade secrets or privileged >> >> >or > > >>otherwise confidential information. Unauthorized review, forwarding, >> >> >printing, > > >>copying, distributing, or using such information is strictly prohibited >> >> >and may > > >>be unlawful. If you received this message in error, or have reason to >> >> >believe > > >>you are not authorized to receive it, please promptly delete this message >> >> >and > > >>notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you >> >> >> >> > >------------------------------------------------------------------------------- >This message and any included attachments are from Siemens Medical Solutions >Health Services Corporation and are intended only for the addressee(s). >The information contained herein may include trade secrets or privileged or >otherwise confidential information. Unauthorized review, forwarding, printing, >copying, distributing, or using such information is strictly prohibited and may >be unlawful. If you received this message in error, or have reason to believe >you are not authorized to receive it, please promptly delete this message and >notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you > > > > -- Chris Calabrese, GCIA, GCFA Internet Security Analyst MedcoHealth.com <html><head><title>XML for Secure System Logs</title> <STYLE type='text/css'> .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right; font-family: helvetica, arial, sans-serif } .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right; font-family: helvetica, arial, sans-serif } p.copyright { color: #000000; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif } p { margin-left: 2em; margin-right: 2em; } ol { margin-left: 2em; margin-right: 2em; } ul.text { margin-left: 2em; margin-right: 2em; } pre { margin-left: 3em; color: #333333 } ul.toc { color: #000000; line-height: 16px; font-family: verdana, charcoal, helvetica, arial, sans-serif } H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif } H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif } TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top } TD.author-text { color: #000000; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif } TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif } A:link { color: #990000; font-size: 10px; text-transform: uppercase; font-weight: bold; font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } A:visited { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase; font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } A:name { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase; font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } .link2 { color:#ffffff; font-weight: bold; text-decoration: none; font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; font-size: 9px } .RFC { color:#666666; font-weight: bold; text-decoration: none; font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; font-size: 9px } .hotText { color:#ffffff; font-weight: normal; text-decoration: none; font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; font-size: 9px } </style> </head> <body bgcolor="#ffffff"text="#000000" alink="#000000" vlink="#666666" link="#990000"> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1"> <tr valign="top"><td width="33%" bgcolor="#666666" class="header">Network Working Group</td><td width="33%" bgcolor="#666666" class="header">C. J. Calabrese</td></tr> <tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">The SANS Institute</td></tr> <tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: July 16, 2001</td><td width="33%" bgcolor="#666666" class="header">January 15, 2001</td></tr> </table></td></tr></table> <div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">XML for Secure System Logs</span></b></font></div> <div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-calabrese-xml-log-00</span></b></font></div> <font face="verdana, helvetica, arial, sans-serif" size="2"> <h3>Status of this Memo</h3> <p> This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p> <p> 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.</p> <p> 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."</p> <p> The list of current Internet-Drafts can be accessed at <a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> <p> The list of Internet-Draft Shadow Directories can be accessed at <a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> <p> This Internet-Draft will expire on July 16, 2001.</p> <h3>Copyright Notice</h3> <p> Copyright (C) The Internet Society (2001). All Rights Reserved.</p> <h3>Abstract</h3> <p> This memo presents an Extensible Markup Language <a href="#W3C98">(XML)</a>[16] encoding that applications may use to express logging information in a structured manner. Thus making these logs easier for computer programs to parse the the free-form data traditionally associated with <a href="#CSRG">Syslog</a>[3]-based logs. </p> <a name="toc"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>Table of Contents</h3> <ul compact class="toc"> <b><a href="#introduction">1.</a> Introduction<br></b> <b><a href="#overview">2.</a> Schema Overview<br></b> <b><a href="#examples">3.</a> Examples<br></b> <b><a href="#anchor1">3.1</a> Nested `log:EVNT' Entries<br></b> <b><a href="#xml-deviation">4.</a> Deviation from Pure XML<br></b> <b><a href="#implementation">5.</a> Implementation Considerations<br></b> <b><a href="#anchor2">5.1</a> Event Filtering<br></b> <b><a href="#anchor3">5.2</a> Event Viewing/Reporting<br></b> <b><a href="#anchor4">5.3</a> Logging API's<br></b> <b><a href="#anchor5">5.4</a> Backward Compatibility<br></b> <b><a href="#anchor6">5.4.1</a> Syslog<br></b> <b><a href="#anchor7">5.4.2</a> NT Event Logger<br></b> <b><a href="#anchor8">5.5</a> Network Communications<br></b> <b><a href="#sec">6.</a> Security Considerations<br></b> <b><a href="#anchor9">6.1</a> Correctness and Completeness of Identifying Information<br></b> <b><a href="#anchor10">6.2</a> Confidentiality, Integrity, and Availability of Log Messages<br></b> <b><a href="#rfc.references">§</a> References<br></b> <b><a href="#rfc.authors">§</a> Author's Address<br></b> <b><a href="#anchor11">A.</a> XML DTD for the `log:EVNT' Element<br></b> <b><a href="#data_types">B.</a> XML DTD for Data Types Used in the `log:EVNT' Element<br></b> <b><a href="#rfc.copyright">§</a> Full Copyright Statement<br></b> </ul> <br clear="all"> <a name="introduction"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>1. Introduction</h3> <p> 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. <br> <br> This memo presents an Extensible Markup Language <a href="#W3C98">(XML)</a>[16] encoding that applications may use to express logging information in a structured manner. Thus making these logs easier for computer programs to parse the the free-form data traditionally associated with <a href="#CSRG">Syslog</a>[3]-based logs. <br> <br> This scheme is, for the most part, an "XML-ization" of the Abela and Debeaupuis' Universal Format for Logger Messages <a href="#ULM">(ULM)</a>[11]. A new version of their ULM tool has been written by Nicolas Jombart to deal with an earlier version of this XML-ized format<a href="#Jombart">[12]</a>. <br> <br> 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 <a href="#RFC2119">RFC 2119</a>[1]. </p> <a name="overview"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>2. Schema Overview</h3> <p> The basic idea is very straight forward. Each log entry is represented by a 'log:EVNT' element. Inside this element are the following attributes: <blockquote class="text"><dl> <dt>log:HOST</dt> <dd> The host on which the log entry was originally generated. </dd> <dt>log:DATE</dt> <dd> The date/time at which the log was generated in '<a href="#data_types">ISO.8601:1998_Date_Format</a>'. <a href="#ISO.8601">[2]</a> </dd> <dt>log:SEV</dt> <dd> Severity of the event using the standard <a href="#CSRG">Syslog</a>[3] as enumerated in '<a href="#data_types">log:SEV_Format</a>' (`LOG_DEBUG', `LOG_INFO', `LOG_NOTICE', `LOG_WARNING', `LOG_ERR', `LOG_CRIT', `LOG_ALERT', `LOG_EMERG',). <br> When operating in Windows NT environments, the native NT Event Types (`Information', `Warning', `Error', `Success Audit', and `Falure Audit') should map into `LOG_INFO', `LOG_WARNING',, `LOG_ERR', `LOG_INFO', and `LOG_INFO' respecitively. <br> <br> Similarly, the standard SNMP Trap Severities (`Normal', `Warning', `Minor', `Major', and `Critical') should map into `LOG_INFO', `LOG_WARNING', `LOG_ERR', `LOG_ERR', and `LOG_CRIT' respecitively. <br> <br> NOTE: Need references for NT and SNMP </dd> <dt>log:PROC.NAME</dt> <dd> 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: Standard hiercharies need to be specified. </dd> <dt>log:PROC.ID</dt> <dd> 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'). </dd> <dt>log:PROC.PRIV</dt> <dd> A list of any security ID's/groups/labels associated with the process generating the log entry (`USR-chris, UID-748, GRP-adm, GRP-sys, GRP-users, EUID-root, EGID-kmem, DAC_READ, SYSTEM_HIGH') NOTE: Need to specify standard nonclemature for Unix, NT, and IEEE 1003.1e/2c priveleges. Also, do we really want to do it this way, or would it be better done as different attribute types, or even nested elements or something? </dd> <dt>log:PROC.MAIL</dt> <dd> An e-mail address associated with the usr/login/account the process is running as. </dd> <dt>log:PROC.TTY</dt> <dd> The TTY or other description of the user's physical connection to the host generating the event. </dd> <dt>log:EVENT.TYPE</dt> <dd> Gives a further taxonomy of the type of event that occurred. Allowed values given under '<a href="#data_types">log:Event_Type_Enumeration</a>'. </dd> <dt>XML:LANG</dt> <dd> The language used for any textual messages in the standard XML `LangCode' format<a href="#W3C98">[16]</a>. </dd> <dt>log:DUR</dt> <dd> Duration of the event being logged in '<a href="#data_types">Seconds.Decimel</a>' format. </dd> <dt>log:SRC.ADDR (log:DST.ADDR)</dt> <dd> The network source (destination) address of any network traffic represented by this event in '<a href="#data_types">log:Address_Format</a>'. </dd> <dt>log:SRC.PROT (log:DST.PROT)</dt> <dd> The network protocols/ports used by the source (destination) of network traffic in '<a href="#data_types">log:Protocol_Format</a>' (`IP/TCP/25/ESMTP', `IP/ICMP/Source_Quench'). </dd> <dt>log:SRC.FQDN (log:DST.FQDN)</dt> <dd> The fully qualified domain name for the traffic source (destination). </dd> <dt>log:SRC.NAME (log:DST.NAME)</dt> <dd> Some other unique identifier for the traffic source (destination). </dd> <dt>log:SRC.USR (log:DST.USR)</dt> <dd> A user/login/account associated with the traffic source (destination). </dd> <dt>log:SRC.MAIL (log.DST.MAIL)</dt> <dd> An e-mail address associated with the traffic source (destination). </dd> <dt>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</dt> <dd> Similar to the `log:SRC.' and `log:DST.' attributes, but representing inbound and outbound traffic through a relay or proxy. </dd> <dt>log:VOL, VOL.SENT, VOL.RCVD</dt> <dd> Total data volume in octets, volume sent, and volume received. </dd> <dt>log:CNT, log:CNT.SENT, log:CNT.RCVD</dt> <dd> Total data volume in records, records sent, and records received. </dd> <dt>log:PROG.FILE, log:PROG.LINE</dt> <dd> The name of the program source file and line number within the source file. Typically used for debugging and assert messages. </dd> <dt>log:DOC</dt> <dd> Name of an accessed document/file, such as an FTP file, a newsgroup, or a URL. </dd> <dt>log:CMD</dt> <dd> Issued command that generated the event. For example: </font><pre> <log:EVNT ... log:CMD="/bin/rm -rf /"> </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> </dd> <dt>log:MSG</dt> <dd> Free form message text. </dd> </dl></blockquote> </p> <a name="examples"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>3. Examples</h3> <h4><a name="anchor1">3.1</a> Nested `log:EVNT' Entries</h4> <p> At first blush, it's not obvious why we need a MSG attribute when we could use something like: </font><pre> <log:EVNT ...>this is the text</log:EVNT> </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> 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: </font><pre> <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: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> </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> As a result, only inner-most `log:EVNT' elements are log entries. Outer `log:EVNT' elements set attributes common to the contained entries. </p> <a name="xml-deviation"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>4. Deviation from Pure XML</h3> <p> Although XML is a good fit for the structure needed to describe system logs, it is not a perfect fit. In particular: <ol class="text"> <li> 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. </li> <li> 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. </li> <li> 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. </li> </ol> 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. </p> <a name="implementation"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>5. Implementation Considerations</h3> <h4><a name="anchor2">5.1</a> Event Filtering</h4> <p> NOTE: Need info about filtering... </p> <h4><a name="anchor3">5.2</a> Event Viewing/Reporting</h4> <p> NOTE: Need info viewing/reporting... </p> <h4><a name="anchor4">5.3</a> Logging API's</h4> <p> NOTE: Need info on API's, especially making sure that the TCB generates whatever information it can. Refer to sec section. </p> <h4><a name="anchor5">5.4</a> Backward Compatibility</h4> <h4><a name="anchor6">5.4.1</a> Syslog</h4> <p> NOTE: Need info on this..., especially issue of including level/facility info in both XML and native syslog levels. </p> <h4><a name="anchor7">5.4.2</a> NT Event Logger</h4> <p> NOTE: Need info on this... </p> <h4><a name="anchor8">5.5</a> Network Communications</h4> <p> NOTE: Need info on this..., including references to Syslog WG work. </p> <a name="sec"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>6. Security Considerations</h3> <h4><a name="anchor9">6.1</a> Correctness and Completeness of Identifying Information</h4> <p> NOTE: TCB should/must generate log:HOST log:DATE log:SEV log:PROC.NAME log:PROC.ID log:PROC.PRIV </p> <h4><a name="anchor10">6.2</a> Confidentiality, Integrity, and Availability of Log Messages</h4> <p> The confidentiality, integrity, and availability of log messages or logging mechanisms is beyond the scope of this memo. However, these issues are addressed in the following places. <br> NOTE: need references here... </p> <a name="rfc.references"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3> References</h3> <table width="99%" border="0"> <tr><td class="author-text" valign="top"><b><a name="RFC2119">[1]</a></b></td> <td class="author-text"><a href="mailto:[EMAIL PROTECTED]";>Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt";>Key words for use in RFCs to Indicate Requirement Levels</a>", RFC 2119, BCP 14, March 1997.</td></tr> <tr><td class="author-text" valign="top"><b><a name="ISO.8601">[2]</a></b></td> <td class="author-text">International Standards Organization, "Data elements and interchange formats - Information interchange - Representation of dates and times", International Standard ISO 8601:1988, available from http://www.iso.ch/markete/8601.pdf, 1988.</td></tr> <tr><td class="author-text" valign="top"><b><a name="CSRG">[3]</a></b></td> <td class="author-text">University of California Computer Systems Research Group, "Unix Programmer's Manual, 4.3 Berkeley Software Distribution, Virtual VAX-11 Version", April 1986.</td></tr> <tr><td class="author-text" valign="top"><b><a name="TCSEC">[4]</a></b></td> <td class="author-text">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.</td></tr> <tr><td class="author-text" valign="top"><b><a name="CC">[5]</a></b></td> <td class="author-text">International Standards Organization, "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.</td></tr> <tr><td class="author-text" valign="top"><b><a name="LSPP">[6]</a></b></td> <td class="author-text">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.</td></tr> <tr><td class="author-text" valign="top"><b><a name="CAPP">[7]</a></b></td> <td class="author-text">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.</td></tr> <tr><td class="author-text" valign="top"><b><a name="Lonvick">[8]</a></b></td> <td class="author-text"><a href="mailto:[EMAIL PROTECTED]";>Lonvick, C.M.</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-syslog-03.txt";>syslog Protocol</a>", draft-ietf-syslog-syslog-03 (work in progress), January 2001.</td></tr> <tr><td class="author-text" valign="top"><b><a name="SK98">[9]</a></b></td> <td class="author-text"><a href="http://www.counterpane.com";>Schneier, B.</a> and <a href="mailto:[EMAIL PROTECTED]";>J. Kelsey</a>, "Cryptographic Support for Secure Logs on Untrusted Machines", The Seventh USENIX Security Symposium Proceedings, USENIX Press pp. 53-62, available from http://www.counterpane.com/secure-logs.html, January 1998.</td></tr> <tr><td class="author-text" valign="top"><b><a name="SK99">[10]</a></b></td> <td class="author-text"><a href="http://www.counterpane.com";>Schneier, B.</a> and <a href="mailto:[EMAIL PROTECTED]";>J. Kelsey</a>, "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.</td></tr> <tr><td class="author-text" valign="top"><b><a name="ULM">[11]</a></b></td> <td class="author-text"><a href="http://www.hsc.fr";>Abela, J.</a> and <a href="http://www.hsc.fr";>T. Debeaupuis</a>, "Universal Format for Logger Messages", May 1999.</td></tr> <tr><td class="author-text" valign="top"><b><a name="Jombart">[12]</a></b></td> <td class="author-text"><a href="mailto:[EMAIL PROTECTED]";>Jombart, N.</a>, "Private correspondence", May 2000.</td></tr> <tr><td class="author-text" valign="top"><b><a name="syslog-reliable">[13]</a></b></td> <td class="author-text"><a href="mailto:[EMAIL PROTECTED]";>New, D.</a> and <a href="mailto:[EMAIL PROTECTED]";>M.T. Rose</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-reliable-02.txt";>Reliable Delivery for Syslog</a>", draft-ietf-syslog-reliable-02 (work in progress), November 2000.</td></tr> <tr><td class="author-text" valign="top"><b><a name="syslog-auth">[14]</a></b></td> <td class="author-text"><a href="mailto:[EMAIL PROTECTED]";>Kelsey, J.</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-auth-00.txt";>Syslog-Auth Protocol</a>", draft-ietf-syslog-auth-00 (work in progress), December 2000.</td></tr> <tr><td class="author-text" valign="top"><b><a name="syslog-sign">[15]</a></b></td> <td class="author-text"><a href="mailto:[EMAIL PROTECTED]";>Kelsey, J.</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-00.txt";>Syslog-Sign Protocol</a>", draft-ietf-syslog-sign-00 (work in progress), December 2000.</td></tr> <tr><td class="author-text" valign="top"><b><a name="W3C98">[16]</a></b></td> <td class="author-text"><a href="http://www.w3c.org";>World Wide Web Consortium</a>, "Extensible Markup Language (XML) 1.0.", available from http://www.w3.org/TR/REC-xml, February 1998.</td></tr> </table> <a name="rfc.authors"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>Author's Address</h3> <table width="99%" border="0" cellpadding="0" cellspacing="0"> <tr><td class="author-text"> </td> <td class="author-text">Christopher J. Calabrese</td></tr> <tr><td class="author-text"> </td> <td class="author-text">The SANS Institute</td></tr> <tr><td class="author-text"> </td> <td class="author-text">26 Wellesley Road</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Upper Montclair, NJ 07043</td></tr> <tr><td class="author-text"> </td> <td class="author-text">US</td></tr> <tr><td class="author" align="right">Phone: </td> <td class="author-text">+1 973 233 1464</td></tr> <tr><td class="author" align="right">EMail: </td> <td class="author-text"><a href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</a></td></tr> </table> <a name="anchor11"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>Appendix A. XML DTD for the `log:EVNT' Element</h3> <p> </font><pre> <!-- Note that attributes are marked REQUIRED -- here if it is implied by draft-calabrese-requir-loggprot-01. -- This assumes this information is not being provided by -- another source. --> <!ELEMENT log:ENTRY (log:ENTRY)*> <!ATTLIST log:ENTRY log:HOST CDATA #REQUIRED log:DATE ISO.8601:1998_Date_Format #REQUIRED log:SEV log:Severity_Type #REQUIRED log:PROC.NAME CDATA #REQUIRED log:PROC.ID CDATA #REQUIRED log:PROC.PRIV CDATA #REQUIRED log:PROC.MAIL CDATA #IMPLIED log:PROC.TTY CDATA #IMPLIED log:EVENT.TYPE log:Event_Type_Enumeration #IMPLIED log:XML:LANG LangCode "EN" log:DUR Seconds.Decimal #IMPLIED log:SRC.ADDR log:Address_Format #IMPLIED log:SRC.PROT log:Protocol_Format #IMPLIED log:SRC.FQDN CDATA #IMPLIED log:SRC.NAME CDATA #IMPLIED log:SRC.USR CDATA #IMPLIED log:SRC.MAIL CDATA #IMPLIED log:DST.ADDR log:Address_Format #IMPLIED log:DST.PROT log:Protocol_Format #IMPLIED log:DST.FQDN CDATA #IMPLIED log:DST.NAME CDATA #IMPLIED log:DST.USR CDATA #IMPLIED log:DST.MAIL CDATA #IMPLIED log:REL.IN.ADDR log:Address_Format #IMPLIED log:REL.IN.PROT log:Protocol_Format #IMPLIED log:REL.IN.FQDN CDATA #IMPLIED log:REL.IN.NAME CDATA #IMPLIED log:REL.IN.USR CDATA #IMPLIED log:REL.IN.MAIL CDATA #IMPLIED log:REL.OUT.ADDR log:Address_Format #IMPLIED log:REL.OUT.PROT log:Protocol_Format #IMPLIED log:REL.OUT.FQDN CDATA #IMPLIED log:REL.OUT.NAME CDATA #IMPLIED log:REL.OUT.USR CDATA #IMPLIED log:REL.OUT.MAIL CDATA #IMPLIED log:VOL Integer #IMPLIED log:VOL.SENT Integer #IMPLIED log:VOL.RCVD Integer #IMPLIED log:CNT Integer #IMPLIED log:CNT.SENT Integer #IMPLIED log:CNT.RCVD Integer #IMPLIED log:PROG.FILE CDATA #IMPLIED log:PROG.LINE Integer #IMPLIED log:DOC CDATA #IMPLIED log:CMD CDATA #IMPLIED log:MSG CDATA #IMPLIED > </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> </p> <a name="data_types"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>Appendix B. XML DTD for Data Types Used in the `log:EVNT' Element</h3> <p> </font><pre> <!NOTATION log:Severity_Type ('0'|'1'|...|'99')> <!NOTATION ISO.8601:1998_Date_Format (YYYY '-' MM '-' DD 'T' hh ':' mm [':' ss ['.' f+]]('+' | '-') zzzz)> <!-- NOTE: Need reference and further explanation of date format --> <!NOTATION Seconds.Decimal (ss ['.' f+]) <!NOTATION log:Event_Type_Enumeration ('AUTH.FAIL'|'AUTH.SUCCESS'|'PROG.FAIL'|'PROG.START'|...)> <!-- NOTE: Need more complete enumeration. --> <!NOTATION log:Address_Format (IPv4_Address|IPv6_Address|IPX_Address|...)> <!-- NOTE: Do we need more a complete enumeration? of address types? --> <!NOTATION IPv4_Address CDATA > <!-- NOTE: Need proper definition and reference for IPv4 addresses --> <!NOTATION IPv6_Address CDATA> <!-- NOTE: Need proper definition and reference for IPv6 addresses --> <!NOTATION IPX_Address CDATA> <!-- NOTE: Need proper definition and reference for IPX addresses --> <!NOTATION log:Protocol_Format ( ('IPv4/' ('UDP'|'TCP') '/' IPv4_Port_Number ['/' CDATA]) | ('IPv4/ICMP/' IPv4_ICMP_Message_Type) | ( ('IPv6/' ('UDP'|'TCP') '/' IPv6_Port_Number ['/' CDATA]) | ('IPv6/ICMP/' IP64_ICMP_Message_Type) | ('IPX' ['/SPX/'] IPX_Port_Number ['/' CDATA]) ) <!-- NOTE: Need further definitions of referenced types... --> </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> </p> <a name="rfc.copyright"><br><hr size="1" shade="0"></a> <table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> <h3>Full Copyright Statement</h3> <p class='copyright'> Copyright (C) The Internet Society (2001). All Rights Reserved.</p> <p class='copyright'> 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.</p> <p class='copyright'> The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p> <p class='copyright'> 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.</p> <h3>Acknowledgement</h3> <p class='copyright'> Funding for the RFC editor function is currently provided by the Internet Society.</p> </font></body></html> Network Working Group C. J. Calabrese Internet-Draft The SANS Institute Expires: July 16, 2001 January 15, 2001 XML for Secure System Logs draft-calabrese-xml-log-00 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 16, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo presents an Extensible Markup Language (XML)[16] encoding that applications may use to express logging information in a structured manner. Thus making these logs easier for computer programs to parse the the free-form data traditionally associated with Syslog[3]-based logs. Calabrese Expires July 16, 2001 [Page 1] Internet-Draft XML for Secure System Logs January 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Schema Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Nested `log:EVNT' Entries . . . . . . . . . . . . . . . . . 7 4. Deviation from Pure XML . . . . . . . . . . . . . . . . . . 8 5. Implementation Considerations . . . . . . . . . . . . . . . 9 5.1 Event Filtering . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Event Viewing/Reporting . . . . . . . . . . . . . . . . . . 9 5.3 Logging API's . . . . . . . . . . . . . . . . . . . . . . . 9 5.4 Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 5.4.1 Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4.2 NT Event Logger . . . . . . . . . . . . . . . . . . . . . . 9 5.5 Network Communications . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . 10 6.1 Correctness and Completeness of Identifying Information . . 10 6.2 Confidentiality, Integrity, and Availability of Log Messages 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 A. XML DTD for the `log:EVNT' Element . . . . . . . . . . . . . 13 B. XML DTD for Data Types Used in the `log:EVNT' Element . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 Calabrese Expires July 16, 2001 [Page 2] Internet-Draft XML for Secure System Logs January 2001 1. Introduction 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 presents an Extensible Markup Language (XML)[16] encoding that applications may use to express logging information in a structured manner. Thus making these logs easier for computer programs to parse the the free-form data traditionally associated with Syslog[3]-based logs. This scheme is, for the most part, an "XML-ization" of the Abela and Debeaupuis' Universal Format for Logger Messages (ULM)[11]. A new version of their ULM tool has been written by Nicolas Jombart to deal with an earlier version of this XML-ized format[12]. 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 Expires July 16, 2001 [Page 3] Internet-Draft XML for Secure System Logs January 2001 2. Schema Overview The basic idea is very straight forward. Each log entry is represented by a 'log:EVNT' element. Inside this element are the following attributes: log:HOST The host on which the log entry was originally generated. log:DATE The date/time at which the log was generated in 'ISO.8601:1998_Date_Format (Appendix B)'. [2] log:SEV Severity of the event using the standard Syslog[3] as enumerated in 'log:SEV_Format (Appendix B)' (`LOG_DEBUG', `LOG_INFO', `LOG_NOTICE', `LOG_WARNING', `LOG_ERR', `LOG_CRIT', `LOG_ALERT', `LOG_EMERG',). When operating in Windows NT environments, the native NT Event Types (`Information', `Warning', `Error', `Success Audit', and `Falure Audit') should map into `LOG_INFO', `LOG_WARNING',, `LOG_ERR', `LOG_INFO', and `LOG_INFO' respecitively. Similarly, the standard SNMP Trap Severities (`Normal', `Warning', `Minor', `Major', and `Critical') should map into `LOG_INFO', `LOG_WARNING', `LOG_ERR', `LOG_ERR', and `LOG_CRIT' respecitively. NOTE: Need references for NT and SNMP log:PROC.NAME 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: Standard hiercharies need to be specified. log:PROC.ID 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'). log:PROC.PRIV A list of any security ID's/groups/labels associated with the process generating the log entry (`USR-chris, UID-748, GRP-adm, GRP-sys, GRP-users, EUID-root, EGID-kmem, DAC_READ, SYSTEM_HIGH') NOTE: Need to specify standard nonclemature for Unix, NT, and IEEE 1003.1e/2c priveleges. Also, do we really want to do it this way, or would it be better done as different attribute types, or even nested elements or something? log:PROC.MAIL An e-mail address associated with the Calabrese Expires July 16, 2001 [Page 4] Internet-Draft XML for Secure System Logs January 2001 usr/login/account the process is running as. log:PROC.TTY 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 (Appendix B)'. XML:LANG The language used for any textual messages in the standard XML `LangCode' format[16]. log:DUR Duration of the event being logged in 'Seconds.Decimel (Appendix B)' format. log:SRC.ADDR (log:DST.ADDR) The network source (destination) address of any network traffic represented by this event in 'log:Address_Format (Appendix B)'. log:SRC.PROT (log:DST.PROT) The network protocols/ports used by the source (destination) of network traffic in 'log:Protocol_Format (Appendix B)' (`IP/TCP/25/ESMTP', `IP/ICMP/Source_Quench'). log:SRC.FQDN (log:DST.FQDN) The fully qualified domain name for the traffic source (destination). log:SRC.NAME (log:DST.NAME) Some other unique identifier for the traffic source (destination). log:SRC.USR (log:DST.USR) A user/login/account associated with the traffic source (destination). log:SRC.MAIL (log.DST.MAIL) An e-mail address associated with the traffic source (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 Similar to the `log:SRC.' and `log:DST.' attributes, but representing inbound and outbound traffic through 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 Calabrese Expires July 16, 2001 [Page 5] Internet-Draft XML for Secure System Logs January 2001 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:CMD="/bin/rm -rf /"> log:MSG Free form message text. Calabrese Expires July 16, 2001 [Page 6] Internet-Draft XML for Secure System Logs January 2001 3. Examples 3.1 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: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: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> As a result, only inner-most `log:EVNT' elements are log entries. Outer `log:EVNT' elements set attributes common to the contained entries. Calabrese Expires July 16, 2001 [Page 7] Internet-Draft XML for Secure System Logs January 2001 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: 1. 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. 2. 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. 3. 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. Calabrese Expires July 16, 2001 [Page 8] Internet-Draft XML for Secure System Logs January 2001 5. Implementation Considerations 5.1 Event Filtering NOTE: Need info about filtering... 5.2 Event Viewing/Reporting NOTE: Need info viewing/reporting... 5.3 Logging API's NOTE: Need info on API's, especially making sure that the TCB generates whatever information it can. Refer to sec section. 5.4 Backward Compatibility 5.4.1 Syslog NOTE: Need info on this..., especially issue of including level/facility info in both XML and native syslog levels. 5.4.2 NT Event Logger NOTE: Need info on this... 5.5 Network Communications NOTE: Need info on this..., including references to Syslog WG work. Calabrese Expires July 16, 2001 [Page 9] Internet-Draft XML for Secure System Logs January 2001 6. Security Considerations 6.1 Correctness and Completeness of Identifying Information NOTE: TCB should/must generate log:HOST log:DATE log:SEV log:PROC.NAME log:PROC.ID log:PROC.PRIV 6.2 Confidentiality, Integrity, and Availability of Log Messages The confidentiality, integrity, and availability of log messages or logging mechanisms is beyond the scope of this memo. However, these issues are addressed in the following places. NOTE: need references here... Calabrese Expires July 16, 2001 [Page 10] Internet-Draft XML for Secure System Logs January 2001 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] International Standards Organization, "Data elements and interchange formats - Information interchange - Representation of dates and times", International Standard ISO 8601:1988, available from http://www.iso.ch/markete/8601.pdf, 1988. [3] University of California Computer Systems Research Group, "Unix Programmer's Manual, 4.3 Berkeley Software Distribution, Virtual VAX-11 Version", April 1986. [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] International Standards Organization, "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] 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. [8] Lonvick, C.M., "syslog Protocol", draft-ietf-syslog-syslog-03 (work in progress), January 2001. [9] Schneier, B. and J. Kelsey, "Cryptographic Support for Secure Logs on Untrusted Machines", The Seventh USENIX Security Symposium Proceedings, USENIX Press pp. 53-62, available from http://www.counterpane.com/secure-logs.html, January 1998. [10] Schneier, B. and J. Kelsey, "Minimizing Bandwidth for Remote Access to Cryptographically Protected Audit Logs", Second Calabrese Expires July 16, 2001 [Page 11] Internet-Draft XML for Secure System Logs January 2001 International Workshop on the Recent Advances inIntrusion Detection (RAID '99), available from http://www.counterpane.com/auditlog2.html, September 1999. [11] Abela, J. and T. Debeaupuis, "Universal Format for Logger Messages", May 1999. [12] Jombart, N., "Private correspondence", May 2000. [13] New, D. and M.T. Rose, "Reliable Delivery for Syslog", draft-ietf-syslog-reliable-02 (work in progress), November 2000. [14] Kelsey, J., "Syslog-Auth Protocol", draft-ietf-syslog-auth-00 (work in progress), December 2000. [15] Kelsey, J., "Syslog-Sign Protocol", draft-ietf-syslog-sign-00 (work in progress), December 2000. [16] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0.", available from http://www.w3.org/TR/REC-xml, February 1998. Author's Address Christopher J. Calabrese The SANS Institute 26 Wellesley Road Upper Montclair, NJ 07043 US Phone: +1 973 233 1464 EMail: [EMAIL PROTECTED] Calabrese Expires July 16, 2001 [Page 12] Internet-Draft XML for Secure System Logs January 2001 Appendix A. XML DTD for the `log:EVNT' Element <!-- Note that attributes are marked REQUIRED -- here if it is implied by draft-calabrese-requir-loggprot-01. -- This assumes this information is not being provided by -- another source. --> <!ELEMENT log:ENTRY (log:ENTRY)*> <!ATTLIST log:ENTRY log:HOST CDATA #REQUIRED log:DATE ISO.8601:1998_Date_Format #REQUIRED log:SEV log:Severity_Type #REQUIRED log:PROC.NAME CDATA #REQUIRED log:PROC.ID CDATA #REQUIRED log:PROC.PRIV CDATA #REQUIRED log:PROC.MAIL CDATA #IMPLIED log:PROC.TTY CDATA #IMPLIED log:EVENT.TYPE log:Event_Type_Enumeration #IMPLIED log:XML:LANG LangCode "EN" log:DUR Seconds.Decimal #IMPLIED log:SRC.ADDR log:Address_Format #IMPLIED log:SRC.PROT log:Protocol_Format #IMPLIED log:SRC.FQDN CDATA #IMPLIED log:SRC.NAME CDATA #IMPLIED log:SRC.USR CDATA #IMPLIED log:SRC.MAIL CDATA #IMPLIED log:DST.ADDR log:Address_Format #IMPLIED log:DST.PROT log:Protocol_Format #IMPLIED log:DST.FQDN CDATA #IMPLIED log:DST.NAME CDATA #IMPLIED log:DST.USR CDATA #IMPLIED log:DST.MAIL CDATA #IMPLIED log:REL.IN.ADDR log:Address_Format #IMPLIED log:REL.IN.PROT log:Protocol_Format #IMPLIED log:REL.IN.FQDN CDATA #IMPLIED log:REL.IN.NAME CDATA #IMPLIED log:REL.IN.USR CDATA #IMPLIED log:REL.IN.MAIL CDATA #IMPLIED log:REL.OUT.ADDR log:Address_Format #IMPLIED log:REL.OUT.PROT log:Protocol_Format #IMPLIED log:REL.OUT.FQDN CDATA #IMPLIED log:REL.OUT.NAME CDATA #IMPLIED log:REL.OUT.USR CDATA #IMPLIED log:REL.OUT.MAIL CDATA #IMPLIED log:VOL Integer #IMPLIED log:VOL.SENT Integer #IMPLIED log:VOL.RCVD Integer #IMPLIED log:CNT Integer #IMPLIED Calabrese Expires July 16, 2001 [Page 13] Internet-Draft XML for Secure System Logs January 2001 log:CNT.SENT Integer #IMPLIED log:CNT.RCVD Integer #IMPLIED log:PROG.FILE CDATA #IMPLIED log:PROG.LINE Integer #IMPLIED log:DOC CDATA #IMPLIED log:CMD CDATA #IMPLIED log:MSG CDATA #IMPLIED > Calabrese Expires July 16, 2001 [Page 14] Internet-Draft XML for Secure System Logs January 2001 Appendix B. XML DTD for Data Types Used in the `log:EVNT' Element <!NOTATION log:Severity_Type ('0'|'1'|...|'99')> <!NOTATION ISO.8601:1998_Date_Format (YYYY '-' MM '-' DD 'T' hh ':' mm [':' ss ['.' f+]]('+' | '-') zzzz)> <!-- NOTE: Need reference and further explanation of date format --> <!NOTATION Seconds.Decimal (ss ['.' f+]) <!NOTATION log:Event_Type_Enumeration ('AUTH.FAIL'|'AUTH.SUCCESS'|'PROG.FAIL'|'PROG.START'|...)> <!-- NOTE: Need more complete enumeration. --> <!NOTATION log:Address_Format (IPv4_Address|IPv6_Address|IPX_Address|...)> <!-- NOTE: Do we need more a complete enumeration? of address types? --> <!NOTATION IPv4_Address CDATA > <!-- NOTE: Need proper definition and reference for IPv4 addresses --> <!NOTATION IPv6_Address CDATA> <!-- NOTE: Need proper definition and reference for IPv6 addresses --> <!NOTATION IPX_Address CDATA> <!-- NOTE: Need proper definition and reference for IPX addresses --> <!NOTATION log:Protocol_Format ( ('IPv4/' ('UDP'|'TCP') '/' IPv4_Port_Number ['/' CDATA]) | ('IPv4/ICMP/' IPv4_ICMP_Message_Type) | ( ('IPv6/' ('UDP'|'TCP') '/' IPv6_Port_Number ['/' CDATA]) | ('IPv6/ICMP/' IP64_ICMP_Message_Type) | ('IPX' ['/SPX/'] IPX_Port_Number ['/' CDATA]) ) <!-- NOTE: Need further definitions of referenced types... --> Calabrese Expires July 16, 2001 [Page 15] Internet-Draft XML for Secure System Logs 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 Expires July 16, 2001 [Page 16]
