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 "
" 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:
If a character encoding is specified, the declaration looks like:
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:
The last component of the document type declaration is the formal
public identifier (FPI) specified in the previous section.
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:
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:
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:
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 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.
5.2.1 STRBUFFER
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.
5.2.2 FILLER
The "filler" type is not implemented in the IDEF DTD.
5.2.3 USERID
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 or 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
********************************************************************
5.2.4 USERINFO
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 or MUST be provided; the other
sub-elements are OPTIONAL.
5.2.5 ADDRESSID
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 sub-element MUST be provided; the 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
********************************************************************
5.2.6 FILEID
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 and 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 [ and ] or [
and ] MUST be provided. Both pairs MAY be provided.
5.2.7 HOSTID
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.
5.2.8 PROCESSID
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 , , or both MUST be provided; the other
sub-elements are OPTIONAL.
5.2.9 SERVICEID
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 , , 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
5.2.10 TIME
********************************************************************
** 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 sub-element is OPTIONAL; all other sub-elements are
REQUIRED.
5.2.11 IDSID
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 , , , , or
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 element. The
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 element has two sub-elements: and
; each may contain zero or more of each of
these sub-elements.
6.1 HEARTBEAT
The 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
6.2 EVENT
The 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 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)
********************************************************************
** , , and need to have hi/lo limits **
** and we need to decide which direction the ranking goes. **
** **
** needs to have defined values, strings or numbers **
********************************************************************
More detailed information about the event MAY be provided using one
sub-element of type , , ,
or .
The