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