Actually, I don't like any of these schemes. The problem is that they
make it impossible to put authenticity codes (i.e., signed hashes) into
the data because you're changing the thing being signed each time
you add a new hop. Instead, I believe the best approach is
something more like this:
<received host=server.dev.example.com time=2000-10-23T120605>
<received host=firewall.dev.example.com time=2000-10-23T120606>
<received host=relay1.example.com time=2000-10-23T120607>
<entry ...>...</entry MAC=4j3kj4kl32>
</received MAC=439232j4kj349324>
</received MAC=43kl3j432j4k>
</received MAC=43j2k4j23k4j>
Why would you want to do this? Because something like IP-sec or
TLS only guarantees hop-wise on-the-wire confidentiality and
maybe authentication. It doesn't help if you want to go back to the
on-disk data store later and show chain of custody. Even better
is if you also use encryption so that you can have confidentiality
of the on-disk data. Selective handing out of the crypto keys
(possibly only to trusted programs) gets you full ability to
control who sees what when.
BTW, this is all hashed out (no pun intended) in the doc I was
working on that extended UML with an XML schema.
If anyone's interested in reviving this effort, I'd be happy
to work with them as a co-author.
Darren New wrote:
> As Balazs Scheidler has pointed out, it can be useful in complex
> configurations to know the path over which syslog messages have
> traveled. I think this would be a valuable addition to the COOKED
> profile, but I'd like to bounce a few ideas off to see what
> people think.
>
> One possibility is to have something like
> <entry deviceFQDN="..." facility="..." ...
> path="relay1.example.com firewall.dev.example.com server.dev.example.com">
> Problem with server!</entry>
>
> This has the obvious problem that the attribute could get
> really, really long. It also necessitates parsing the entire
> entry to figure out how to change it properly. It's also hard
> to extend later.
>
> Another possibility is to have
> <entry ...>
> <received .../>
> <received .../>
> Replacement found
> </entry>
>
> This is going to be prone to problems like
> <entry ...>
> <received .../>
> Replacement
> <received .../>
> in nostril
> <received .../>
> </entry>
> because I don't think there's any way to avoid that in XML.
>
> Another possibility is
> <entry ...>
> <received ... />
> <received ... />
> <received ... />
> <message> Replacement found in nostril </message>
> </entry>
> which has the problem that in the simpler cases, <message> is
> just plain overhead.
>
> The choice I like best so far is
> <trace>
> <received .../>
> <received .../>
> <entry ...> replacement found </entry>
> </trace>
>
> That is, adding a top-level <trace> element, with <received> in
> reverse order (first <received> is most recent), one for each
> relay through which the entry passed. This gives obvious places
> where the protocol can be extended, eliminates the need to do
> a lot of sophisticated XML parsing on each hop (if you trust
> the implementation on the other end), and provides a simple
> separation between important content and operational/debugging
> content.
>
> I'll be adding this last option into the spec, but I'd like
> comments on the general approach.
>
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
> The tragedy of the commons applies to monitizing eyeballs, too.
Title: XML for Secure System Logs
Security Working Group C. Calabrese
INTERNET DRAFT June 2000
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 (2000). All Rights
Reserved.
Table of Contents
1 Overview ???
2 Specification ???
3 Examples ???
4 Deviation from Pure XML ???
5 Implementation Considerations ???
6 Discussion ???
7 Security Considerations ???
8 References ???
9 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[1].
INTERNET DRAFT XML for Secure System Logs June 2000
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) [2].
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[3].
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:
INTERNET DRAFT XML for Secure System Logs June 2000
o 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.
o 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.
o The user/login/account the process is
running as ("chris", "id748").
o An e-mail address associated with the
usr/login/account the process is running
as.
o The group(s) the process belongs to
("bin,mail").
o 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.
o 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[1].
log:DUR
Duration of the event being logged in
seconds.
INTERNET DRAFT XML for Secure System Logs June 2000
log:SRC.ADDR,
log:SRC.PORT,
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
o The network source address in
log:Address_Format.
o The network protocols/ports used in
log:Protocol_Format ("IP/TCP/25/ESMTP",
"IP/ICMP/Source_Quench").
o The fully qualified domain name for the
source host.
o Some other unique identifier for the
source host.
o The source user/login/account.
o An e-mail address associated with the
traffic source.
log:DST.ADDR,
log:DST.PORT,
log:DST.FQDN,
log:DST.NAME,
log:DST.USR,
log:DST.MAIL
Attributes representing the traffic
destination.
log:REL.IN.ADDR,
log:REL.IN.PORT,
log:REL.IN.FQDN,
log:REL.IN.NAME,
log:REL.IN.USR,
log:REL.IN.MAIL,
log:REL.OUT.ADDR,
log:REL.OUT.PORT,
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.
INTERNET DRAFT XML for Secure System Logs June 2000
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
INTERNET DRAFT XML for Secure System Logs June 2000
assumed they will be provided the forthcoming
standard for XML digital standards[3].
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:
INTERNET DRAFT XML for Secure System Logs June 2000
<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.
INTERNET DRAFT XML for Secure System Logs June 2000
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.
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
INTERNET DRAFT XML for Secure System Logs June 2000
5.3 Event Viewing/Reporting
5.4 Logging API's
5.5 Backward Compatibility
5.5.1 Syslog
5.5.2 NT Event Logger
6. Discussion
7. Security Considerations
7.1 Privacy of Log Messages
7.2 Authenticity of Log Messages
7.3 Non-Repudiation of Log Messages
7.4 Immutability of Log Messages Without Detection
7.5 Denial of Service Attacks Against Log Servers
8. References
[1] World Wide Web Consortium, "Extensible Markup
Language (XML) 1.0." February 1998. Available
from www.w3.org/TR/REC-xml.
[2] J. Abela and T. Debeaupis, "Universal Format for
Logger Messages." The Internet Society, May
1999. Available from ftp.ietf.org/internet-
drafts/draft-abela-ulm-05.txt.
[3] World Wide Web Consortium, "Digital Signature
Initiative Activity Statement." October 1999.
Available from
www.w3.org/Signature/Activity.html.
9. Author's Address
C. Calabrese
26 Wellesley Road
Montclair, NJ, USA 07043
Phone: (201) 703-7218
EMail: [EMAIL PROTECTED]
begin:vcard n:Calabrese;Chris tel;work:201-703-7218 x-mozilla-html:TRUE org:Merck-Medco Managed Care, L.L.C.;Internet Infrastructure and Security adr:;;1900 Pollitt Drive;Fair Lawn;NJ;07410;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Internet Security Administrator fn:Chris Calabrese end:vcard
