As one of the people who have been pushing storage
security since the beginning, let me address this...
When the mailing list first started, there were two factions.
The first was biased toward solving the "entire" problem
of system logging, including cradle-to-grave confidentiality
and integrity. As such, the group pondered many different
avenues, the most fully-cooked of which was an XML-based
log format that built on the UML work and used digital
signatures to provide integrity and key distro for
confidentiality (see attachments xml-log.{html|txt}).
The second wanted to bring reasonably secure logging
functionality to low-end embedded devices (i.e., sub $500
switches and hubs) and thought the public-key crypto of the first
group was too much overhead.
Eventually, the IETF agreed to form a working group to support
some of this work, but told us not to work on the end-to-end
roblem as it was also being worked on by the Intrusion Detection
Working Group (IDWG). Additionally they said that they were
only interested in the protocol and security aspects and that any
message-formatting issues beyond these aspects were a
secondary affair.
As a result, work on the end-to-end problem was suspended
and work on simple authentication for embedded devices
moved forward.
Now, however, it has become clear that the work coming out of
the IDWG will not address the concerns of generalized
end-to-end secure logging. And therefore there is renewed
interest in addressing that issue within that group.
The fundamental question is... Is it really true that embedded
devices don't have enough horsepower to do public-key crypto
at the speeds required? This is a non-trivial question because
first we have to answer the question of what speed really is
required (i.e., how often secure messages really have to be
sent anyway).
If they can do it, then I believe we should concentrate only on
end-to-end solutions. I also believe that shared secret solutions
are a fundamentally wrong approach to this problem.
If they can't, we'll need end-to-end solutions for systems that do
have the horsepower and an "on-ramp" solution to getting
messages from systems that don't.
Personally I'd be surprised if there really are any devices being
planned for manufacture within the timeframe of when this stuff
will become real (say a year from now) that couldn't handle the
computations. After all, you can get a $150 LinkSys router that
can do several mb/s of IPsec these days, and the IKE bits of that
are pretty similar to the stuff we're talking about. Yes, I know
IKE
key negotiation is only a small fraction of the overall traffic, but
so is logging.
Either way we need to develop the end-to-end solution.
That doesn't necessarily mean that the solution has to address
internal formatting of messages (as my original proposal did).
Another approach would be to specify a framework that provides
the security bits to protect free-form messages, but also allows
extensions to do more formatted stuff later. Essentially this would
be something like my proposal with some of the formatting stuff
stripped out. Some of the formatting bits could actually stay
because the system knows how to fill the answers in without help
from the logging application (timestamps, for example). The other
bits that were stripped out could be specified in a seperate
extension document published in another forum (W3C, POSIX,
and X/Open come to mind).
Another approach would be to beef up the current Syslog-Reliable
to do confidentiality and integrity.
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
