Intrusion Detection Working Group D. Curry
draft-curry-idef-xml-00.txt IBM
Expires: April 13, 2000 October 14, 1999
Intrusion Detection Exchange Format
Extensible Markup Language (XML) Implementation
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [1].
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.
Distribution of this memo is unlimited.
This Internet-Draft expires April 13, 2000.
1. Abstract
The purpose of the Intrusion Detection Exchange Format (IDEF) is to
define data formats and exchange procedures for sharing information
of interest to intrusion detection and response systems, and to the
management systems which may need to interact with them. The goals
and requirements of the IDEF are described in [2].
This Internet-Draft describes a proposed implementation of the data
format component of the IDEF, using the Extensible Markup Language
(XML) [3] to represent the class hierarchy defined by Debar and
Huang [4]. The rationale for choosing XML is explained, a Document
Type Definition (DTD) is developed, and examples are provided.
Internet-Draft IDEF XML Implementation October 14, 1999
TABLE OF CONTENTS
1. Abstract ........................................................ 1
2. Conventions used in this document ............................... 5
3. Introduction .................................................... 5
3.1 The Extensible Markup Language ............................. 6
3.2 Rationale for Implementing IDEF in XML ..................... 6
3.3 The Debar/Huang IDEF Class Hierarchy ....................... 7
4. Use of XML in the IDEF .......................................... 8
4.1 The IDEF Document Prolog ................................... 8
4.1.1 XML Declaration ...................................... 8
4.1.2 XML Document Type Definition (DTD) ................... 9
4.1.3 IDEF DTD Formal Public Identifier .................... 9
4.1.4 IDEF DTD Document Type Declaration ................... 10
4.2 Character Data Processing in XML and IDEF .................. 10
4.2.1 Character Entity References .......................... 11
4.2.2 Character Code References ............................ 11
4.2.3 White Space Processing ............................... 11
4.3 Languages in XML and IDEF .................................. 12
4.4 Unrecognized Tags in IDEF Messages ......................... 12
5. IDEF Data Types ................................................. 13
5.1 Simple Data Types .......................................... 13
5.2 Complex Data Types ......................................... 13
5.2.1 STRBUFFER ............................................ 13
5.2.2 FILLER ............................................... 14
5.2.3 USERID ............................................... 14
5.2.4 USERINFO ............................................. 15
5.2.5 ADDRESSID ............................................ 15
5.2.6 FILEID ............................................... 16
5.2.7 HOSTID ............................................... 16
5.2.8 PROCESSID ............................................ 17
5.2.9 SERVICEID ............................................ 17
5.2.10 TIME ................................................ 18
5.2.11 IDSID ............................................... 18
6. IDEF Tags ....................................................... 19
6.1 HEARTBEAT .................................................. 19
6.2 EVENT ...................................................... 20
6.2.1 E_WEIRD .............................................. 21
6.2.2 E_MULTIPLEHOSTS ...................................... 21
6.2.2.1 EM_RANGEID ..................................... 21
6.2.3 E_SINGLEHOST ......................................... 21
6.2.4 E_REFLIST ............................................ 21
6.2.4.1 ES_SPOOFEDORIGIN ............................... 22
6.2.4.1.1 ESS_SINGLESERVICE ........................ 22
6.2.4.1.2 ESS_MULTIPLESERVICES ..................... 22
Curry Expires: April 13, 2000 [Page 2]
Internet-Draft IDEF XML Implementation October 14, 1999
6.2.4.1.2.1 ESSM_SERVICERANGE .................. 22
6.2.4.2 ES_APPLICATION ................................. 22
6.2.4.2.1 ESA_MULTIPLEUSERS ........................ 23
6.2.4.2.2 ESA_USER ................................. 23
6.2.4.2.2.1 ESAU_TARGETUSER .................... 23
6.2.4.2.2.2 ESAU_TARGETFILE .................... 23
6.2.4.3 ES_REALORIGIN .................................. 23
6.2.4.3.1 ESR_TOOL ................................. 24
6.2.4.3.2 ESR_CRASHPACKET .......................... 24
6.2.4.3.3 ESR_ICMP ................................. 24
6.2.4.3.4 ESR_MULTIPLESERVICES ..................... 24
6.2.4.3.4.1 ESRM_SERVICERANGE .................. 24
6.2.4.3.5 ESR_SINGLESERVICE ........................ 25
6.2.4.3.5.1 ESRS_EMAIL ......................... 25
6.2.4.3.5.2 ESRS_USER .......................... 25
6.2.4.3.5.3 ESRS_DNSCMD ........................ 25
6.2.4.3.5.4 ESRS_SNMP .......................... 25
6.2.4.3.5.4.1 ESRSS_ACTIVITY ............... 26
6.2.4.3.5.5 ESRS_PASSDECODE .................... 26
6.2.4.3.5.6 ESRS_CMDDECODE ..................... 26
6.2.4.3.5.6.1 ESRSC_USERINFO ............... 26
6.2.4.3.5.7 ESRS_THIRDHOST ..................... 26
6.2.4.3.5.7.1 ESRST_USERINFO ............... 27
6.2.4.3.5.8 ESRS_FILEACCESS .................... 27
6.2.4.3.5.9 ESRS_RIP ........................... 27
6.2.4.3.5.10 ESRS_DISTANTCNT ................... 27
6.2.4.3.5.11 ESRS_STRINGMATCH .................. 27
6.2.4.3.5.12 ESRS_TROJAN ....................... 28
6.2.4.3.5.13 ESRS_WEBSERVER .................... 28
6.2.4.3.5.13.1 ESRSW_PRIVILEGEDCMD ......... 28
6.2.4.3.5.13.2 ESRSW_INSECURECGI ........... 28
6.3 Tag Hierarchy .............................................. 29
7. Examples ........................................................ 29
7.1 Denial of Service Attacks .................................. 30
7.1.1 The "teardrop" Attack ................................ 30
7.1.2 The "ping of death" Attack ........................... 31
7.2 Port Scanning Attacks ...................................... 32
7.2.1 Connection to a Disallowed Service ................... 32
7.2.2 Simple Port Scanning ................................. 33
7.3 Network Decodes ............................................ 35
7.3.1 Protocol Decode for the "FTP GET" Command ............ 35
7.4 Local Attacks .............................................. 37
7.4.1 The "loadmodule" Attack .............................. 37
7.5 System Policy Abuses ....................................... 39
7.5.1 After-Hours Login .................................... 39
8. Extending the IDEF .............................................. 40
8.1 Adding a New Element ....................................... 41
8.2 Adding a New Attribute ..................................... 41
9. The IDEF Document Type Definition ............................... 43
Curry Expires: April 13, 2000 [Page 3]
Internet-Draft IDEF XML Implementation October 14, 1999
10. Security Considerations ........................................ 53
11. References ..................................................... 54
12. Acknowledgments ................................................ 54
13. Author's Address ............................................... 54
Curry Expires: April 13, 2000 [Page 4]
Internet-Draft IDEF XML Implementation October 14, 1999
2. Conventions used in this document
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 [5].
An "IDEF application" is a program or program component that reads
and/or writes messages in the format specified by this memo.
An "IDEF document" is a message that adheres to the requirements
specified by this memo, and that is exchanged by two or more IDEF
applications. An "IDEF message" is another term for an "IDEF
document."
********************************************************************
** Comments and questions about the draft are shown in asterisked **
** boxes like this one. These will be removed from the final **
** version of this draft. **
********************************************************************
3. Introduction
The Intrusion Detection Exchange Format (IDEF) [2] is intended to be
a standard data format that automated intrusion detection systems can
use to report events that they have deemed suspicious. The
development of this standard format will enable interoperability
among commercial, open source, and research systems, allowing users
to mix-and-match the deployment of these systems according to their
strong and weak points to obtain an optimal implementation.
The most obvious place to implement the IDEF is in the data channel
between an intrusion detection "sensor" or "agent" and the "console"
or "manager" to which it sends alarms. But there are other places
where the IDEF can be useful:
+ a single database system that could store the results from a
variety of intrusion detection products would make it possible for
data analysis and reporting activities to be performed on "the
whole picture" instead of just a part of it;
+ an event correlation system that could accept events from a
variety of intrusion detection products would be capable of
performing more sophisticated cross-correlation and cross-
confirmation calculations than one that is limited to a single
product;
+ a graphical user interface that could display events from a
variety of intrusion detection products would enable the user to
monitor all of the products from a single screen, and require him
or her to learn only one interface, instead of several; and
+ a common data exchange format would make it easier for different
Curry Expires: April 13, 2000 [Page 5]
Internet-Draft IDEF XML Implementation October 14, 1999
organizations (users, vendors, response teams, law enforcement)
to not only exchange data, but also communicate about it.
The diversity of uses for the IDEF needs to be considered when
selecting its method of implementation.
3.1 The Extensible Markup Language
The Extensible Markup Language (XML) [4] is a simplified version of
the Standard Generalized Markup Language (SGML), a text markup syntax
defined by the ISO 8879 standard. XML is gaining widespread
attention as a language for representing and exchanging documents and
data on the Internet, and as the solution to most of the problems
inherent in HyperText Markup Language (HTML). XML was published as a
recommendation by the World Wide Web Consortium (W3C) on February 10,
1998.
XML is a metalanguage -- a language for describing other languages --
that enables an application to define its own markup. XML allows the
definition of customized markup languages for different types of
documents and different applications. This differs from HTML, in
which there is a fixed set of tags with preset meanings that must be
"adapted" for specialized uses. Both XML and HTML use tags
(identifiers delimited by '<' and '>') and attributes (of the form
"name='value'"). But where "<p>" always means "paragraph" in HTML,
it may mean "paragraph," "person," "price," or "platypus" in XML, or
it might have no meaning at all, depending on the particular
application.
The publication of XML was followed by the publication of a second
recommendation [6] by the World Wide Web Consortium, defining the use
of namespaces in XML documents. An XML namespace is a collection of
names, identified by a Universal Resource Identifier (URI). It
allows documents of different types, that use tags with the same
names, to be merged with no confusion. In anticipation of the
widespread use of XML namespaces, this memo includes the definition
of the URI to be used to identify the IDEF namespace.
XML applications that conform to the requirements set forth in this
memo and also make use of namespaces MUST NOT include other non-IDEF
namespaces in an IDEF document.
3.2 Rationale for Implementing IDEF in XML
XML-based applications are being used or developed for a wide variety
of uses, including electronic data interchange in a variety of
fields, financial data interchange, electronic business cards,
calendar and scheduling, enterprise software distribution, web "push"
technology, and markup languages for chemistry, mathematics, music,
molecular dynamics, astronomy, book and periodical publishing, web
Curry Expires: April 13, 2000 [Page 6]
Internet-Draft IDEF XML Implementation October 14, 1999
publishing, weather observations, real estate transactions, and many
others.
XML's flexibility makes it a good choice for these applications; that
same flexibility makes it a good choice for implementing the IDEF as
well. Other, more specific reasons for choosing XML to implement the
IDEF are:
+ XML allows a custom language to be developed specifically for the
purpose of describing intrusion detection events. It also defines
a standard way to extend this language, either for later revisions
of this document ("standard" extensions), or for vendor-specific
use ("non-standard" extensions).
+ Software tools for processing XML documents are widely available,
in both commercial and open source forms. A variety of tools and
APIs for parsing and/or validating XML are available in Java, C,
C++, Tcl, Perl, Python, and GNU Emacs Lisp. Widespread access to
tools will make adoption of the IDEF by product developers easier,
and hopefully, faster.
+ XML meets IDEF Requirement 5.1, that message formats support full
internationalization and localization. The XML standard specifies
support for both the UTF-8 and UTF-16 encodings of ISO 10646
(Unicode), making IDEF compatible with both one- and two-byte
character sets. XML also provides support for specifying, on a
per-element basis, the language in which the element's content is
written, making IDEF easy to adapt to "Natural Language Support"
versions of a product.
+ XML meets IDEF Requirement 5.2, that message formats must support
filtering and aggregation. XML's integration with XSL, a style
language, allows messages to be combined, discarded, and
rearranged.
+ Ongoing XML development projects, in the W3C and elsewhere, will
provide object-oriented extensions, database support, and other
useful features. If implemented in XML, the IDEF immediately
gains these features as well.
+ XML is free, with no license, no license fees, and no royalties.
3.3 The Debar/Huang IDEF Class Hierarchy
Debar and Huang [4] have proposed that intrusion detection events in
the IDEF be represented by a class hierarchy. This representation
has several advantages:
+ it is flexible, and capable of describing events to arbitrary
levels of complexity;
Curry Expires: April 13, 2000 [Page 7]
Internet-Draft IDEF XML Implementation October 14, 1999
+ it is compact, and allows applications to specify only the data
they know; and
+ it is easy to extend, and will allow vendors to provide additional
information about particular events.
This implementation follows the Debar/Huang model almost exactly,
with the following exceptions and restrictions:
+ XML tags have the names given to the various classes in the model,
except in cases where XML scope rules require otherwise.
+ Subclasses are implemented by making the tags for those classes
subtags of the tags for the parent classes.
+ XML does not support "inheritance;" tags may only be used at the
level at which they are declared. This means that all the class
tags from the "root" to the lowest subclass in use must be
specified.
+ XML is a typeless language, but the model's complex data types
have been implemented after a fashion by using parameterized
entity references.
+ The STRBUFFER and FILLER types have not been implemented, as they
are not required in an XML implementation.
+ The TIME type has been implemented differently to provide a more
generically useful format.
These changes make little difference in the overall usefulness of the
Debar/Huang model, or XML as an implementation language.
4. Use of XML in the IDEF
This section describes how some of XML's features and requirements
will impact the IDEF.
4.1 The IDEF Document Prolog
The "prolog" of an IDEF document, that part that precedes anything
else, consists of the XML declaration and the document type
declaration.
4.1.1 XML Declaration
Every XML document (and therefore every IDEF document) starts with an
XML declaration. The XML declaration specifies the version of XML
being used; it may also specify the character set being used.
Curry Expires: April 13, 2000 [Page 8]
Internet-Draft IDEF XML Implementation October 14, 1999
The XML declaration looks like:
<?xml version="1.0" ?>
If a character encoding is specified, the declaration looks like:
<?xml version="1.0" encoding="charset" ?>
where "charset" is the name of the character set in use (see section
4.2). If no encoding is specified, UTF-8 is assumed.
IDEF documents being exchanged between IDEF applications MUST begin
with an XML declaration, and MUST specify the XML version in use.
Specification of the encoding in use is RECOMMENDED.
IDEF applications such as event databases MAY choose to omit the XML
declaration internally to conserve space, adding it only when the
message is sent to another destination. This practice is NOT
RECOMMENDED unless it can be accomplished without loss of each
message's version and encoding information.
4.1.2 XML Document Type Definition (DTD)
The Document Type Definition (DTD) specifies the exact syntax of an
XML document. It defines the various tags that may be used in the
document, how the tags are related to each other, which tags are
mandatory and which are optional, and so forth.
The IDEF Document Type Definition is listed in its entirety in
section 9.
It is expected that IDEF applications will not normally include the
IDEF DTD itself in their communications. Instead, the DTD will be
referenced in the document type declaration in the document entity
(see below). Such IDEF documents will be well-formed and valid as
defined in [3].
Other IDEF documents will be specified that do not include the
document prolog (e.g., entries in an IDEF-format database). Such
IDEF documents will be well-formed but not valid.
IDEF documents MUST be well-formed. IDEF documents SHOULD be valid
whenever both possible and practical.
4.1.3 IDEF DTD Formal Public Identifier
The formal public identifier (FPI) for the Document Type Definition
described in this memo is:
Curry Expires: April 13, 2000 [Page 9]
Internet-Draft IDEF XML Implementation October 14, 1999
"-//IETF//DTD RFCxxxx IDEF v0.1//EN"
NOTE: The "RFCxxxx" text in the FPI value will be replaced
with the actual RFC number, if this memo is published
as an RFC.
This FPI MUST be used in the document type declaration within an XML
document referencing the DTD defined by this memo, as shown in the
following section.
4.1.4 IDEF DTD Document Type Declaration
The document type declaration for an XML document referencing the DTD
defined by this memo will usually be specified in one of the
following ways:
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN">
The last component of the document type declaration is the formal
public identifier (FPI) specified in the previous section.
<!DOCTYPE idef-message SYSTEM "/some/path/to/the/idef-message.dtd">
The last component of the document type declaration is a URL that
points to a copy of the Document Type Definition.
4.2 Character Data Processing in XML and IDEF
The XML standard requires that XML processors support the UTF-8 and
UTF-16 encodings of ISO 10646 (Unicode), making XML compatible with
both one- and two-byte character sets. While many XML processing
applications may support other character sets, only UTF-8 and UTF-16
can be relied upon from a portability viewpoint.
A document's XML declaration (see section 4.1.1) specifies the
character encoding to be used in the document, as follows:
<?xml version="1.0" encoding="charset" ?>
where "charset" is the name of the character set, as registered with
the Internet Assigned Numbers Authority (IANA), see [7].
If no encoding is specified, UTF-8 is assumed.
IDEF applications SHOULD NOT use, and IDEF messages SHOULD NOT be
encoded in, character sets other than UTF-8 and UTF-16. Note that
since ASCII is a subset of UTF-8, it MAY be used to encode IDEF
messages.
Per the XML standard, IDEF documents encoded in UTF-16 MUST begin
Curry Expires: April 13, 2000 [Page 10]
Internet-Draft IDEF XML Implementation October 14, 1999
with the Byte Order Mark described by ISO/IEC 10646 Annex E and
Unicode Appendix B (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF).
4.2.1 Character Entity References
Within XML documents, certain characters have special meanings in
some contexts. To include the actual character itself in one of
these contexts, a special escape sequence, called an entity
reference, must be used.
The characters that sometimes need to be escaped, and their entity
references, are:
Character Entity Reference
---------------------------------
& &
< <
> >
" "
' '
It is RECOMMENDED that IDEF applications use the entity reference
form whenever writing these characters in data, to avoid any
possibility of misinterpretation.
4.2.2 Character Code References
Any character defined by the ISO/IEC 10646 standard may be included
in an XML document by the use of a character reference. A character
reference is started with the characters '&' and '#', and ended with
the character ';'. Between these characters, the character code for
the character inserted.
If the character code is preceded by an 'x' it is interpreted in
hexadecimal (base 16), otherwise, it is interpreted in decimal (base
10). For instance, the ampersand (&) is encoded as & or &
and the less-than sign (<) is encoded as < or <.
Any one- or two-byte character specified in the Unicode standard can
be included in a document using this technique.
4.2.3 White Space Processing
XML preserves white space by default. The XML processor passes all
white space characters to the application unchanged. This is much
different from HTML (and SGML), in which, although the space/no space
distinction is meaningful, the one space/many spaces distinction is
not.
Curry Expires: April 13, 2000 [Page 11]
Internet-Draft IDEF XML Implementation October 14, 1999
XML allows tags to identify the importance of white space in their
content by using the "xml:space" attribute:
<tagname xml:space="action">
where "action" is either "default" or "preserve."
If "action" is "preserve," the application MUST treat all white space
in the tag's content as significant. If "action" is "default," the
application is free to do whatever it normally would with white space
in the tag's content.
The intent declared with the "xml:space" attribute is considered to
apply to all attributes and content of the element where it is
specified, unless overriden with an instance of "xml:space" on
another element within that content.
All IDEF tags support the "xml:space" attribute.
4.3 Languages in XML and IDEF
XML allows tags to identify the language their content is written in
by using the "xml:lang" attribute:
<tagname xml:lang="langcode">
where "langcode" is a language tag as described in RFC 1766 [8].
The intent declared with the "xml:lang" attribute is considered to
apply to all attributes and content of the element where it is
specified, unless overriden with an instance of "xml:lang" on another
element within that content.
IDEF applications SHOULD specify the language in which their contents
are encoded; in general this can be done by specifying the "xml:lang"
attribute for the top-level <idef-message> tag.
All IDEF tags support the "xml:lang" attribute.
4.4 Unrecognized Tags in IDEF Messages
On occasion, an IDEF application may receive a well-formed, or even
well-formed and valid, IDEF message containing unknown tags. The
tags may be either:
+ Recognized as "legitimate," but the application does not know the
semantic meaning of the tag's content; or
+ Not recognized at all.
Curry Expires: April 13, 2000 [Page 12]
Internet-Draft IDEF XML Implementation October 14, 1999
IDEF applications MUST continue to process IDEF messages that contain
unknown tags, provided that such messages meet the well-formedness
requirement of section 4.1.2. It is up to the individual application
to decide how to process any content from the unknown tag(s).
5. IDEF Data Types
The simple and complex data types from the Debar and Huang model have
been defined as XML parameterized entities. Although XML does not
provide true data typing, this practice makes it clear what type of
data is expected in each document element.
5.1 Simple Data Types
The Debar and Huang simple data types are implemented in the IDEF DTD
as follows:
%dt.real; an element of this type contains a 64-bit floating
point number
********************************************************************
** There is an ongoing discussion within the group about whether **
** or not we want real numbers (as opposed to integers). This **
** document uses reals in a few spots now because the Debar/Huang **
** model does, but this can be changed if the group decides that **
** we don't want reals **
********************************************************************
%dt.int16; an element of this type contains a 16-bit unsigned
integer
%dt.int32; an element of this type contains a 32-bit unsigned
integer
%dt.int64; an element of this type contains a 64-bit unsigned
integer
%dt.string; an element of this type contains string data of
arbitrary length; the end of the string will be
indicated by the element's close tag.
5.2 Complex Data Types
The Debar and Huang complex data types are implemented as described
in the following sections.
Curry Expires: April 13, 2000 [Page 13]
Internet-Draft IDEF XML Implementation October 14, 1999
The "strbuffer" type is not implemented in the IDEF DTD.
The "filler" type is not implemented in the IDEF DTD.
The "userid" type indicates the different ways in which a user can be
identified; it is intended to be applicable to all platforms. IDEF
elements of this type may have the following sub-elements:
username the name of the user running the service or
application (string)
userid the identification number of the user running the
service or application (int32)
groupname the name of the group running the service or
application (string)
groupid the identification number of the group running the
service or application (int32)
One of <username> or <userid> MUST be provided; the other
sub-elements are OPTIONAL.
Elements of type "userid" have a "type" attribute that defines the
environment in which the above elements are meaningful. Defined
values for the "type" attribute are:
unix the UNIX operating system (any version)
nt the Microsoft Windows NT operating system
application a particular application
********************************************************************
** Should we list individual application names here instead of a **
** generic value? It might work better, but it means we have to **
** updated the list all the time. Perhaps a second attribute for **
** specifying the application name? **
********************************************************************
email an electronic mail address
other anything else (this is the default value)
********************************************************************
** What should the total list of types be? **
Curry Expires: April 13, 2000 [Page 14]
Internet-Draft IDEF XML Implementation October 14, 1999
********************************************************************
The "userinfo" type is an association between a user source and a
user destination. The "source" user provides information about the
user running on the attack's source host, and the "destination" user
provides information about the user running on the attack's
destination host. IDEF elements of this type may have the following
sub-elements:
usersrc the user associated with the action on the source
host (userid)
passwdsrc the password of the source user (if relevant)
(string)
userdst the user associated with the action on the
destination host (userid)
passwddst the password of the destination user (if relevant)
(string)
One of <usersrc> or <userdst> MUST be provided; the other
sub-elements are OPTIONAL.
The "addressid" type carries address information. The address can be
a network address, hardware address, or application address. IDEF
elements of this type may have the following sub-elements:
address the address information (string)
info additional information about the address (string)
The <address> sub-element MUST be provided; the <info> sub-element is
OPTIONAL.
Elements of type "addressid" have a "type" attribute that defines the
type of address being provided. Defined values for the "type"
attribute are:
ipv4 Internet Protocol version 4
ipv6 Internet Protocol version 6
other anything else (this is the default)
********************************************************************
** What should the list of supported types be? **
Curry Expires: April 13, 2000 [Page 15]
Internet-Draft IDEF XML Implementation October 14, 1999
********************************************************************
The "fileid" type represents a file in the system. It is extended to
any physical or logical device (including network devices) that can
be accessed by the system. IDEF elements of this type may have the
following sub-elements:
filename the name of the file, absent any path information
(string)
pathname the path to the file, absent any file name (string)
inode the file serial number (int64)
device the id of the device containing this file (string)
As per POSIX 1003.1, the <inode> and <device> values together
uniquely identify the file in the system.
********************************************************************
** Is this what we want? And isn't "inode" kind of a UNIX-ish **
** name? Perhaps "filenumber" or something would be better? **
********************************************************************
One of the sub-element pairs [ <filename> and <pathname> ] or [
<inode> and <device> ] MUST be provided. Both pairs MAY be provided.
The "hostid" type provides several different methods for identifying
hosts. Elements of this type may have the following sub-elements:
identity an identifier that does not correspond to one of the
following categories, e.g., an inventory number
(string)
name the fully qualified domain name of the host (string)
location the physical location of the equipment (string)
netaddress the network address of the host (addressid)
hwaddress the hardware address of the host (e.g., a MAC
address) (addressid)
appaddress the address seen at the application level (addressid)
At least one of these sub-elements MUST be provided; more than one
Curry Expires: April 13, 2000 [Page 16]
Internet-Draft IDEF XML Implementation October 14, 1999
MAY be provided.
The "processid" type collects information about the process being
run. IDEF elements of this type may have the following sub-elements:
name the name of the program being run (string)
ident the process identifier (int16)
pathname the path to the program being run (string)
environ the environment (options, environment variables,
etc.) in which the process is running (string)
One of <name>, <ident>, or both MUST be provided; the other
sub-elements are OPTIONAL.
The "serviceid" type identifies a network service request being
carried out over the network. It should be used not only for open
services, but also connections and connection attempts. IDEF
elements of this type may have the following sub-elements:
name the name of the service (string)
dstport the port to which the connection request is addressed
(int16)
srcport the port from which the request originated (int16)
protocol the protocol name (string)
process identification of the process related to the
provision of the service (processid)
user identification of the user running the service
(serviceid)
One of <name>, <dstport>, or both MUST be provided; the other
sub-elements are OPTIONAL.
Elements of type "serviceid" have a "range" attribute that may take
on the values "low," "high," and "none." If the value is "low"
("high") this element is to be understood as specifying the low
(high) end of a range of services; otherwise, it specifies an
individual service. The IDEF application is responsible for ensuring
that both a "low" and a "high" end for a range is provided.
Curry Expires: April 13, 2000 [Page 17]
Internet-Draft IDEF XML Implementation October 14, 1999
********************************************************************
** This is totally different than the Debar and Huang model **
********************************************************************
The "time" type specifies a date and time. Elements of this type may
have the following sub-elements:
yy the four-digit year (int16)
mm the month (1-12) (int16)
dd the day (1-31) (int16)
h the hour (00-23) (int16)
m the minute (00-59) (int16)
s the second (00-59) (int16)
fs fractions of seconds (real)
offset the offset from Coordinated Universal Time (UTC/GMT)
as a positive or negative decimal number of hours
(real)
The <fs> sub-element is OPTIONAL; all other sub-elements are
REQUIRED.
The "idsid" type describes the intrusion detection sensor or agent
that provided the event. This may not be the same as the device that
is transmitting the IDEF message. Elements of this type may have the
following sub-elements:
id some global identification of the sensor, similar to
a serial number (int64)
sensor the sensor identification within the context of the
IDS installation (string)
console the console identification within the context of the
IDS installation (string)
sensorid the sensor identification by the host it is running
on (hostid)
Curry Expires: April 13, 2000 [Page 18]
Internet-Draft IDEF XML Implementation October 14, 1999
consoleid the console identification by the host it is running
on (hostid)
sensorpid process information concerning the sensor (processid)
consolepid process information concerning the console
(processid)
At least one of <id>, <sensor>, <console>, <sensorid>, or <consoleid>
MUST be provided; more than one of these and the other sub-elements
MAY be provided.
6. IDEF Tags
Every IDEF message is contained in an <idef-message> element. The
<idef-message> tag has the following attributes, both of which are
OPTIONAL:
version the version of the IDEF message specification this
message conforms to; messages conforming to the
format described in this memo MUST use "0.1" as the
value for this attribute
extensions indicates whether or not the enclosed message makes
use of extended tags or attributes; the default is
"no"
The <idef-message> element has two sub-elements: <heartbeat> and
<event>; each <idef-message> may contain zero or more of each of
these sub-elements.
6.1 HEARTBEAT
The <heartbeat> element is used to transmit a sensor/agent's status
to a console/manager station. The element has the following
sub-elements:
idsid identifies the sensor sending the heartbeat (idsid)
time time information (see description in 6.2)
hbdata product-specific hearbeat data (string)
All three sub-elements are REQUIRED.
********************************************************************
** Should hbdata be optional? That would allow the use of a more **
** or less empty heartbeat, but even that is better than nothing. **
********************************************************************
Curry Expires: April 13, 2000 [Page 19]
Internet-Draft IDEF XML Implementation October 14, 1999
The <event> element is used to describe an event. The tag has an
"id" attribute that MUST be provided; its value MUST be a unique-
within-the-environment identifier of this particular event.
The <event> tag has the following sub-elements, all of which are
REQUIRED:
priority the processing priority of this event (int16)
severity the severity of this event (real)
idsid identifies the sensor that detected the event (idsid)
time time information (see below)
name the name of the vulnerability (string)
signature the signature that triggered the event (string)
method an indication of the detection method (string)
trust the trust (confidence) of this event (real)
********************************************************************
** <priority>, <severity>, and <trust> need to have hi/lo limits **
** and we need to decide which direction the ranking goes. **
** **
** <method> needs to have defined values, strings or numbers **
********************************************************************
More detailed information about the event MAY be provided using one
sub-element of type <e_weird>, <e_multiplehosts>, <e_singlehost>,
or <e_reflist>.
The <time> element may have the following sub-elements:
alert-time the time on the sensor at which the alert (event) was
created (time)
detect-time the time on the sensor at which the event was
detected (time)
current-time the current time on the sensor; this can be used by
the recipient to compare clocks and normalize event
times (time)
The <alert-time> sub-element MUST be provided; the others are
OPTIONAL.
Curry Expires: April 13, 2000 [Page 20]
Internet-Draft IDEF XML Implementation October 14, 1999
Events that do not fit either of the other two categories are
described by the <e_weird> element.
This element does not have any sub-elements, and any information
provided in the element is assumed to be in a product-specific
format.
6.2.2 E_MULTIPLEHOSTS
The <e_multiplehosts> element is used to describe events that concern
several targets within a single domain. The tag has a "number"
attribute that MUST be provided, indicating the number of hosts
targeted by the event.
More specific information about the targeted hosts MAY be provided
with the <em_rangeid> sub-element.
The <em_rangeid> element is used to describe the multiple targets in
an <e_multiplehosts> type of event. It has the following
sub-elements, both of which are REQUIRED:
dst a destination host (hostid)
src the source host (hostid)
Exactly one <src> sub-element MUST be provided; at least two <dst>
sub-elements MUST be provided.
6.2.3 E_SINGLEHOST
The <e_singlehost> element is used to describe events that target or
affect a single host. It has one sub-element that MUST be provided:
dst the destination host (hostid)
More detailed information about the event MAY be provided with one
sub-element of type <es_spoofedorigin>, <es_application>, or
<es_realorigin>.
The <e_reflist> element is used to refer to other events by their id
strings (the string provided in the "id" attribute of the <event>
tag).
Curry Expires: April 13, 2000 [Page 21]
Internet-Draft IDEF XML Implementation October 14, 1999
It contains one or more occurrences of the <eventid> sub-element;
each <eventid> has a REQUIRED "idref" attribute the speficies the id
of the referenced event. The contents of the <eventid> element can
be anything the application cares to put there (including nothing).
6.2.4.1 ES_SPOOFEDORIGIN
The <es_spoofedorigin> element is used to describe events of type
<e_singlehost> for which it is certain the source address has been
spoofed. It has one sub-element that MUST be provided:
spoofsrc the spoofed source address (hostid)
Additional information about the services affected by this event MAY
be provided with one sub-element of type <ess_multipleservices> or
<ess_singleservice>.
The <ess_singleservice> element is used to describe the service being
attacked from the spoofed address. It has one REQUIRED sub-element:
service description of the targeted service (serviceid)
6.2.4.1.2 ESS_MULTIPLESERVICES
The <ess_multipleservices> element is used to describe multiple
services being attacked from the spoofed address. It has a REQUIRED
"number" attribute that is used to indicate how many services have
been affected.
More information about the affected services MAY be provided with a
sub-element of type <essm_servicerange>.
The <essm_servicerange> element is used to provide information about
a list and/or range of services. It has one REQUIRED sub-element, of
which there MUST be two or more occurrences:
service a description of an affected service (serviceid)
6.2.4.2 ES_APPLICATION
The <es_application> element is used to describe <e_singlehost>
events that are occurring on the local machine; generally this means
the attack is being run locally (although the attacker may not be
Curry Expires: April 13, 2000 [Page 22]
Internet-Draft IDEF XML Implementation October 14, 1999
local). It has one REQUIRED sub-element:
service description of the affected service (serviceid)
Additional information MAY be provided with the <esa_multipleusers>
and <esa_user> sub-elements.
The <esa_multipleusers> element provides a list of users who are
triggering an <es_application> event. It has one REQUIRED
sub-element, of which there MUST be two or more occurrences:
user description of a user triggering the event (userid)
The <esa_user> element provides information about a single user who
is triggering an <es_application> event. It has one REQUIRED
sub-element:
user description of a user triggering the event (userid)
More information MAY be provided through either one of the
<esau_targetuser> and <esau_targetfile> sub-elements.
The <esau_targetuser> element describes the user who is the target of
the attack (as opposed to the user who is triggering it). It has one
REQUIRED sub-element:
targetuser description of the targeted user (userid)
The <esau_targetfile> element describes a file that is the target of
the attack. It has one REQUIRED sub-element:
targetfile description of the targeted file (fileid)
The <es_realorigin> element is used to describe events of type
<e_singleservice> for which the true origin of the event can be
determined. It has one REQUIRED sub-element:
source the source of the event (hostid)
Curry Expires: April 13, 2000 [Page 23]
Internet-Draft IDEF XML Implementation October 14, 1999
More information MAY be provided about the event by using one of the
sub-elements <esr_tool>, <esr_crashpacket>, <esr_icmp>,
<esr_multipleservices>, or <esr_singleservice>.
The <esr_tool> element is used to describe detected activity from
security tools (either scanners or "hacker" tools). It has one
REQUIRED sub-element:
tool the name of the tool (string)
The <esr_crashpacket> element is used to describe attacks based on
the use of pathological network packets. It has one REQUIRED
sub-element:
protocol the name of the affected protocol (string)
The <esr_icmp> element is used to describe attacks based on the
Internet Control Message Protocol. It has two REQUIRED elements:
code the ICMP code (int16)
type the ICMP type (int16)
6.2.4.3.4 ESR_MULTIPLESERVICES
The <esr_multipleservices> element is used to describe multiple
services being attacked. It has a REQUIRED "number" attribute that
is used to indicate how many services have been affected.
More information about the affected services MAY be provided with a
sub-element of type <esrm_servicerange>.
The <esrm_servicerange> element is used to provide information about
a list and/or range of services. It has one REQUIRED sub-element, of
which there MUST be two or more occurrences:
service a description of an affected service (serviceid)
Curry Expires: April 13, 2000 [Page 24]
Internet-Draft IDEF XML Implementation October 14, 1999
The <esr_singleservice> element is used to describe the service being
attacked. It has one REQUIRED sub-element:
service description of the targeted service (serviceid)
More detailed information about how the service is being attacked MAY
be provided with one of the <esrs_email>, <esrs_user>, <esrs_dnscmd>,
<esrs_snmp>, <esrs_passdecode>, <esrs_cmddecode>, <esrs_thirdhost>,
<esrs_fileaccess>, <esrs_rip>, <esrs_distantcnt>, <esrs_trojan>,
<esrs_stringmatch>, or <esrs_webserver> sub-elements.
The <esrs_email> element is used to describe events related to
electronic mail. It has one REQUIRED sub-element:
address the e-mail address involved in the event (addressid)
The <esrs_user> element describes user login (or user remote shell)
events. It has one REQUIRED sub-element:
userinfo information about the source and destination users
(userinfo)
The <esrs_dnscmd> element describes events related to the Domain Name
System. It has one REQUIRED sub-element:
domain the fully qualified domain name (string)
The <esrs_snmp> element describes events related to the Simple
Network Management Protocol. It has two REQUIRED sub-elements:
community the SNMP community string (string)
oid the SNMP object identifier (string)
Additional information MAY be provided by using the <esrss_activity>
sub-element.
Curry Expires: April 13, 2000 [Page 25]
Internet-Draft IDEF XML Implementation October 14, 1999
The <esrss_activity> element allows an IDS to provide the entire SNMP
PDU in addition to the community and object identifier strings. It
has one REQUIRED sub-element:
pdu the protocol data unit (string)
The <esrs_passdecode> element handles reporting passwords, but only
when they cannot be attached to the associated account or user
information. It has one REQUIRED sub-element:
password the password (string)
The <esrs_cmddecode> element describes commands entered by users that
are related to suspicious activity. It has one REQUIRED sub-element:
cmdline the command line associated with the event (string)
Additional information about the command MAY be provided with the
<esrsc_userinfo> sub-element.
The <esrsc_userinfo> element associates a user and password with a
suspicious command. It has two REQUIRED elements:
user the user information (userid)
password the password (string)
********************************************************************
** Should password be optional? I can see lots of cases where it **
** wouldn't be available. Is there any need for it at all? **
********************************************************************
The <esrs_thirdhost> element handles certain types of events that
involve a third host (e.g., as a relay or middleman). It has two
REQUIRED sub-elements:
thost the third host involved with the event (hostid)
tservice the related service information on this third host
Curry Expires: April 13, 2000 [Page 26]
Internet-Draft IDEF XML Implementation October 14, 1999
In addition, user information on the third host MAY be reported via
the <esrst_userinfo> sub-event.
The <esrst_userinfo> element provides information about the user on
the third host. It has two REQUIRED sub-elements:
tuser information about the user (userid)
tpassword the password, if known (string)
********************************************************************
** Should password be optional? I can see lots of cases where it **
** wouldn't be available. Is there any need for it at all? **
********************************************************************
The <esrs_fileaccess> element handles events related to file
accesses. It has two REQUIRED sub-elements:
file the file being accessed (fileid)
user the user accessing the file (userid)
The <esrs_rip> element handles routing-related events. It has two
REQUIRED elements:
route the route (string)
metric the metric (int16)
The <esrs_distantcnt> element describes remote connections between
two machines at the server level, e.g., NetBIOS. It has two
REQUIRED sub-elements:
client the client accessing the service (hostid)
server the server providing the service (hostid)
Curry Expires: April 13, 2000 [Page 27]
Internet-Draft IDEF XML Implementation October 14, 1999
The <esrs_stringmatch> element covers events produced by an IDS
matching a given pattern against an input stream. It has two
REQUIRED sub-elements:
content the part of the stream that matches the pattern
(string)
pattern the matching pattern (string)
The <esrs_trojan> element provides for the detection of Trojan
software programs. It has two REQUIRED sub-elements:
command the command sent to the Trojan, if applicable
(string)
name the name under which the Trojan is known (string)
The <esrs_webserver> element provides information about events
related to the World Wide Web, including all web-related traffic. It
has one REQUIRED element:
url the URL as submitted by the requesting browser, with
any method information (GET, POST) included (string)
Additional information about the event MAY be provided with the
<esrsw_privilegedcmd> or <esrsw_insecurecgi> sub-elements.
The <esrsw_privilegedcmd> element describes attempted and successful
shell or interpreter accesses through the web server. It has one
REQUIRED sub-element:
command the attempted command (string)
The <esrsw_insecurecgi> element describes attempts to exploit well
known vulnerabilities in CGI programs. It has one REQUIRED
sub-element:
cgi the script invoked by the attack
Curry Expires: April 13, 2000 [Page 28]
Internet-Draft IDEF XML Implementation October 14, 1999
6.3 Tag Hierarchy
The figure below shows the relationship between the major tags in the
IDEF DTD.
IDEF-MESSAGE
+--- HEARTBEAT
+--- EVENT
+---- E_WEIRD
+---- E_MULTIPLEHOSTS
| +---- EM_RANGEID
+---- E_SINGLEHOST
| +---- ES_SPOOFEDORIGIN
| | +---- ESS_SINGLESERVICE
| | +---- ESS_MULTIPLESERVICES
| | +---- ESSM_SERVICERANGE
| +---- ES_APPLICATION
| | +---- ESA_MULTIPLEUSERS
| | +---- ESA_USER
| | +---- ESAU_TARGETUSER
| | +---- ESAU_TARGETFILE
| +---- ES_REALORIGIN
| +---- ESR_TOOL
| +---- ESR_CRASHPACKET
| +---- ESR_ICMP
| +---- ESR_MULTIPLESERVICES
| | +---- ESRM_SERVICERANGE
| +---- ESR_SINGLESERVICE
| +---- ESRS_EMAIL
| +---- ESRS_USER
| +---- ESRS_DNSCMD
| +---- ESRS_SNMP
| | +---- ESRSS_ACTIVITY
| +---- ESRS_PASSDECODE
| +---- ESRS_CMDDECODE
| | +---- ESRSC_USERINFO
| +---- ESRS_THIRDHOST
| | +---- ESRST_USERINFO
| +---- ESRS_FILEACCESS
| +---- ESRS_RIP
| +---- ESRS_DISTANTCNT
| +---- ESRS_STRINGMATCH
| +---- ESRS_TROJAN
| +---- ESRS_WEBSERVER
| +---- ESRSW_PRIVILEGEDCMD
| +---- ESRSW_INSECURECGI
+---- E_REFLIST
7. Examples
The examples shown in this section demonstrate how the IDEF is used
Curry Expires: April 13, 2000 [Page 29]
Internet-Draft IDEF XML Implementation October 14, 1999
to encode event data. Because these are the same examples as those
used by Debar and Huang, they also serve to show how the IDEF format
relates to the Debar and Huang class hierarchy.
These examples are for demonstration purposes only. They do not
necessarily represent the only (or even the "best") way to encode a
particular event, and should not be construed as guidelines on how
particular events should be classified.
7.1 Denial of Service Attacks
The following examples show how some common denial of service attacks
could be represented in the IDEF.
7.1.1 The "teardrop" Attack
In the "teardrop" attack, the attacker sends anomalous fragmented
packets to the target host. Because the attack is targeted at the
IP stack itself, there is no need to encode service information.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: Denial-of-service attack (Teardrop) -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="12345">
<priority>1</priority>
<severity>1.0</severity>
<idsid>
<id>123123123</id>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>09</mm><dd>29</dd>
<h>08</h><m>30</m><s>10</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Denial of service/Net/Teardrop</name>
<signature>Teardrop</signature>
<method>knowledge</method>
<trust>1.0</trust>
<e_singlehost>
<dst>
<netaddress type="ipv4">
<address>123.234.231.121</address>
<info>Web server</info>
Curry Expires: April 13, 2000 [Page 30]
Internet-Draft IDEF XML Implementation October 14, 1999
</netaddress>
</dst>
<es_realorigin>
<src>
<netaddress type="ipv4">
<address>222.121.111.112</address>
</netaddress>
</src>
</es_realorigin>
</e_singlehost>
</event>
</idef-message>
7.1.2 The "ping of death" Attack
The "ping of death" attack is accomplished by sending very large
packets to the target system, overflowing its packet reassembly
buffers.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: Denial of service attack (Ping of Death) -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="sensor01.foo.com:34567">
<priority>1</priority>
<severity>1.0</severity>
<idsid>
<sensor>sensor01.foo.com</sensor>
<console>consoloe01.foo.com</console>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>09</mm><dd>29</dd>
<h>08</h><m>30</m><s>10</s>
<offset>-4</offset>
</alert-time>
<detect-time>
<yy>1999</yy><mm>09</mm><dd>29</dd>
<h>08</h><m>29</m><s>53</s>
<offset>-4</offset>
</detect-time>
</time>
<name>Denial of service/Net/Ping of death</name>
<signature>PingOfDeath</signature>
<method>knowledge</method>
<trust>1.0</trust>
<e_singlehost>
Curry Expires: April 13, 2000 [Page 31]
Internet-Draft IDEF XML Implementation October 14, 1999
<dst>
<identity>oasd01s0</identity>
<name>Service workstation</name>
<location>Computer room B005</location>
</dst>
<es_realorigin>
<src>
<netaddress type="ipv4">
<address>222.121.111.112</address>
</netaddress>
</src>
</es_realorigin>
</e_singlehost>
</event>
</idef-message>
7.2 Port Scanning Attacks
The following examples show how some common port scanning attacks
could be represented in the IDEF.
7.2.1 Connection to a Disallowed Service
This type of event is reported when an attacker attempts to connect
to an unavailable or forbidden service on a host.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: Connection to a disallowed service -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="011a3bghq">
<priority>3</priority>
<severity>1.0</severity>
<idsid>
<sensor>mysensor02@myconsole04</sensor>
<console>myconsole04</console>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>04</mm><dd>23</dd>
<h>08</h><m>32</m><s>43</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Policy/forbidden service</name>
<signature>Connection to forbidden service</signature>
Curry Expires: April 13, 2000 [Page 32]
Internet-Draft IDEF XML Implementation October 14, 1999
<method>3</method>
<trust>4.0</trust>
<e_singlehost>
<dst>
<netaddress type="ipv4">
<address>10.10.10.24</address>
</netaddress>
</dst>
<es_realorigin>
<src>
<netaddress type="ipv4">
<address>127.0.0.1</address>
</netaddress>
</src>
<esr_singleservice>
<service>
<name>finger</name>
<dstport>79</dstport>
<srcport>4235</srcport>
</service>
</esr_singleservice>
</es_realorigin>
</e_singlehost>
</event>
</idef-message>
7.2.2 Simple Port Scanning
"Simple" port scanning occurs when one host attempts to connect to a
large number of ports on a target host in a short amount of time.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: Simple port scanning (report number of ports only) -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="3298759876">
<priority>5</priority>
<severity>1.0</severity>
<idsid>
<id>123123123</id>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>04</mm><dd>23</dd>
<h>08</h><m>32</m><s>43</s>
<offset>-4</offset>
</alert-time>
Curry Expires: April 13, 2000 [Page 33]
Internet-Draft IDEF XML Implementation October 14, 1999
</time>
<name>Map/Net/TCP Scan</name>
<signature>Simple portscan</signature>
<method>1</method>
<trust>1.0</trust>
<e_singlehost>
<dst>
<netaddress type="ipv4">
<address>123.234.231.121</address>
</netaddress>
</dst>
<es_realorigin>
<src>
<netaddress type="ipv4">
<address>222.121.111.112</address>
</netaddress>
</src>
<esr_multipleservices number="501">
</esr_multipleservices>
</es_realorigin>
</e_singlehost>
</event>
</idef-message>
If the IDS were able to record and report the ports that had been
accessed, the same event might be reported as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: Simple port scanning (identify ports connected to) -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="3298759876">
<priority>5</priority>
<severity>1.0</severity>
<idsid>
<id>123123123</id>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>04</mm><dd>23</dd>
<h>08</h><m>32</m><s>43</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Map/Net/TCP Scan</name>
<signature>Simple portscan</signature>
<method>1</method>
<trust>1.0</trust>
Curry Expires: April 13, 2000 [Page 34]
Internet-Draft IDEF XML Implementation October 14, 1999
<e_singlehost>
<dst>
<netaddress type="ipv4">
<address>123.234.231.121</address>
</netaddress>
</dst>
<es_realorigin>
<src>
<netaddress type="ipv4">
<address>222.121.111.112</address>
</netaddress>
</src>
<esr_multipleservices number="398">
<esrm_servicerange>
<service>
<name>finger</name>
</service>
<service>
<dstport>53</dstport>
</service>
<service range="low">
<dstport>119</dstport>
</service>
<service range="high">
<dstport>512</dstport>
</service>
<service>
<name>nntp</name>
</service>
<service>
<name>ftp</name>
</service>
</esrm_servicerange>
</esr_multipleservices>
</es_realorigin>
</e_singlehost>
</event>
</idef-message>
7.3 Network Decodes
Network decodes are protocol elements that some IDSs are capable of
monitoring. Rather than representing known attacks, they are usually
used to implement parts of an organization's security policy.
7.3.1 Protocol Decode for the "FTP GET" Command
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: Protocol decode for FTP GET command -->
Curry Expires: April 13, 2000 [Page 35]
Internet-Draft IDEF XML Implementation October 14, 1999
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="9245abc98349def">
<priority>10</priority>
<severity>5.0</severity>
<idsid>
<console>console02</console>
<sensor>sensor05</sensor>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>04</mm><dd>23</dd>
<h>08</h><m>32</m><s>43</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Decode/Net/FTP GET</name>
<signature>Get password file</signature>
<method>3</method>
<trust>1.0</trust>
<e_singlehost>
<dst>
<name>machine003.mydomain.com</name>
<netaddress type="ipv4">
<address>10.10.10.24</address>
</netaddress>
</dst>
<es_realorigin>
<src>
<name>all.attacks.com</name>
<netaddress type="ipv4">
<address>127.0.0.1</address>
</netaddress>
</src>
<esr_singleservice>
<service>
<name>ftp</name>
<dstport>20</dstport>
<srcport>4235</srcport>
</service>
<esrs_cmddecode>
<cmdline>GET /etc/passwd</cmdline>
<esrsc_userinfo>
<user type="unix">
<username>joe</username>
</user>
<password></password>
</esrsc_userinfo>
</esrs_cmddecode>
Curry Expires: April 13, 2000 [Page 36]
Internet-Draft IDEF XML Implementation October 14, 1999
</esr_singleservice>
</es_realorigin>
</e_singlehost>
</event>
</idef-message>
7.4 Local Attacks
The following examples show how some common local host attacks could
be represented in the IDEF.
7.4.1 The "loadmodule" Attack
The "loadmodule" attack involves tricking the "loadmodule" program on
a Sun Microsystems computer to run another program. Since
"loadmodule" is set-user-id "root," the executed program runs with
super-user privileges.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: The Sun loadmodule attack -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="9873653az">
<priority>1</priority>
<severity>1.0</severity>
<idsid>
<id>12345678</id>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>09</mm><dd>29</dd>
<h>08</h><m>45</m><s>10</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Privileges/Bad Parameter/Loadmodule</name>
<signature>loadmodule forking shell</signature>
<method>1</method>
<trust>1.0</trust>
<e_singlehost>
<dst>
<name>machine.domain.com</name>
<netaddress type="ipv4">
<address>123.234.345.456</address>
</netaddress>
</dst>
Curry Expires: April 13, 2000 [Page 37]
Internet-Draft IDEF XML Implementation October 14, 1999
<es_application>
<service>
<name>loadmodule</name>
<process>
<ident>12345</ident>
<pathname>/usr/openwin/bin/loadmodule</pathname>
</process>
</service>
<esa_user>
<user type="unix">
<username>joe</username>
<userid>13243</userid>
</user>
</esa_user>
</es_application>
</e_singlehost>
</event>
</idef-message>
The IDS could also indicate that the target user is the "root" user;
the event might then look like:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: The Sun loadmodule attack with target user -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="9873653az">
<priority>1</priority>
<severity>1.0</severity>
<idsid>
<id>12345678</id>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>09</mm><dd>29</dd>
<h>08</h><m>45</m><s>10</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Privileges/Bad Parameter/Loadmodule</name>
<signature>loadmodule forking shell</signature>
<method>1</method>
<trust>1.0</trust>
<e_singlehost>
<dst>
<name>machine.domain.com</name>
<netaddress type="ipv4">
<address>123.234.345.456</address>
Curry Expires: April 13, 2000 [Page 38]
Internet-Draft IDEF XML Implementation October 14, 1999
</netaddress>
</dst>
<es_application>
<service>
<name>loadmodule</name>
<process>
<ident>12345</ident>
<pathname>/usr/openwin/bin/loadmodule</pathname>
</process>
</service>
<esa_user>
<user type="unix">
<username>joe</username>
<userid>13243</userid>
</user>
<esau_targetuser>
<targetuser type="unix">
<username>root</username>
</targetuser>
</esau_targetuser>
</esa_user>
</es_application>
</e_singlehost>
</event>
</idef-message>
7.5 System Policy Abuses
The following examples show how some common abuses of system policy
could be represented in the IDEF.
7.5.1 After-Hours Login
In this example, logins are restricted to business hours. The event
reports a violation of this policy that occurs when a user logs in a
little after 9:00pm.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: Policy violation - after-hours login -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd">
<idef-message version="0.1">
<event id="fdkhj8748756">
<priority>1</priority>
<severity>1.0</severity>
<idsid>
<console>console02</console>
<sensor>sensor05</sensor>
Curry Expires: April 13, 2000 [Page 39]
Internet-Draft IDEF XML Implementation October 14, 1999
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>04</mm><dd>23</dd>
<h>21</h><m>16</m><s>51</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Policy violation</name>
<signature>After-hours login</signature>
<method>3</method>
<trust>4.0</trust>
<e_singlehost>
<dst>
<name>machine003.mydomain.com</name>
<netaddress type="ipv4">
<address>10.10.10.24</address>
</netaddress>
</dst>
<es_realorigin>
<src>
<netaddress type="ipv4">
<address>127.0.0.1</address>
</netaddress>
</src>
<esr_singleservice>
<service>
<name>login</name>
<dstport>23</dstport>
<srcport>4235</srcport>
</service>
<esrs_user>
<userinfo>
<usersrc type="unix">
<username>joe</username>
</usersrc>
</userinfo>
</esrs_user>
</esr_singleservice>
</es_realorigin>
</e_singlehost>
</event>
</idef-message>
8. Extending the IDEF
XML allows a Document Type Definition to be extended by declaring (or
redeclaring) elements, entities, and attributes in the document type
declaration. The general syntax for this is:
<!DOCTYPE idef-message PUBLIC
Curry Expires: April 13, 2000 [Page 40]
Internet-Draft IDEF XML Implementation October 14, 1999
"-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd"
[
....declarations....
]>
All new elements, attributes, and entities defined in this manner
MUST have names that begin with "x-".
All new elements, attributes, and entities defined in this manner
SHOULD include the name of their creator in their name, for example,
"x-acme-specialtag."
Any redefinitions of existing IDEF tags, attributes, and entities
MUST NOT alter the validity of IDEF documents that are valid under
the DTD defined in this memo. In other words, while redefinition may
be used to add new elements, it SHOULD NOT be used to remove
elements, change the order of elements, or change the number of times
an element may/must appear.
IDEF messages that use extensions MUST set the "extensions" attribute
on the <idef-message> tag to "yes."
8.1 Adding a New Element
The example below shows how to add a new element type. In this case,
a new IDEF message type, "x-acme-error," is added to the existing
<event> and <heartbeat> types.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Example: add an "x-acme-error" message type to idef-message -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd"
[
<!ELEMENT idef-message (event | heartbeat | x-acme-error)* >
<!ELEMENT x-acme-error (#PCDATA) >
]>
<idef-message version="0.1" extensions="yes">
<x-acme-error>Here is an error message</x-acme-error>
</idef-message>
8.2 Adding a New Attribute
The example below shows how to add a new attribute. In this case, a
new attribute, "x-acme-domain," is added to the <user> type.
<?xml version="1.0" encoding="UTF-8"?>
Curry Expires: April 13, 2000 [Page 41]
Internet-Draft IDEF XML Implementation October 14, 1999
<!-- Example: add an "x-acme-domain" attribute to user -->
<!DOCTYPE idef-message PUBLIC "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
"idef-message.dtd"
[
<!ATTLIST user
x-acme-domain CDATA #IMPLIED>
]>
<idef-message version="0.1" extensions="yes">
<event id="9873653az">
<priority>1</priority>
<severity>1.0</severity>
<idsid>
<id>12345678</id>
</idsid>
<time>
<alert-time>
<yy>1999</yy><mm>09</mm><dd>29</dd>
<h>08</h><m>45</m><s>10</s>
<offset>-4</offset>
</alert-time>
</time>
<name>Privileges/Bad Parameter/Loadmodule</name>
<signature>loadmodule forking shell</signature>
<method>1</method>
<trust>1.0</trust>
<e_singlehost>
<dst>
<name>machine.domain.com</name>
<netaddress type="ipv4">
<address>123.234.345.456</address>
</netaddress>
</dst>
<es_application>
<service>
<name>loadmodule</name>
<process>
<ident>12345</ident>
<pathname>/usr/openwin/bin/loadmodule</pathname>
</process>
</service>
<esa_user>
<user type="unix" x-acme-domain="engineering">
<username>joe</username>
<userid>13243</userid>
</user>
</esa_user>
</es_application>
</e_singlehost>
</event>
Curry Expires: April 13, 2000 [Page 42]
Internet-Draft IDEF XML Implementation October 14, 1999
</idef-message>
9. The IDEF Document Type Definition
<?xml version="1.0" encoding="UTF-8"?>
<!-- ****************************************************************
*********************************************************************
**** Intrusion Detection Exchange Format (IDEF) XML DTD
**** Version 0.2, 14-Oct-1999
****
**** This content model is described in "Intrusion Detection Exchange
**** Format Extensible Markup Language (XML) Implementation," David
**** A. Curry, draft-curry-idef-xml-00.txt.
****
**** Typical invocation:
**** <!DOCTYPE idef-message PUBLIC
**** "-//IETF//DTD RFCxxxx IDEF v0.1//EN"
**** "/some/path/idef-message.dtd">
*********************************************************************
***************************************************************** -->
<!-- ================================================================
== Data types used in the Debar/Huang model. XML is typeless, but
== this makes the ultimate processing of the elements' content
== easier to understand.
=============================================================== -->
<!ENTITY % dt.real "(#PCDATA)" > <!-- 64-bit real number -->
<!ENTITY % dt.int16 "(#PCDATA)" > <!-- 16-bit integer -->
<!ENTITY % dt.int32 "(#PCDATA)" > <!-- 32-bit integer -->
<!ENTITY % dt.int64 "(#PCDATA)" > <!-- 64-bit integer -->
<!ENTITY % dt.string "(#PCDATA)" > <!-- character string -->
<!-- User identification information. The "type" attribute indicates
what kind of user it is. -->
<!ENTITY % dt.userid "(
(username | userid | (username, userid)),
(groupname | groupid | (groupname, groupid))?
)">
<!ENTITY % at.userid "
type (unix | nt | application | email | other) 'other'
">
<!-- Information about the user running on the source or destination
host in the attack. -->
<!ENTITY % dt.userinfo "(
(usersrc, passwdsrc?) | (userdst, passwddst?)
)">
<!-- Address information (network addresses, hardware addresses, and
application addresses). The "type" attribute indicates what
Curry Expires: April 13, 2000 [Page 43]
Internet-Draft IDEF XML Implementation October 14, 1999
kind of address it is (and therefore its format). -->
<!ENTITY % dt.addressid "(
address, info?
)">
<!ENTITY % at.addressid "
type (ipv4 | ipv6 | other) 'other'
">
<!-- Identification of files, including physical and logical devices.
The "inode" and "device" elements have their POSIX meanings. -->
<!ENTITY % dt.fileid "(
(filename, pathname) | (inode, device) |
(filename, pathname, inode, device)
)">
<!-- Identification of hosts, by network address, hardware address
(MAC address), physical location, etc. -->
<!ENTITY % dt.hostid "(
(identity | name | location | netaddress | hwaddress |
appaddress)+
)">
<!-- Description of a process, the program it is executing, and the
environment it is running in. -->
<!ENTITY % dt.processid "(
(name | ident | (name, ident)), pathname?, environ?
)">
<!-- Description of a network service and/or connections and
connection attempts to the service. -->
<!ENTITY % dt.serviceid "(
(name | dstport | (name, dstport)), srcport?, protocol?,
process?, user?
)">
<!ENTITY % at.serviceid "
range (low | high | none) 'none'
">
<!-- Date and time information. The "fs" element is a decimal
fraction of seconds, to whatever precision the implementation
supports. The "offset" element indicates the positive/negative
offset in hours (and fractions of hours) of the local timezone
from Coordinated Universal Time (UTC/GMT). -->
<!ENTITY % dt.time "(
yy, mm, dd, h, m, s, fs?, offset
)">
<!-- Identification of the intrusion detection system (or sensor)
that is the source of this message. -->
<!ENTITY % dt.idsid "(
(id | sensor | console | sensorid | consoleid)+, sensorpid?,
consolepid?
Curry Expires: April 13, 2000 [Page 44]
Internet-Draft IDEF XML Implementation October 14, 1999
)">
<!-- elements associated with the userid data type -->
<!ELEMENT groupid %dt.int32; >
<!ELEMENT groupname %dt.string; >
<!ELEMENT userid %dt.int32; >
<!ELEMENT username %dt.string; >
<!-- elements associated with the userinfo data type -->
<!ELEMENT passwdsrc %dt.string; >
<!ELEMENT passwddst %dt.string; >
<!ELEMENT usersrc %dt.userid; >
<!ATTLIST usersrc %at.userid; >
<!ELEMENT userdst %dt.userid; >
<!ATTLIST userdst %at.userid; >
<!-- elements associated with the addressid data type -->
<!ELEMENT address %dt.string; >
<!ELEMENT info %dt.string; >
<!-- elements associated with the fileid data type -->
<!ELEMENT device %dt.string; >
<!ELEMENT filename %dt.string; >
<!ELEMENT inode %dt.int64; >
<!-- elements associated with the hostid data type -->
<!ELEMENT appaddress %dt.addressid; >
<!ATTLIST appaddress %at.addressid; >
<!ELEMENT hwaddress %dt.addressid; >
<!ATTLIST hwaddress %at.addressid; >
<!ELEMENT identity %dt.string; >
<!ELEMENT location %dt.string; >
<!ELEMENT netaddress %dt.addressid; >
<!ATTLIST netaddress %at.addressid; >
<!-- elements associated with the processid data type -->
<!ELEMENT environ %dt.string; >
<!ELEMENT ident %dt.int16; >
<!-- elements associated with the serviceid data type -->
<!ELEMENT dstport %dt.int16; >
<!ELEMENT process %dt.processid; >
<!ELEMENT protocol %dt.string; >
<!ELEMENT srcport %dt.int16; >
<!ELEMENT user %dt.userid; >
<!ATTLIST user %at.userid; >
<!-- elements associated with the time data type -->
<!ELEMENT yy %dt.int16; >
<!ELEMENT mm %dt.int16; >
<!ELEMENT dd %dt.int16; >
<!ELEMENT h %dt.int16; >
Curry Expires: April 13, 2000 [Page 45]
Internet-Draft IDEF XML Implementation October 14, 1999
<!ELEMENT m %dt.int16; >
<!ELEMENT s %dt.int16; >
<!ELEMENT fs %dt.real; >
<!ELEMENT offset %dt.real; >
<!-- elements associated with the idsid data type -->
<!ELEMENT console %dt.string; >
<!ELEMENT consoleid %dt.hostid; >
<!ELEMENT consolepid %dt.processid; >
<!ELEMENT id %dt.int64; >
<!ELEMENT sensor %dt.string; >
<!ELEMENT sensorid %dt.hostid; >
<!ELEMENT sensorpid %dt.processid; >
<!-- elements associated with more than one data type -->
<!ELEMENT name %dt.string; >
<!ELEMENT pathname %dt.string; >
<!-- ****************************************************************
** The top-level tag. An IDEF message is composed of some number
** of events and heartbeats, intermixed with each other.
*************************************************************** -->
<!ELEMENT idef-message (event | heartbeat)* >
<!ATTLIST idef-message
xmlns CDATA #FIXED
"http://www.ietf.org/internet-drafts/draft-curry-idef-xml-00.txt"
xmlns:idef CDATA #FIXED
"http://www.ietf.org/internet-drafts/draft-curry-idef-xml-00.txt"
version CDATA #FIXED "0.1"
extensions (yes | no) "no" >
<!-- ****************************************************************
** The second-level tags, which define the types of messages
** carried in an idef-message (heartbeats and events). The "id"
** attribute must be unique across the intrusion detection
** environment.
*************************************************************** -->
<!ELEMENT event (
priority, severity, idsid, time, name, signature, method, trust,
(e_weird | e_multiplehosts | e_singlehost | e_reflist)?
)>
<!ATTLIST event
id CDATA #REQUIRED >
<!ELEMENT heartbeat (
idsid, time, hbdata
)>
<!ELEMENT idsid %dt.idsid; >
<!ELEMENT method %dt.string; >
<!ELEMENT priority %dt.int16; >
<!ELEMENT severity %dt.real; >
Curry Expires: April 13, 2000 [Page 46]
Internet-Draft IDEF XML Implementation October 14, 1999
<!ELEMENT signature %dt.string; >
<!ELEMENT trust %dt.real; >
<!ELEMENT time (alert-time, detect-time?, current-time?) >
<!ELEMENT alert-time %dt.time; >
<!ELEMENT current-time %dt.time; >
<!ELEMENT detect-time %dt.time; >
<!ELEMENT hbdata (#PCDATA) >
<!-- ****************************************************************
** The three subclasses of EVENT:
** E_WEIRD, E_MULTIPLEHOSTS, E_SINGLEHOST
** E_REFLIST is also here, but it's not really a class.
*************************************************************** -->
<!-- Events that don't fit into one of the other categories; we allow
free-form text in this element (for lack of anything else). -->
<!ELEMENT e_weird (#PCDATA) >
<!-- Events that are directed against multiple target hosts in a
single domain. -->
<!ELEMENT e_multiplehosts (em_rangeid?) >
<!ATTLIST e_multiplehosts
number CDATA #REQUIRED >
<!-- A range is two or more destinations, followed by a source. -->
<!ELEMENT em_rangeid (dst, dst+, src) >
<!ELEMENT dst %dt.hostid; >
<!ELEMENT src %dt.hostid; >
<!-- Events that are directed at a single target host; most events
will probably fall into this class. -->
<!ELEMENT e_singlehost (
dst, (es_spoofedorigin | es_application | es_realorigin)?
)>
<!-- Allow other events to be referenced by their "id" attributes,
e.g., a correlation engine could refer to the base events from
which it "generated" this one. -->
<!ELEMENT e_reflist (eventid+) >
<!-- The important part of the "eventid" element is the "idref," but
the application can also put text in there, perhaps to describe
what is being referenced. -->
<!ELEMENT eventid (#PCDATA) >
<!ATTLIST eventid
idref CDATA #REQUIRED >
<!-- ****************************************************************
** The three sub-classes of E_SINGLEHOST:
** ES_SPOOFEDORIGIN, ES_APPLICATION, ES_REALORIGIN
*************************************************************** -->
Curry Expires: April 13, 2000 [Page 47]
Internet-Draft IDEF XML Implementation October 14, 1999
<!-- Single or multiple services that have been attacked from a
spoofed network address. -->
<!ELEMENT es_spoofedorigin (
spoofsrc, (ess_multipleservices | ess_singleservice)?
)>
<!ELEMENT spoofsrc %dt.hostid; >
<!-- The "number" attribute indicates how many services were
accessed; they may or may not be listed. -->
<!ELEMENT ess_multipleservices (essm_servicerange?) >
<!ATTLIST ess_multipleservices
number CDATA #REQUIRED >
<!ELEMENT essm_servicerange (service, service+) >
<!ELEMENT ess_singleservice (service) >
<!ELEMENT service %dt.serviceid; >
<!ATTLIST service %at.serviceid; >
<!-- Events occuring on the local host (as opposed to from a remote
host). -->
<!ELEMENT es_application (
service, (esa_multipleusers | esa_user)?
)>
<!ELEMENT esa_multipleusers (user, user+) >
<!-- This gives the local user, but may also give a target user
(e.g., the user whose privileges were under attack) or a target
file. -->
<!ELEMENT esa_user (
user, (esau_targetuser | easu_targetfile)?
)>
<!ELEMENT esau_targetuser (targetuser) >
<!ELEMENT easu_targetfile (targetfile) >
<!ELEMENT targetuser %dt.userid; >
<!ATTLIST targetuser %at.userid; >
<!ELEMENT targetfile %dt.fileid; >
<!-- Events coming from an identifiable source (or a spoofed one for
which the spoofing goes undetected. -->
<!ELEMENT es_realorigin (
src, (esr_tool | esr_crashpacket | esr_icmp |
esr_multipleservices | esr_singleservice)?
)>
<!-- Attacks from a particular hacker tool. -->
<!ELEMENT esr_tool (tool) >
<!ELEMENT tool %dt.string; >
Curry Expires: April 13, 2000 [Page 48]
Internet-Draft IDEF XML Implementation October 14, 1999
<!-- Pathological packets (bad offsets, weird options, etc.). -->
<!ELEMENT esr_crashpacket (protocol) >
<!-- Attacks related to the ICMP protocol. -->
<!ELEMENT esr_icmp (code, type) >
<!ELEMENT code %dt.int16; >
<!ELEMENT type %dt.int16; >
<!-- The "number" attribute indicates how many services were
accessed; these may or may not be listed. -->
<!ELEMENT esr_multipleservices (esrm_servicerange?) >
<!ATTLIST esr_multipleservices
number CDATA #REQUIRED >
<!ELEMENT esrm_servicerange (service, service+) >
<!ELEMENT esr_singleservice (
service, (esrs_email | esrs_user | esrs_dnscmd | esrs_snmp |
esrs_passdecode | esrs_cmddecode | esrs_thirdhost |
esrs_fileaccess | esrs_rip | esrs_distantcnt | esrs_trojan |
esrs_stringmatch | esrs_webserver)?
)>
<!-- ****************************************************************
** The 13 sub-classes of ESR_SINGLESERVICE:
** ESRS_EMAIL, ESRS_USER, ESRS_DNSCMD, ESRS_SNMP,
** ESRS_PASSDECODE, ESRS_CMDDECODE, ESRS_THIRDADDRESS,
** ESRS_FILEACCESS, ESRS_RIP, ESRS_DISTANTCNT, ESRS_TROJAN,
** ESRS_STRINGMATCH, ESRS_WEBSERVER
*************************************************************** -->
<!-- Events related to the electronic mail subsystem. -->
<!ELEMENT esrs_email (addr) >
<!ELEMENT addr %dt.addressid; >
<!ATTLIST addr %at.addressid; >
<!-- User-related events such as logins. -->
<!ELEMENT esrs_user (userinfo) >
<!ELEMENT userinfo %dt.userinfo; >
<!-- Events related to the domain name system. -->
<!ELEMENT esrs_dnscmd (domain) >
<!ELEMENT domain %dt.string; >
<!-- Events related to the Simple Network Management Protocol. -->
<!ELEMENT esrs_snmp (community, oid, esrss_activity?) >
<!ELEMENT community %dt.string; >
<!ELEMENT oid %dt.string; >
<!ELEMENT esrss_activity (pdu) >
<!ELEMENT pdu %dt.string; >
<!-- For reporting passwords that cannot otherwise be associated
with the associated user/account information. -->
Curry Expires: April 13, 2000 [Page 49]
Internet-Draft IDEF XML Implementation October 14, 1999
<!ELEMENT esrs_passdecode (password) >
<!ELEMENT password %dt.string; >
<!-- Commands entered by users that may be suspicious. -->
<!ELEMENT esrs_cmddecode (cmdline, esrsc_userinfo?) >
<!ELEMENT cmdline %dt.string; >
<!ELEMENT esrsc_userinfo (user, password) >
<!-- Attacks that involve a third host, e.g., "FTP Bounce." -->
<!ELEMENT esrs_thirdhost (thost, tservice, esrst_userinfo?) >
<!ELEMENT thost %dt.hostid; >
<!ELEMENT tservice %dt.serviceid; >
<!ATTLIST tservice %at.serviceid; >
<!ELEMENT esrst_userinfo (tuser, tpassword) >
<!ELEMENT tuser %dt.userinfo; >
<!ELEMENT tpassword %dt.string; >
<!-- Events related to file access attempts. -->
<!ELEMENT esrs_fileaccess (file, user) >
<!ELEMENT file %dt.fileid; >
<!-- Events related to the routing subsystem. -->
<!ELEMENT esrs_rip (route, metric) >
<!ELEMENT route %dt.string; >
<!ELEMENT metric %dt.int16; >
<!-- Remote connections between two hosts at the server level, e.g.,
NetBIOS. -->
<!ELEMENT esrs_distantcnt (client, server) >
<!ELEMENT client %dt.hostid; >
<!ELEMENT server %dt.hostid; >
<!-- Events produced by pattern matching against a data stream. -->
<!ELEMENT esrs_stringmatch (content, pattern) >
<!ELEMENT content %dt.string; >
<!ELEMENT pattern %dt.string; >
<!-- Events associated with Trojan programs such as Back Orifice and
NetBus. -->
<!ELEMENT esrs_trojan (command, name) >
<!ELEMENT command %dt.string; >
<!-- Events related to the web server subsystem. -->
<!ELEMENT esrs_webserver (
url, (esrsw_insecurecgi | esrsw_privilegedcmd)?
)>
<!ELEMENT url %dt.string; >
<!ELEMENT esrsw_insecurecgi (cgi) >
<!ELEMENT cgi %dt.string; >
Curry Expires: April 13, 2000 [Page 50]
Internet-Draft IDEF XML Implementation October 14, 1999
<!ELEMENT esrsw_privilegedcmd (command) >
<!-- ================================================================
== Put the "standard" attributes on all the tags.
=============================================================== -->
<!ENTITY % at.std "
xml:space (default | preserve) 'default'
xml:lang NMTOKEN #IMPLIED
">
<!ATTLIST addr %at.std; >
<!ATTLIST address %at.std; >
<!ATTLIST alert-time %at.std; >
<!ATTLIST appaddress %at.std; >
<!ATTLIST cgi %at.std; >
<!ATTLIST client %at.std; >
<!ATTLIST cmdline %at.std; >
<!ATTLIST code %at.std; >
<!ATTLIST command %at.std; >
<!ATTLIST community %at.std; >
<!ATTLIST console %at.std; >
<!ATTLIST consoleid %at.std; >
<!ATTLIST consolepid %at.std; >
<!ATTLIST content %at.std; >
<!ATTLIST current-time %at.std; >
<!ATTLIST dd %at.std; >
<!ATTLIST detect-time %at.std; >
<!ATTLIST device %at.std; >
<!ATTLIST domain %at.std; >
<!ATTLIST dst %at.std; >
<!ATTLIST dstport %at.std; >
<!ATTLIST e_multiplehosts %at.std; >
<!ATTLIST e_reflist %at.std; >
<!ATTLIST e_singlehost %at.std; >
<!ATTLIST e_weird %at.std; >
<!ATTLIST easu_targetfile %at.std; >
<!ATTLIST em_rangeid %at.std; >
<!ATTLIST environ %at.std; >
<!ATTLIST es_application %at.std; >
<!ATTLIST es_realorigin %at.std; >
<!ATTLIST es_spoofedorigin %at.std; >
<!ATTLIST esa_multipleusers %at.std; >
<!ATTLIST esa_user %at.std; >
<!ATTLIST esau_targetuser %at.std; >
<!ATTLIST esr_crashpacket %at.std; >
<!ATTLIST esr_icmp %at.std; >
<!ATTLIST esr_multipleservices %at.std; >
<!ATTLIST esr_singleservice %at.std; >
<!ATTLIST esr_tool %at.std; >
<!ATTLIST esrm_servicerange %at.std; >
<!ATTLIST esrs_cmddecode %at.std; >
Curry Expires: April 13, 2000 [Page 51]
Internet-Draft IDEF XML Implementation October 14, 1999
<!ATTLIST esrs_distantcnt %at.std; >
<!ATTLIST esrs_dnscmd %at.std; >
<!ATTLIST esrs_email %at.std; >
<!ATTLIST esrs_fileaccess %at.std; >
<!ATTLIST esrs_passdecode %at.std; >
<!ATTLIST esrs_rip %at.std; >
<!ATTLIST esrs_snmp %at.std; >
<!ATTLIST esrs_stringmatch %at.std; >
<!ATTLIST esrs_thirdhost %at.std; >
<!ATTLIST esrs_trojan %at.std; >
<!ATTLIST esrs_user %at.std; >
<!ATTLIST esrs_webserver %at.std; >
<!ATTLIST esrsc_userinfo %at.std; >
<!ATTLIST esrss_activity %at.std; >
<!ATTLIST esrst_userinfo %at.std; >
<!ATTLIST esrsw_insecurecgi %at.std; >
<!ATTLIST esrsw_privilegedcmd %at.std; >
<!ATTLIST ess_multipleservices %at.std; >
<!ATTLIST ess_singleservice %at.std; >
<!ATTLIST essm_servicerange %at.std; >
<!ATTLIST event %at.std; >
<!ATTLIST eventid %at.std; >
<!ATTLIST file %at.std; >
<!ATTLIST filename %at.std; >
<!ATTLIST fs %at.std; >
<!ATTLIST groupid %at.std; >
<!ATTLIST groupname %at.std; >
<!ATTLIST h %at.std; >
<!ATTLIST hbdata %at.std; >
<!ATTLIST heartbeat %at.std; >
<!ATTLIST hwaddress %at.std; >
<!ATTLIST id %at.std; >
<!ATTLIST idef-message %at.std; >
<!ATTLIST ident %at.std; >
<!ATTLIST identity %at.std; >
<!ATTLIST idsid %at.std; >
<!ATTLIST info %at.std; >
<!ATTLIST inode %at.std; >
<!ATTLIST location %at.std; >
<!ATTLIST m %at.std; >
<!ATTLIST method %at.std; >
<!ATTLIST metric %at.std; >
<!ATTLIST mm %at.std; >
<!ATTLIST name %at.std; >
<!ATTLIST netaddress %at.std; >
<!ATTLIST offset %at.std; >
<!ATTLIST oid %at.std; >
<!ATTLIST passwddst %at.std; >
<!ATTLIST passwdsrc %at.std; >
<!ATTLIST password %at.std; >
<!ATTLIST pathname %at.std; >
<!ATTLIST pattern %at.std; >
Curry Expires: April 13, 2000 [Page 52]
Internet-Draft IDEF XML Implementation October 14, 1999
<!ATTLIST pdu %at.std; >
<!ATTLIST priority %at.std; >
<!ATTLIST process %at.std; >
<!ATTLIST protocol %at.std; >
<!ATTLIST route %at.std; >
<!ATTLIST s %at.std; >
<!ATTLIST sensor %at.std; >
<!ATTLIST sensorid %at.std; >
<!ATTLIST sensorpid %at.std; >
<!ATTLIST server %at.std; >
<!ATTLIST service %at.std; >
<!ATTLIST severity %at.std; >
<!ATTLIST signature %at.std; >
<!ATTLIST spoofsrc %at.std; >
<!ATTLIST src %at.std; >
<!ATTLIST srcport %at.std; >
<!ATTLIST targetfile %at.std; >
<!ATTLIST targetuser %at.std; >
<!ATTLIST thost %at.std; >
<!ATTLIST time %at.std; >
<!ATTLIST tool %at.std; >
<!ATTLIST tpassword %at.std; >
<!ATTLIST trust %at.std; >
<!ATTLIST tservice %at.std; >
<!ATTLIST tuser %at.std; >
<!ATTLIST type %at.std; >
<!ATTLIST url %at.std; >
<!ATTLIST user %at.std; >
<!ATTLIST userdst %at.std; >
<!ATTLIST userid %at.std; >
<!ATTLIST userinfo %at.std; >
<!ATTLIST username %at.std; >
<!ATTLIST usersrc %at.std; >
<!ATTLIST yy %at.std; >
<!-- ************************************************************ -->
<!-- ************************************************************ -->
<!-- **** END OF DTD **** -->
<!-- ************************************************************ -->
<!-- ************************************************************ -->
10. Security Considerations
This Internet-Draft describes a data format for the exchange of
security-related data between security product implementations.
There are no security considerations directly applicable to the
format of this data. There may, however, be security considerations
associated with the transport protocol chosen to move this data
between communicating entities.
Curry Expires: April 13, 2000 [Page 53]
Internet-Draft IDEF XML Implementation October 14, 1999
11. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3," BCP
9, RFC 2026, October 1996.
[2] Wood, M., "Intrusion Detection Message Exchange Requirements,"
draft-ietf-idwg-requirements-01.txt, September 17, 1999,
work in progress.
[3] World Wide Web Consortium (W3C), "Extensible Markup Language
(XML)," W3C Recommendation, February, 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
[4] Debar, H. and Ming-Yuh Huang, "Intrusion Detection Exchange
Format Data Model," draft-ietf-idwg-data-model-00.ps, August 23,
1999, work in progress.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14, RFC 2119, March 1997.
[6] World Wide Web Consortium (W3C), "Namespaces in XML," W3C
Recommendation, January, 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114.
[7] Freed, N., "IANA Charset Registration Procedures," BCP 19, RFC
2278, January, 1998.
[8] Alvestrand, H., "Tags for the Identification of Languages," RFC
1766, March, 1995.
12. Acknowledgments
The following individuals deserve all the credit for the actual data
model described here; this document simply proposes an XML-based
implementation of their work.
Herve Debar, IBM Corporation
Ming-Yuh Huang, The Boeing Company
Dominique Alessandri, IBM Corporation
Marc Dacier, IBM Corporation
James Riordan, IBM Corporation
Stephane Schitter, IBM Corporation
Michael Steiner, University of Saarland
Andreas Wespi, IBM Corporation
S. Felix Wu, North Carolina State University
13. Author's Address
David A. Curry
IBM Emergency Response Service
Curry Expires: April 13, 2000 [Page 54]
Internet-Draft IDEF XML Implementation October 14, 1999
300 Long Meadow Road
Mail Stop 230
Sterling Forest, NY 10979
Phone: +1 914 759-4452
Email: davy@ers.ibm.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 DISCLAIM 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
MERCHANITIBILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Curry Expires: April 13, 2000 [Page 55]