INTERNET-DRAFT Yixian Yang Expires: May 2004 Ming Tao Yonggang Chu Beijing University of Posts and Telecom. Nov 2003 Security Components Interactive Message Format Data Model and Extensible Markup Language (XML) Document Type Definition Status of This Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract The purpose of the Security Components Message Exchange Format (SCIMF) is to define data formats and exchange procedures for sharing information of security components, and for the management systems which may need to interact with each other. This Internet-Draft describes a data model to represent information exported by alert-make systems, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. Yixian Yang, et al. Expires May, 2004 [Page 1] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 TABLE OF CONTENTS Status of This Memo ................................................1 Abstract ...........................................................1 1. Conventions Used in This Document ...............................4 2. Introduction ....................................................4 2.1 About the SCIMF Data Model .................................5 2.1.1 Problems Addressed by the Data Model .................5 2.1.2 Data Model Design Goals ..............................6 2.2 About the SCIMF XML Implementation .........................6 2.3 Relationship between SCIMF and IDMEF .......................8 3. Notational Conventions and Formatting Issues ....................8 3.1 SCIMF XML Documents ........................................8 3.1.1 The Document Prolog ..................................8 3.1.1.1 XML Declaration ................................9 3.1.1.2 SCIMF DTD Formal Public Identifier .............9 3.1.1.3 SCIMF DTD Document Type Declaration ............9 3.1.2 Character Data Processing in XML and SCIMF ...........10 3.1.3 Languages in XML and SCIMF ...........................10 3.1.4 Inheritance and Aggregation ..........................10 3.2 SCIMF Data Types ...........................................11 3.2.1 Integers .............................................11 3.2.2 Real Numbers .........................................11 3.2.3 Characters and Strings ...............................11 3.2.4 Bytes ................................................11 3.2.5 Enumerated Types .....................................12 3.2.6 Date-Time Strings ....................................12 3.2.7 NTP Timestamps .......................................14 3.2.8 Port Lists ...........................................14 3.2.9 Unique Identifiers ...................................14 3.2.10 Path ................................................15 4. The SCIMF Data Model and XML DTD ................................16 4.1 Data Model Overview ........................................16 4.2 The Message Classes ........................................17 4.2.1 The SCIMF-Message Class ..............................18 4.2.2 The Heartbeat Class ..................................18 4.2.3 The Alert Class ......................................19 4.2.4 The Command Classes ..................................22 4.2.5 The Core Classes .....................................24 4.2.5.1 The Parameter class ............................24 Yixian Yang, et al. Expires May, 2004 [Page 2] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 4.2.5.2 The Source Class ...............................26 4.2.5.3 The Target Class ...............................28 4.2.5.4 The Alertmaker Class ...........................30 4.2.5.5 The AdditionalData Class .......................32 4.2.6 The Time Classes .....................................33 4.2.6.1 The CommandTime Class ..........................33 4.2.6.2 The CreateTime Class ...........................33 4.2.7 The Support Classes ..................................34 4.2.7.1 The Node Class .................................34 4.2.7.2 The User Class .................................36 4.2.7.3 The Process Class ..............................37 4.2.7.4 The Service Class ..............................38 4.2.7.5 The Classification Class .......................39 4.2.7.6 The Alertpath class ............................41 4.2.7.7 The Certificate class ..........................42 4.2.7.8 The Cost class .................................43 4.2.7.9 The Evidence Class .............................44 4.2.7.10The EvidenceData Class .........................45 5. Extending the SCIMF .............................................47 5.1 Extending the Data Model ...................................47 5.2 Extending the XML DTD ......................................48 6. Special Considerations ..........................................49 6.1 XML Validity and Well-Formedness ...........................50 6.2 Unrecognized XML Tags ......................................50 6.3 Alertmaker-Manager Time Synchronization ....................51 6.4 NTP Timestamp Wrap-Around ..................................52 6.5 Digital Signatures .........................................53 7. Experimental implementation and examples .......................53 8. The SCIMF Document Type Definition ..............................54 9. Security Considerations .........................................61 10. References .....................................................61 11. Acknowledgements ...............................................63 12. Author's Addresses .............................................63 Full Copyright Statement ...........................................64 Yixian Yang, et al. Expires May, 2004 [Page 3] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 1. 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. An "SCIMF-compliant application" is a program or program component, such as an alertmaker/manager or responser, that reads and/or writes messages in the format specified by this memo. An "SCIMF document" is a message that adheres to the requirements specified by this memo, and that is exchanged by two or more SCIMF applications. "SCIMF message" is another term for an "SCIMF document." 2. Introduction With the development of the network, IDS is more and more important to the security of the networks. But most IDSs can only finish the intrusion detection and a little interaction. This results in the delay of dealing with the network intrusion actions, which will cause lots of losing. This document mainly designs the interface of the existing IDSs and some other security components. 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 SCIMF is in the data channel between one security component (or "sensor") and another. But there are other places where the SCIMF can be useful: + a single database system that could store the results from a variety of security components 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 alerts from a variety of security components 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 alerts and commands from a variety of security components 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. + a common data exchange format would make it easier for different organizations (users, vendors, response teams, law enforcement) to not only exchange data, but also communicate about it. Yixian Yang, et al. Expires May, 2004 [Page 4] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The diversity of uses for the SCIMF needs to be considered when selecting its method of implementation. The security components include: firewall AV(Anti Virus) SCANNER(Security Scanner) ROUTER CA(Certificate Audit) HONEYPOT LA(Log Audit) Netmanager The relationship among these security componentsú¦ +----------+ <----------------- +----------+ |-->| IDS |<---------| | | LA | | +----------+ | | +----------+ | | | | | | | | | | +----------+ | | +----------+ |---| CA | | |----| AV | | +----------+ | +----------+ | | | | | +----------+ | +----------+ |---| HONEYPOT | |-------->|FW/ROUTER | | +----------+ | +----------+ | | | | | +----------+ | +----------+ |---| SCANNER | |-------->|NETMANAGER| +----------+ +----------+ Figure 2.1 - relationship among security components 2.1 About the SCIMF Data Model The SCIMF data model is an object-oriented representation of the alert data and interaction command sent to the security components. 2.1.1 Problems Addressed by the Data Model The data model addresses several problems associated with representing intrusion detection alert data and the interaction command: Yixian Yang, et al. Expires May, 2004 [Page 5] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 + The data model must be flexible to accommodate different needs. + The data model defines support classes that accommodate the differences in data sources + Different alertmakers may make alerts with different information sources to the same attack action, so the manager will take different responses. + The data model must allow the format transform of the alerts by the third party, not the alertmaker. + The aims of the interaction may be at least one. 2.1.2 Data Model Design Goals The data model was designed to provide a standard representation of alerts and commands in an unambiguous fashion, and to permit the relationship between simple and complex alerts to be described, so the security components can response exactly in time. The model must provide a method to aggregate the simple classes into the complex one. 2.1.2.1 Representing Events The goal of the data model which we presents is to provide a standard representation of the information that an alertmaker (section4.2.5.4) reports when it detects an occurrence of some unusual events. These alerts may be simple or complex, depending on the capabilities of the alertmaker that creates them. 2.1.2.2 Content-Driven The design of the data model is content-driven. This means that new objects are introduced to accommodate additional content, not semantic differences between alerts. This is an important goal, as the task of classifying and naming computer vulnerabilities is both extremely difficult and very subjective. The data model must be unambiguous. This means that while we allow alertmakers to be more or less precise than one another (i.e., one alertmaker may report more information about an event than another), we do not allow them to produce contradictory information in two alerts describing the same event (i.e., the common subset of Yixian Yang, et al. Expires May, 2004 [Page 6] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 information reported by both alertmakers must be identical and inserted in the same placeholders within the alert data structure). Of course, it is always possible to insert all "interesting" information about an event in extension fields of the alert instead of in the fields where it belongs; however, such practice reduces interoperability and should be avoided whenever possible, while we may use these alerts to make the same response. 2.2 About the SCIMF XML Implementation Two implementations of the SCIMF were originally proposed to the IDWG: one using the Structure of Management Information (SMI) to describe an SNMP MIB, and the other using a Document Type Definition(DTD) to describe XML documents. These proposed implementations were reviewed by the IDWG at its September 1999 and February 2000 meetings; it was decided at the February meeting that the XML solution was best at fulfilling the IDWG requirements. 2.2.1 The Extensible Markup Language The Extensible Markup Language (XML) [1] is a simplified version of the Standard Generalized Markup Language (SGML), a syntax for specifying text markup 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. Yixian Yang, et al. Expires May, 2004 [Page 7] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 2.3 Relationship between SCIMF and IDMEF One of SCIMF design principle is compatibility with Intrusion Detection Message Exchange Format (IDMEF) developed for Intrusion Detection Systems. SCIMF is heavily based on IDMEF and has upward compatibility with IDMEF that assures inheritance of IDMEF data structure. SCIMF re-uses most of class definitions from IDMEF. IDMEF message may be simply wrapped up into IDMEF container. When Incident description is produced of IDMEF message, SCIMF may directly use related data classes/elements from IDMEF. In this context is recommended that IHS understands both format - SCIMF and IDMEF. This may be achieved by mapping part of IDMEF classes (XML tags) related to response into SCIMF classes. This is not a difficult task because of initial approach to match SCIMF and IDMEF XML namespaces. Otherwise SCIMF parser will still be able to parser well-formed IDMEF document and recognize important XML tags, which semantics and meaning in SCIMF is inherited from IDMEF. 3. Notational Conventions and Formatting Issues This document uses three notations: Unified Modeling Language to describe the data model, XML to describe the markup used in SCIMF documents, and SCIMF markup to represent the documents themselves. 3.1 SCIMF XML Documents This section describes SCIMF XML document formatting rules. Most of these rules are "inherited" from the rules for formatting XML documents. 3.1.1 The Document Prolog The format of a SCIMF XML document prolog is described in the following sections. Yixian Yang, et al. Expires May, 2004 [Page 8] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 3.1.1.1 XML Declaration SCIMF documents being exchanged between SCIMF-compliant applications MUST begin with an XML declaration, and MUST specify the XML version in use. Specification of the encoding in use is RECOMMENDED. SCIMF-compliant applications MAY choose to omit the XML declaration internally to conserve space, adding it only when the message is sent to another destination (e.g., a web browser). This practice is NOT RECOMMENDED unless it can be accomplished without loss of each message's version and encoding information. 3.1.1.2 SCIMF DTD Formal Public Identifier The formal public identifier (FPI) for the SCIMF Document Type Definition described in this memo is: "-//IETF//DTD RFC XXXX SCIMF v1.0//EN" This FPI MUST be used in the document type declaration within an XML document referencing the SCIMF DTD defined by this memo, as shown in the following section. 3.1.1.3 SCIMF DTD Document Type Declaration The document type declaration for an XML document referencing the SCIMF 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 URI that points to a copy of the Document Type Definition. In order to be valid (see Section 6.1), an XML document must contain a document type declaration. However, this represents significant overhead to an SCIMF-compliant application, both in the bandwidth it consumes as well as the requirements it places on the XML processor (not only to parse the declaration itself, but also to parse the DTD it references). Yixian Yang, et al. Expires May, 2004 [Page 9] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Implementors MAY decide, therefore, to have alertmakers and managers agree out-of-band on the particular document type definition they will be using to exchange messages (the standard one as defined here, or one with extensions), and then omit the document type declaration from SCIMF messages. The method for negotiating this agreement is outside the scope of this document. Note that great care must be taken in negotiating any such agreements, as the manager may have to accept messages from many different alertmakers, each using a DTD with a different set of extensions. 3.1.2 Character Data Processing in XML and SCIMF For portability reasons, SCIMF-compliant applications SHOULD NOT use, and SCIMF messages SHOULD NOT be encoded in, character encodings other than UTF-8 and UTF-16. Consistent with the XML standard, if no encoding is specified for an SCIMF message, UTF-8 is assumed. NOTE: The ASCII character set is a subset of the UTF-8 encoding, and therefore may be used to encode SCIMF messages. Per the XML standard, SCIMF documents encoded in UTF-16 MUST begin with the Byte Order Mark described by ISO/IEC 10646 Annex E and Unicode Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character, #xFEFF). 3.1.3 Languages in XML and SCIMF SCIMF-compliant 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 element and letting all other elements "inherit" that definition. If no language is specified for an SCIMF message, English SHALL be assumed. All SCIMF tags MUST support the "xml:lang" attribute. 3.1.4 Inheritance and Aggregation XML DTDs do not support inheritance as used by the SCIMF data model (i.e., there is no support for "kind-of" relationships). This does not present a major problem in practice; aggregation relationships have been used instead to implement these relationships with little loss of functionality. As a note of interest, XML Schemas, recently approved by the W3C, will provide support for inheritance, as well as stronger data typing and other useful features. Future versions of the SCIMF may probably use XML Schemas instead of DTDs. It was recognized that for initial stage of new application design XML DTD provides better human readable format of document and elements description, however further development of application and its possible integration into Information/Incident management system may require more detailed definition of data types and object/elements relations. Yixian Yang, et al. Expires May, 2004 [Page 10] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 3.2 SCIMF Data Types Within an XML SCIMF message, all data will be expressed as "text" (as opposed to "binary"), since XML is a text formatting language. We provide typing information for the attributes of the classes in the data model however, to convey to the reader the type of data the model expects for each attribute. Each data type in the model has specific formatting requirements in an XML SCIMF message; these requirements are set forth in this section. 3.2.1 Integers Integer attributes are represented by the INTEGER data type. Integer data MUST be encoded in Base 10 or Base 16. Base 10 integer encoding uses the digits '0' through '9' and an optional sign ('+' or '-'). For example, "123", "-456". Base 16 integer encoding uses the digits '0' through '9' and 'a' through 'f' (or their upper case equivalents), and is preceded by the characters "0x". For example, "0x1a2b". 3.2.2 Real Numbers Real (floating-point) attributes are represented by the REAL data type. Real data MUST be encoded in Base 10. Real encoding is that of the POSIX 1003.1 "strtod" library function: an optional sign ('+' or '-') followed by a non-empty string of decimal digits, optionally containing a radix character, then an optional exponent part. An exponent part consists of an 'e' or 'E', followed by an optional sign, followed by one or more decimal digits. For example, "123.45e02", "-567,89e-03". SCIMF-compliant applications MUST support both the '.' and ',' radix characters. 3.2.3 Characters and Strings Single-character attributes are represented by the CHARACTER data type. Multi-character attributes of known length are represented by the STRING data type. Character and string data have no special formatting requirements, other than the need to occasionally use character references (see Sections A.3.2.1 and A.3.2.2) to represent special characters. 3.2.4 Bytes Yixian Yang, et al. Expires May, 2004 [Page 11] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Binary data is represented by the BYTE (and BYTE[]) data type. Binary data MUST be encoded in its entirety using character code references (see Section A.3.2.2). 3.2.5 Enumerated Types Enumerated types are represented by the ENUM data type, and consist of an ordered list of acceptable values. Each value has a rank (number) and a representing keyword. Within SCIMF XML messages, the enumerated type keywords are used as attribute values, and the ranks are ignored. However, those SCIMF- compliant applications that choose to represent these values internally in a numeric format MUST use the rank values identified in this memo. 3.2.6 Date-Time Strings Date-time strings are represented by the DATETIME data type. Each date-time string identifies a particular instant in time; ranges are not supported. Date-time strings are formatted according to a subset of ISO 8601:2000 [5], as show below. Section references in parentheses refer to sections of the ISO 8601:2000 standard. 1. Dates MUST be formatted as follows: YYYY-MM-DD where YYYY is the four- digit year, MM is the two-digit month (01-12), and DD is the two- digit day (01-31). (Section 5.2.1.1, "Complete representation -- Extended format.") 2. Times MUST be formatted as follows: hh:mm:ss where hh is the two-digit hour (00-24), mm is the two-digit minute(00-59), and ss is the two-digit second (00-60). (Section 5.3.1.1, "Complete representation -- Extended format.") Note that midnight has two representations, 00:00:00 and 24:00:00.Both representations MUST be supported by SCIMF-compliant applications, however, the 00:00:00 representation SHOULD be used whenever possible. Yixian Yang, et al. Expires May, 2004 [Page 12] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Note also that this format accounts for leap seconds. Positive leap seconds are inserted between 23:59:59Z and 24:00:00Z and are represented as 23:59:60Z. Negative leap seconds are achieved by the omission of 23:59:59Z. SCIMF-compliant applications MUST support leap seconds. 3. Times MAY be formatted to include a decimal fraction of seconds, as follows: hh:mm:ss.ss or hh:mm:ss,ss As many digits as necessary may follow the decimal sign (at least one digit must follow the decimal sign). Decimal fractions of hours and minutes are not supported. (Section 5.3.1.3, "Representation of decimal fractions.") SCIMF-compliant applications MUST support the use of both decimal signs ('.' and ','). Note that the number of digits in the fraction part does not imply anything about accuracy -- i.e., "00.100000", "00,1000" and "00.1" are all equivalent. 4. Times MUST be formatted to include (a) an indication that the time is in Coordinated Universal Time (UTC), or (b) an indication of the difference between the specified time and Coordinated Universal Time. a. Times in UTC MUST be formatted by appending the letter 'Z' to the time string as follows: hh:mm:ssZ hh:mm:ss.ssZ hh:mm:ss,ssZ (Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended format.") b. If the time is ahead of or equal to UTC, a '+' sign is appended to the time string; if the time is behind UTC, a '-' sign is appended. Following the sign, the number of hours and minutes representing the different from UTC is appended, as follows: hh:mm:ss+hh:mm hh:mm:ss-hh:mm hh:mm:ss.ss+hh:mm hh:mm:ss.ss-hh:mm hh:mm:ss,ss+hh:mm hh:mm:ss,ss-hh:mm Yixian Yang, et al. Expires May, 2004 [Page 13] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The difference from UTC MUST be specified in both hours and minutes, even if the minutes component is 0. A "difference" of "+00:00" is equivalent to UTC. (Section 5.3.4.2, "Local time and the difference with Coordinated Universal Time -- Extended Format.") 5. Date-time strings are created by joining the date and time strings with the letter 'T', as shown below: YYYY-MM-DDThh:mm:ssZ YYYY-MM-DDThh:mm:ss.ssZ YYYY-MM-DDThh:mm:ss,ssZ YYYY-MM-DDThh:mm:ss+hh:mm YYYY-MM-DDThh:mm:ss-hh:mm YYYY-MM-DDThh:mm:ss.ss+hh:mm YYYY-MM-DDThh:mm:ss.ss-hh:mm YYYY-MM-DDThh:mm:ss,ss+hh:mm YYYY-MM-DDThh:mm:ss,ss-hh:mm In summary, SCIMF date-time strings MUST adhere to one of the nine templates identified in Paragraph 5, above. 3.2.7 NTP Timestamps NTP timestamps are represented by the NTPSTAMP data type, and are described in detail in [6] and [7]. An NTP timestamp is a 64-bit unsigned fixed-point number. The integer part is in the first 32 bits, and the fraction part is in the last 32 bits. Within SCIMF messages, NTP timestamps MUST be encoded as two 32-bit hexadecimal values, separated by a period ('.'). For example, "0x12345678.0x87654321". See also Section 6.4 for more information on NTP timestamps. 3.2.8 Port Lists Port lists are represented by the PORTLIST data type, and consist of a comma-separated list of numbers (individual integers) and ranges N-M means ports N through M, inclusive). Any combination of numbers and ranges may be used in a single list. For example, "5-25,37,42,43,53,69-119,123-514". 3.2.9 Unique Identifiers There are two types of unique identifiers used in this specification. Both types are represented by STRING data types. Yixian Yang, et al. Expires May, 2004 [Page 14] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 These identifiers are implemented as attributes on the relevant XML elements, and must have unique values as follows: 1. The Alertmaker class' (Section 4.2.4.1) "alertmakerid" attribute, if specified, MUST have a value that is unique across all alertmakers in the intrusion detection environment. The "alertmakerid" attribute is not required to be globally unique, only unique within the intrusion detection environment of which the alertmaker is a member. It is permissible for two alertmakers, in different intrusion detection environments, to have the same value for "alertmakerid". The default value is "0", which indicates that the alertmaker cannot generate unique identifiers. 2. The Alert, Heartbeat, Command, Source, Target, Node, User, Process, Service, (Sections 4.2.3, 4.2.2, 4.2.4, 4.2.5.2, 4.2.5.3, 4.2.7.1, 4.2.7.2, 4.2.7.3,4.2.7.4) "ident" attribute, if specified, MUST have a value that is unique across all messages sent by the individual alertmaker. The "ident" attribute value MUST be unique for each particular combination of data identifying an object, not for each object. Objects may have more than one "ident" value associated with them. For example, an identification of a host by name would have one value, while an identification of that host by address would have another value, and an identification of that host by both name and address would have still another value. Furthermore, different alertmakers may produce different values for the same information. The "ident" attribute by itself provides a unique identifier only among all the "ident" values sent by a particular alertmaker. But when combined with the "alertmakerid" value for the alertmaker, a value that is unique across the intrusion detection environment is created. Again, there is no requirement for global uniqueness. The default value is "0", which indicates that the alertmaker cannot generate unique identifiers. The specification of methods for creating the unique values contained in these attributes is outside the scope of this document. 3.2.10 Path The Alertpath class is used to indicate the path by which an alert was transmitted. It is a STRING type. The initial value should be the ip address(for example, A:202.112.140.230) of the node that the alert is originated, after the alert message is sent to the upper node(B:202.112.1.111), then the value of the Alertpath turns Yixian Yang, et al. Expires May, 2004 [Page 15] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 to "B.A", which means now the Alertpath equals to 202.112.1.111.202.112.240.230. By this means, the Alertpath calss takes the information of all nodes that the alert message was relayed by. The rest may be deduced by analogy, when a node C was reached, the path will contain the ip address of the nodes C, B, A. Even for more nodes. 4. The SCIMF Data Model and XML DTD In this section, the individual components of the SCIMF data model are explained in detail. UML diagrams of the model are provided to show how the components are related to each other, and relevant sections of the XML DTD are presented to show how the model is translated into XML. 4.1 Data Model Overview The relationship between the principal components of the data model is shown in Figure 4.1 on the following page (occurrence indicators and attributes are omitted). The top-level class for all SCIMF messages is SCIMF-Message; each type of message is a subclass of this top-level class. There are presently three types of messages defined; Alerts, Heartbeats and Commands. Within each message, subclasses of the message class are used to provide the detailed information carried in the message. It is important to note that the data model does not specify how an alert should be classified or identified. For example, a port scan may be identified by one alertmaker as a single attack against multiple targets, while another alertmaker might identify it as multiple attacks from a single source. However, once an alertmaker has determined the type of alert it plans to send, the data model dictates how that alert should be formatted. +-------------+ |SCIMF-Message| +-------------+ /_\ | +-------------------------+------------+ | | | +-------+ +-----------+ +---------+ +-------+ +-----------+ |Command|<>-|CommandTime| |Heartbeat| | Alert |<>-|Alertmaker | +-------+ +-----------+ +---------+ +-------+ +-----------+ | | +---------+ +--------+ | | +-----------+ | |<>-|Parameter|<>-| cost | | |<>-|CreateTime | | | +---------+ +--------+ | | +-----------+ Yixian Yang, et al. Expires May, 2004 [Page 16] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 | | | | +--------+ | | +-----------+ | | | |<>-| Time | | |<>-|DetectTime | | | | | +--------+ | | +-----------+ | | | | +--------+ | | +-----------+ | | | |<>-| Result | | |<>-| Target | | | | | +--------+ | | +-----------+ | | | | +-----------+ | | +-----------+ | | | |<>-|certificate| | |<>-| Source | | | | | +-----------+ | | +-----------+ | | | | +--------+ | | +--------------+ | | | |<>-| update | | |<>-|AlertmakerTime| | | | | +--------+ | | +--------------+ | | | | +-------------+ | | +--------------+ | | | |<>-|AdditinalData| | |<>-|Classification| | | +---------+ +-------------+ | | +--------------+ | | +--------+ +----------+ | | +--------------+ | |<>-| Source |<>-| Node | | |<>-| Assessment | | | +--------+ +----------+ | | +--------------+ | | | | +----------+ | | +--------------+ | | | |<>-| User | | |<>-|AdditinalData | | | | | +----------+ +-------+ +--------------+ | | | | +----------+ | | | |<>-| Process | | | | | +----------+ | | | | +----------+ | | | |<>-| Service | | | +--------+ +----------+ | | +--------+ +----------+ | |<>-| Target |<>-| Node | | | +--------+ +----------+ | | | | +----------+ | | | |<>-| User | | | | | +----------+ | | | | +----------+ | | | |<>-| Process | | | | | +----------+ | | | | +--------- + | | | |<>-| Service | | | | | +----------+ | | | | +----------+ | | | |<>-| FileList | | | +--------+ +----------+ | | +---------------+ | |<>-|AdditionalData | +-------+ +---------------+ Figure 4.1 - Data model overview 4.2 The Message Classes The individual classes are described in the following sections. Yixian Yang, et al. Expires May, 2004 [Page 17] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 4.2.1 The SCIMF-Message Class All SCIMF messages are instances of the SCIMF-Message class; it is the top-level class of the SCIMF data model, as well as the SCIMF DTD. There are currently three types (subclasses) of SCIMF-Message: Alert, Heartbeat and Command. Because DTDs do not support subclassing (see Section A.3.4), the inheritance relationship between SCIMF-Message and the Alert, Heartbeat and Command subclasses shown in Figure 4.1 has been replaced with an aggregate relationship. This is declared in the SCIMF DTD as follows: The SCIMF-Message class has a single attribute: version The version of the SCIMF-Message specification (this document) this message conforms to. Applications specifying a value for this attribute MUST specify the value "1.0". 4.2.2 The Heartbeat Class Alertmakers use Heartbeat messages to indicate their current status to Managers, and the timestampt in Heartbeat messages can be used to implement the synchronization by security components. Heartbeats are intended to be sent in a regular period, say every ten minutes or every hour. The receipt of a Heartbeat message from an alertmaker indicates to the manager that the alertmaker is up and running; lack of a Heartbeat message (or more likely, lack of some number of consecutive Heartbeat messages) indicates that the alertmaker or its network connection has failed. All managers MUST support the receipt of Heartbeat messages; however, the use of these messages by alertmakers is OPTIONAL. Developers of manager software SHOULD permit the software to be configured on a per-alertmaker basis to use/not use Heartbeat messages. A Heartbeat message is composed of several aggregate classes, as shown in Figure 4.2. Yixian Yang, et al. Expires May, 2004 [Page 18] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 +--------------+ | Heartbeat | +--------------+ +------------------+ | STRING ident |<>----------| Alertmaker | | | +------------------+ | | +------------------+ | |<>----------| CreateTime | | | +------------------+ | | 0..1 +------------------+ | |<>----------| AlertmakerTime | | | +------------------+ | | 0..* +------------------+ | |<>----------| AdditionalData | | | +------------------+ +--------------+ Figure 4.2 - The Heartbeat Class The aggregate classes that make up Heartbeat are: Alertmaker Exactly one. Identification information for the alertmaker that originated the heartbeat. CreateTime Exactly one. The time the heartbeat was created. AlertmakerTime Zero or one. The current time on the alertmaker (see Section 6.3). AdditionalData Zero or more. Information included by the alertmaker that does not fit into the data model. This may be an atomic piece of data, or a large amount of data provided through an extension to the SCIMF(see Section 5). This is represented in the XML DTD as follows: The Heartbeat class has one attribute: ident Optional. A unique identifier for the heartbeat, see Section 3.2.9. 4.2.3 The Alert Class Yixian Yang, et al. Expires May, 2004 [Page 19] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Generally, every time an alertmaker detects an event that it has been configured to look for, it sends an Alert message to its manager(s). Depending on the alertmaker, an Alert message may correspond to a single detected event, or multiple detected events. Alerts occur asynchronously in response to outside events. An Alert message is composed of several aggregate classes, as shown in Figure 4.3. The detailed imformation can be searched about the alert class in the SCIMF doc. +---------------+ | Alert | +---------------+ +----------------+ | STRING ident |<>----------| Alertmaker | | | +----------------+ | | +----------------+ | |<>----------| CreateTime | | | +----------------+ | | 0..1 +----------------+ | |<>----------| DetectTime | | | +----------------+ | | 0..1 +----------------+ | |<>----------| AlertmakerTime | | | +----------------+ | | 0..* +----------------+ | |<>----------| Source | | | +----------------+ | | 0..* +----------------+ | |<>----------| Target | | | +----------------+ | | 1..* +----------------+ | |<>----------| Classification | | | +----------------+ | | 0..1 +----------------+ | |<>----------| Assessment | | | +----------------+ | | 0..* +----------------+ | |<>----------| AdditionalData | | | +----------------+ +---------------+ /_\ | +----+------------+-------------+ | | | +-------------------+ | +-------------------+ | ToolAlert | | | CorrelationAlert | +-------------------+ | +-------------------+ | +-------------------+ | OverflowAlert | +-------------------+ Figure 4.3 - The Alert Class Yixian Yang, et al. Expires May, 2004 [Page 20] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The aggregate classes that make up Alert are: Alertmaker Exactly one. Identification information for the alertmaker that originated the alert. CreateTime Exactly one. The time the alert was created. Of the three times that may be provided with an Alert, this is the only one that is required. DetectTime Zero or one. The time the event(s) leading up to the alert was detected. In the case of more than one event, the time the first event was detected. In some circumstances, this may not be the same value as CreateTime. AlertmakerTime Zero or one. The current time on the alertmaker(see Section 6.3). Source Zero or more. The source(s) of the event(s) leading up to the alert. Target Zero or more. The target(s) of the event(s) leading up to the alert. Classification One or more. The "name" of the alert, or other information allowing the manager to determine what it is. Assessment Zero or one. Information about the impact of the event, actions taken by the alertmaker in response to it, and the alertmaker's confidence in its evaluation. AdditionalData Zero or more. Information included by the alertmaker that does not fit into the data model. This may be an atomic piece of data, or a large amount of data provided through an extension to the SCIMF(see Section 5). Because DTDs do not support subclassing (see Section A.3.4), the inheritance relationship between Alert and the ToolAlert, CorrelationAlert, and OverflowAlert subclasses shown in Figure 4.2 has been replaced with an aggregate relationship. Alert is represented in the XML DTD as follows: The Alert class has one attribute: ident Optional. A unique identifier for the alert, see Section 3.2.9. 4.2.4 The Command class The main purpose of sending an alert is that the security components can cooperate immediately to deal with all instances when an intrusion action is detected. And the command class just serves for this purpose. The command includes: blocking the existing connection or the attempt; closing the existing service or the corresponding port; shutting down the security components; exchanging data selected by the security components; broadcasting the system update information; even modifying the configuration files, and so on. The command reflects the capability of one security component to control the others. An Command message is composed of several aggregate classes, as shown in Figure 4.4. +---------------+ | Command | +---------------+ | STRING ident | | STRING name | | | 0..1+------------------+ | |<>----------| CommandTime | | | +------------------+ | | 1..*+------------------+ | |<>----------| parameter | | | +------------------+ | | 0..*+------------------+ | |<>----------| AdditionalData | | | +------------------+ | | +------------------+ | |<>----------| Source | | | +------------------+ | | +------------------+ | |<>----------| Target | | | +------------------+ +---------------+ Figure 4.4- The Command Class The aggregate classes that make up Command are: Yixian Yang, et al. Expires May, 2004 [Page 22] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Name Exactly one. The name of the command sent to the security component. CommandTime Zero or one. The time of sending the command. Parameter One or more. The parameter taken by the command. AdditonalData One or more. Information included by the alertmaker that does not fit into the data model. This may be an atomic piece of data, or a large amount of data provided through an extension to the SCIMF(see Section 5). Source Exactly one. The security component which sends the command. Target Exactly one. The security component which receives the command and acts as what the command says. Command is represented in the XML DTD as follows: The Command class has two attributes: ident Optional. A unique identifier for the command, see Section 3.2.9. name Optional. The name of the command. The permitted values for this attribute are shown below. The default value is "unknown". Rank Keyword Description ---- ------- ----------- 0 block The command to block the existing connection or the attempt 1 connect The command to built a connection 2 demand The command to demand the security components to supply the necessary data 3 notify The command to notify other security components 4 reply The command as a reply to other command Yixian Yang, et al. Expires May, 2004 [Page 23] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 4.2.5 The Core Classes The core classes -- Alertmaker, Source, Target, Parameter, and AdditionalData -- are the main parts of Alerts, Heartbeats and Commands, as shown in Figure 4.5. +-----------+ +----------------+ | Heartbeat | +-------| Alertmaker | +-----------+ | +----------------+ | |<>---+--+ +-----------+ | | 0..* +----------------+ | +-------| AdditionalData | | +----------------+ +-----------+ | | Alert | | 0..* +----------------+ +-----------+ | +-------| Source | | |<>---+ | +----------------+ | | | 0..* +----------------+ | | +-------| Target | | | | +----------------+ | |<>------+ +-----------+ | 1..* +----------------+ +-------| Classification | | +----------------+ +-----------+ | +----------------+ | Command | +-------| Alertmaker | +-----------+ | +----------------+ | |<>------+ +-----------+ Figure 4.5 - The Core Classes 4.2.5.1 The Parameter class The parameter taken by the command which is sent to the security components includes the ip address, the port number, and the certificate, etc. +---------------+ | Parameter | +---------------+ 0..*+---------------+ | STRING ident |<>--------| cost | | STRING type | +---------------+ | integer number| 0..*+---------------+ | STRING content|<>--------| Time | | | +---------------+ | | 0..*+---------------+ | |<>--------| AdditinalData | | | +---------------+ | | 0..1+---------------+ Yixian Yang, et al. Expires May, 2004 [Page 24] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 | |<>--------| Result | | | +---------------+ | | 0..1+---------------+ | |<>--------| certificate | | | +---------------+ | | 0..1+---------------+ | |<>--------| update | | | +---------------+ +---------------+ Figure 4.6 - The Parameter Class The aggregate classes that make up Parameter are: Cost Zero or more. The cost of execute the command by the security components. Time Zero or more. The time parameter includes the beginning, the end and the time of the command to be executed, such as blocking a existing connection, the beginning time is 10:00, and the block lasts for 5 minutes, so the end time is 10:05. Result Zero or one. The result that the command is executed by the security component. Certificate Zero or one. The certificate of the security component. Update Zero or one. The update data to notify the security components. AdditonalData One or more. Information included by the alertmaker that does not fit into the data model. This may be an atomic piece of data, or a large amount of data provided through an extension to the SCIMF(see Section 5). Parameter is represented in the XML DTD as follows: The Parameter class has four attributes: Yixian Yang, et al. Expires May, 2004 [Page 25] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 ident Optional. A unique identifier for the parameter, see Section 3.2.9. type Optional. The type of the parameter. The permitted values for this attribute are shown below. The default value is "unknown". Rank Keyword Description ---- ------- ----------- 0 ip The parameter is a ip address 1 port The parameter is a port number 2 turnoff The command to turn off the security component 3 direction The direction of the command, means that the connection to be built or blocked by the security component is out of the network or into the network 4 certificate The certificate hold by the security component number Optional. The number of the parameter. Content Optional. The type of the parameter content, the permitted values for this attribute are shown below. The default value is "unknown". Rank Keyword Description ---- ------- ----------- 0 boolean The element contains a boolean value, i.e., the strings "true" or "false" 1 byte The element content is a single 8-bit byte (see Section 3.2.4) 2 character The element content is a single character (see Section 3.2.3) 3 date-time The element content is a date-time string (see Section 3.2.6) 4 integer The element content is an integer (see Section 3.2.1) 5 ntpstamp The element content is an NTP timestamp (see Section 3.2.7) 6 portlist The element content is a list of ports (see Section 3.2.8) 7 real The element content is a real number (see Section 3.2.2) 8 string The element content is a string (see Section 3.2.3) 9 xml The element content is XML-tagged data (see Section 5.2) 4.2.5.2 The Source Class Yixian Yang, et al. Expires May, 2004 [Page 26] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The Source class contains information about the possible source(s) of the event(s) that generated an alert. An event may have more than one source (e.g., in a distributed denial of service attack). The Source class is composed of four aggregate classes, as shown in Figure 4.7. +------------------+ | Source | +------------------+ 0..1 +---------+ | STRING ident |<>----------| Node | | ENUM spoofed | +---------+ | STRING interface | 0..1 +---------+ | |<>----------| User | | | +---------+ | | 0..1 +---------+ | |<>----------| Process | | | +---------+ | | 0..1 +---------+ | |<>----------| Service | | | +---------+ +------------------+ Figure 4.7 - The Source Class The aggregate classes that make up Source are: Node Zero or one. Information about the host or device that appears to be causing the events (network address, network name, etc.). User Zero or one. Information about the user that appears to be causing the event(s). Process Zero or one. Information about the process that appears to be causing the event(s). Service Zero or one. Information about the network service involved in the event(s). This is represented in the XML DTD as follows: The Source class has three attributes: ident Optional. A unique identifier for this source, see Section 3.2.9. spoofed Optional. An indication of whether the source is, as far as the alertmaker can determine, a decoy. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 10.) Rank Keyword Description ---- ------- ----------- 0 unknown Accuracy of source information unknown 1 yes Source is believed to be a decoy 2 no Source is believed to be "real" interface Optional. May be used by a network-based alertmaker with multiple interfaces to indicate which interface this source was seen on. 4.2.5.3 The Target Class The Target class contains information about the possible target(s) of the event(s) that generated an alert. An event may have more than one target (e.g., in the case of a port sweep). The Target class is composed of four aggregate classes, as shown in Figure 4.8. +------------------+ | Target | +------------------+ 0..1 +----------+ | STRING ident |<>----------| Node | | ENUM decoy | +----------+ | STRING interface | 0..1 +----------+ | |<>----------| User | | | +----------+ | | 0..1 +----------+ | |<>----------| Process | | | +----------+ | | 0..1 +----------+ | |<>----------| Service | | | +----------+ Yixian Yang, et al. Expires May, 2004 [Page 28] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 | | 0..1 +----------+ | |<>----------| FileList | | | +----------+ +------------------+ Figure 4.8 - The Target Class The aggregate classes that make up Target are: Node Zero or one. Information about the host or device at which the event(s) (network address, network name, etc.) is being directed. User Zero or one. Information about the user at which the event(s) is being directed. Process Zero or one. Information about the process at which the event(s) is being directed. Service Zero or one. Information about the network service involved in the event(s). FileList Zero or one. Information about file(s) involved in the event(s). This is represented in the XML DTD as follows: The Target class has three attributes: ident Optional. A unique identifier for this target, see Section 3.2.9. decoy Optional. An indication of whether the target is, as far as the alertmaker can determine, a decoy. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 10.) Yixian Yang, et al. Expires May, 2004 [Page 29] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Rank Keyword Description ---- ------- ----------- 0 unknown Accuracy of target information unknown 1 yes Target is believed to be a decoy 2 no Target is believed to be "real" interface Optional. May be used by a network-based alertmaker with multiple interfaces to indicate which interface this target was seen on. 4.2.5.4 The Alertmaker Class The Alertmaker class identifies the alertmaker from which the alert or heartbeat message originates. Only one alertmaker may be encoded for each alert or heartbeat, and that MUST be the alertmaker at which the alert or heartbeat originated. The SCIMF data model does not prevent the use of hierarchical intrusion detection systems (where alerts get relayed up the tree), for it provides the way to record the identity of the "relay" alertmakers along the path from the originating alertmaker to the manager that ultimately receives the alert. The Alertmaker class is composed of two aggregate classes, as shown in Figure 4.9. +---------------------+ | Alertmaker | +---------------------+ +---------+ | STRING Alertmakerid |<>----------| Node | | STRING manufacturer | +---------+ | STRING model | +---------+ | STRING version |<>----------| Process | | | +---------+ | | +------------+ | STRING ostype |<>----------|certificate | | STRING osversion | +------------+ | | +-----------+ | |<>----------| Alertpath | | | +-----------+ +---------------------+ Figure 4.9 - The Alertmaker Class The aggregate classes that make up Alertmaker are: Node Zero or one. Information about the host or device on which the alertmaker resides (network address, network name, etc.). Process Zero or one. Information about the process in which the alertmaker is executing. Yixian Yang, et al. Expires May, 2004 [Page 30] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 This is represented in the XML DTD as follows: The Alertmaker class has seven attributes: alertmakerid Optional (but see below). A unique identifier for the alertmaker, see Section 3.2.9. This attribute is only "partially" optional. If the alertmaker makes use of the "ident" attributes on other classes to provide unique identifiers for those objects, then it MUST also provide a valid "alertmakerid" attribute. This requirement is dictated by the uniqueness requirements of the "ident" attribute (they are unique only within the context of a particular "alertmakerid"). If the alertmaker does not make use of the "ident" attributes however, it may also omit the "alertmakerid" attribute. manufacturer Optional. The manufacturer of the alertmaker software and/or hardware. model Optional. The model name/number of the alertmaker software and/or hardware. version Optional. The version number of the alertmaker software and/or hardware. class Optional. The class of alertmaker software and/or hardware. ostype Optional. Operating system name. On POSIX 1003.1 compliant systems, this is the value returned in utsname.sysname by the uname() system call, or the output of the "uname -s" command. Yixian Yang, et al. Expires May, 2004 [Page 31] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 osversion Optional. Operating system version. On POSIX 1003.1 compliant systems, this is the value returned in utsname.release by the uname() system call, or the output of the "uname -r" command. The "manufacturer", "model", "version", and "class" attributes' contents are vendor-specific, but may be used together to identify different types of alertmakers (and perhaps make determinations about the contents to expect in other vendor-specific fields of SCIMF messages). 4.2.5.5 The AdditionalData Class The AdditionalData class is used to provide information that cannot be represented by the data model. AdditionalData can be used to provide atomic data (integers, strings, etc.) in cases where only small amounts of additional information need to be sent; it can also be used to extend the data model and the DTD to support the transmission of complex data (such as packet headers). Detailed instructions for extending the data model and the DTD are provided in Section 5. The AdditionalData element is declared in the XML DTD as follows: The AdditionalData class has two attributes: type Required. The type of data included in the element content. The permitted values for this attribute are shown below. The default value is "string". (See also Section 10.) Rank Keyword Description ---- ------- ----------- 0 boolean The element contains a boolean value, i.e., the strings "true" or "false" 1 byte The element content is a single 8-bit byte (see Section 3.2.4) 2 character The element content is a single character (see Section 3.2.3) 3 date-time The element content is a date-time string (see Section 3.2.6) Yixian Yang, et al. Expires May, 2004 [Page 32] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 4 integer The element content is an integer (see Section 3.2.1) 5 ntpstamp The element content is an NTP timestamp (see Section 3.2.7) 6 portlist The element content is a list of ports (see Section 3.2.8) 7 real The element content is a real number (see Section 3.2.2) 8 string The element content is a string (see Section 3.2.3) 9 xml The element content is XML-tagged data (see Section 5.2) meaning Optional. A string describing the meaning of the element content. These values will be vendor/implementation dependent; the method for ensuring that managers understand the strings sent by alertmaker is outside the scope of this specification. 4.2.6 The Time Classes The data model provides three classes for representing time. These classes are aggregates of the Alert, Heartbeat and Command classes. 4.2.6.1 The CommandTime Class The CommandTime class is used to indicate the date and time the command was created by the security component. It is represented in the XML DTD as follows: The CreateTime class has one attribute: ntpstamp Required. The NTP timestamp representing the same date and time as the element content. The NTPSTAMP format of this attribute's value is described in Section 3.2.7. If the date and time represented by the element content and the NTP timestamp differ (should "never" happen), the value in the NTP timestamp MUST be used. 4.2.6.2 The CreateTime Class Yixian Yang, et al. Expires May, 2004 [Page 33] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The CreateTime class is used to indicate the date and time the alert or heartbeat was created by the alertmaker. It is represented in the XML DTD as follows: The DATETIME format of the element content is described in Section 3.2.6. The CreateTime class has one attribute: ntpstamp Required. The NTP timestamp representing the same date and time as the element content. The NTPSTAMP format of this attribute's value is described in Section 3.2.7. If the date and time represented by the element content and the NTP timestamp differ (should "never" happen), the value in the NTP timestamp MUST be used. 4.2.7 The Support Classes The support classes make up the major parts of the core classes, and are shared between them. 4.2.7.1 The Node Class The Node class is used to identify hosts and other network devices (routers, switches, etc.). The Node class is composed of three aggregate classes, as shown in Figure 4.10. +---------------+ | Node | +---------------+ 0..1 +----------+ | STRING ident |<>----------| location | | ENUM category | +----------+ | | 0..1 +----------+ | |<>----------| name | | | +----------+ | | 0..* +----------+ | |<>----------| Address | | | +----------+ +---------------+ Figure 4.10 - The Node Class Yixian Yang, et al. Expires May, 2004 [Page 34] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The aggregate classes that make up Node are: location Zero or one. STRING. The location of the equipment. name Zero or one. STRING. The name of the equipment. This information MUST be provided if no Address information is given. Address Zero or more. The network or hardware address of the equipment. Unless a name (above) is provided, at least one address must be specified. This is represented in the XML DTD as follows: The Node class has two attributes: ident Optional. A unique identifier for the node, see Section 3.2.9. category Optional. The "domain" from which the name information was obtained, if relevant. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 10.) Rank Keyword Description ---- ------- ----------- 0 unknown Domain unknown or not relevant 1 ads Windows 2000 Advanced Directory Services 2 afs Andrew File System (Transarc) 3 coda Coda Distributed File System 4 dfs Distributed File System (IBM) 5 dns Domain Name System 6 hosts Local hosts file 7 kerberos Kerberos realm 8 nds Novell Directory Services 9 nis Network Information Services (Sun) 10 nisplus Network Information Services Plus (Sun) Yixian Yang, et al. Expires May, 2004 [Page 35] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 11 nt Windows NT domain 12 wfw Windows for Workgroups 4.2.7.2 The User Class The User class is used to describe users. It is primarily used as a "container" class for the UserId aggregate class, as shown in Figure 4.11. +---------------+ | User | +---------------+ 1..* +--------+ | STRING ident |<>----------| UserId | | ENUM category | +--------+ +---------------+ Figure 4.11 - The User Class The aggregate class contained in User is: UserId One or more. Identification of a user, as indicated by its type attribute (see Section 4.2.7.2.1). This is represented in the XML DTD as follows: The User class has two attributes: ident Optional. A unique identifier for the user, see Section 3.2.9. category Optional. The type of user represented. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 10.) Rank Keyword Description ---- ------- ----------- 0 unknown User type unknown 1 application An application user 2 os-device An operating system or device user Yixian Yang, et al. Expires May, 2004 [Page 36] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 4.2.7.3 The Process Class The Process class is used to describe processes being executed on sources, targets, and alertmakers. The Process class is composed of five aggregate classes, as shown in Figure 4.12. +--------------+ | Process | +--------------+ +------+ | STRING ident |<>----------| name | | | +------+ | | 0..1 +------+ | |<>----------| pid | | | +------+ | | 0..1 +------+ | |<>----------| path | | | +------+ | | 0..* +------+ | |<>----------| arg | | | +------+ | | 0..* +------+ | |<>----------| env | | | +------+ +--------------+ Figure 4.12 - The Process Class The aggregate classes that make up Process are: name Exactly one. STRING. The name of the program being executed. This is a short name; path and argument information are provided elsewhere. pid Zero or one. INTEGER. The process identifier of the process. path Zero or one. STRING. The full path of the program being executed. arg Zero or more. STRING. A command-line argument to the program. Multiple arguments may be specified (they are assumed to have occurred in the same order they are provided) with multiple uses of arg. env Zero or more. STRING. An environment string associated with the process; generally of the format "VARIABLE=value". Multiple environment strings may be specified with multiple uses of env. Yixian Yang, et al. Expires May, 2004 [Page 37] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 This is represented in the XML DTD as follows: The Process class has one attribute: ident Optional. A unique identifier for the process, see Section 3.2.9. 4.2.7.4 The Service Class The Service class describes network services on sources and targets. It can identify services by name, port, and protocol. When Service occurs as an aggregate class of Source, it is understood that the service is one from which activity of interest is originating; and that the service is "attached" to the Node, Process, and User information also contained in Source. Likewise, when Service occurs as an aggregate class of Target, it is understood that the service is one to which activity of interest is being directed; and that the service is "attached" to the Node, Process, and User information also contained in Target. The Service class is composed of four aggregate classes, as shown in Figure 4.13. +--------------+ | Service | +--------------+ 0..1 +----------+ | STRING ident |<>----------| name | | | +----------+ | | 0..1 +----------+ | |<>----------| port | | | +----------+ | | 0..1 +----------+ | |<>----------| portlist | | | +----------+ | | 0..1 +----------+ | |<>----------| protocol | | | +----------+ +--------------+ /_\ | +------------+ Yixian Yang, et al. Expires May, 2004 [Page 38] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 | +-------------+ | +-------------+ | SNMPService |--+--| WebService | +-------------+ +-------------+ Figure 4.13 - The Service Class The aggregate classes that make up Service are: name Zero or one. STRING. The name of the service. Whenever possible, the name from the IANA list of well-known ports SHOULD be used. port Zero or one. INTEGER. The port number being used. portlist Zero or one. PORTLIST. A list of port numbers being used; see Section 3.2.8 for formatting rules. protocol Zero or one. STRING. The protocol being used. A Service MUST be specified as either (a) a name, (b) a port, (c) a name and a port, or (d) a portlist. The protocol is optional in all cases, but no other combinations are permitted. Because DTDs do not support subclassing (see Section A.3.4), the inheritance relationship between Service and the SNMPService and WebService subclasses shown in Figure 4.18 has been replaced with an aggregate relationship. Service is represented in the XML DTD as follows: The Service class has one attribute: ident Optional. A unique identifier for the service, see Section 3.2.9. 4.2.7.5 The Classification Class Yixian Yang, et al. Expires May, 2004 [Page 39] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The Classification class provides the "name" of an alert, or other information allowing the manager to determine what it is (for example, to decide whether or not to display the alert on-screen, what color to display it in, etc.). The Classification class is composed of two aggregate classes, as shown in Figure 4.14. +----------------+ | Classification | +----------------+ +---------+ | STRING origin |<>------| name | | | +---------+ | | +---------+ | |<>------| url | | | +---------+ +----------------+ Figure 4.14 - The Classification Class Figure 5.23 The Classification Class The aggregate classes that constitute Classification are: name Exactly one. STRING. The name of the Vulnerability, Exposure or Virus (from one of the origins listed below) used by Attacker to cause Incident. url Exactly one. STRING. A URL at which the manager can find additional information about classified method. The URL may include an in-depth description of the attack, appropriate countermeasures, or other information deemed relevant by the vendor. This is represented in the XML DTD as follows: The Classification class has one attribute: origin Required. The source from which the name of the alert originates. The permitted values for this attribute are shown below. The default value is "unknown". Yixian Yang, et al. Expires May, 2004 [Page 40] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Rank Keyword Description ---- ------- ----------- 0 unknown Origin of the name is not known 1 bugtraqid The SecurityFocus.com ("Bugtraq") vulnerability database identifier (http://www.securityfocus.com/vdb) 2 cve The Common Vulnerabilities and Exposures (CVE) name (http://www.cve.mitre.org/) 3 vendor-specific A vendor-specific name (and hence, URL); this can be used to provide product- specific information 4.2.7.6 The Alertpath class The Alertpath class is used in the hierarchical intrusion detection systems(where alerts get relayed up the tree), for it provides the way to record the identity of the "relay" alertmakers along the path from the originating alertmaker to the manager that ultimately receives the alert. The whole path is presented as: C.B.A, A/B/C is a complete ip address, and A is the ip address of originating alertmaker, B is the relaying node, C is receiving node. Other relaying nodes can be inserted. +------------------+ | Alertpath | +------------------+ | STRING ident | +---------------+ | STRING number |<>------| address | | STRING category | +---------------+ | | +------------------+ Figure 4.15 - The Alertpath Class The aggregate classe that constitute Alertpath is: address Exactly one. STRING. The ip address of the node. This is represented in the XML DTD as follows: The Alertpath class has three attributes: ident Optional. A unique identifier for the node, see Section 3.2.9. Yixian Yang, et al. Expires May, 2004 [Page 41] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 number Optional. The times that the alert was relayed. category Optional. The "domain" from which the name information was obtained, if relevant. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 10.) Rank Keyword Description ---- ------- ----------- 0 beginning originating node 1 relay relaying node 2 end ultimate node 4.2.7.7 The Certificate class The Certificate class describes the certificate of the security component. It is used to communicate, and when the certificate is expired, IDSs and other security components should notify CA to renew the crl list. +------------------+ | Certificate | +------------------+ | STRING ident | +---------------+ | STRING version |<>------|AdditionalData | | STRING authority | +---------------+ | STRING time | | STRING serial | | STRING date | | STRING crladdress| | | +------------------+ Figure 4.16 - The Certificate Class The aggregate classe that constitute Certificate is: AdditionalData Zero or more. Information included by the alertmaker that does not fit into the data model. This may be an atomic piece of data, or a large amount of data provided through an extension to the SCIMF(see Section 5). This is represented in the XML DTD as follows: The Alertpath class has seven attributes: ident Optional. A unique identifier for the node, see Section 3.2.9. version Optional. The version of the certificate. Authority Optional. The authority that issues the certificate. Serial Optional. The serial number of the certificate. date Optional. The date that the certificate is efficient. time Optional. The period of validity crladdress Optional. The WWW address of the CRL list. 4.2.7.8 The Cost class The Cost class indicates the cost to execute one command by a security component. +------------------+ | cost | +------------------+ | STRING ident | +---------------+ | STRING cpu |<>------|AdditionalData | | STRING mem | +---------------+ | STRING time | | STRING network | | STRING pagefile | | | +------------------+ Figure 4.17 - The Cost Class The aggregate classe that constitute Cost is: Yixian Yang, et al. Expires May, 2004 [Page 43] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 AdditionalData Zero or more. Information included by the alertmaker that does not fit into the data model. This may be an atomic piece of data, or a large amount of data provided through an extension to the SCIMF(see Section 5). This is represented in the XML DTD as follows: The Alertpath class has five attributes: cpu Optional. The usage of cpu pagefile Optional. The usage of page file mem Optional. The usage of physical memory network Optional. The usage of network time Optional. The time to execute one command by a security component. 4.2.7.9 The Evidence Class The Evidence class contains evidence information related to current Incident and may consist of multiple "pieces" of Evidence data of different kind, including textual information (logfiles, malicious scripts, list of changes in file system, etc.) and binary (disc images, etc.). +------------------+ | Evidence | +------------------+ | STRING ident | 0..* +---------------+ | ENUM restriction |<>------| EvidenceData | +------------------+ +---------------+ Yixian Yang, et al. Expires May, 2004 [Page 44] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Figure 4.17 The Evidence Class The aggregate classes that constitute Evidence are: EvidenceData Zero or more. Container for Evidence data related to current Incident. Evidence is represented in the XML DTD as follows: The Evidence class has two attributes: ident Optional. A unique identifier for the Evidence element, see Section 3.2.9.. restriction Optional. Indicates restriction level that should be applied to element's data by Incident Handling System. Rank Keyword Description ---- ------- ----------- 0 default Restriction level is defined by external policy applied to overall CSIRT process 1 public No restriction is applied to element 2 internal Data is for company's (or constituency) internal use 3 restricted Use strictly for Incident managers at CSIRT 4.2.7.10 The EvidenceData Class The EvidenceData class contains evidence data of different kinds related to current Incident, including textual information (logfiles, malicious scripts, list of changes if file system, etc.) and binary (disc images, etc.). Yixian Yang, et al. Expires May, 2004 [Page 45] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 +------------------+ | Evidence | +------------------+ /_\ | +------------------+ | EvidenceData | +------------------+ 0..1 +----------------+ | STRING ident |<>----------| IncidentID | | ENUM restriction | +----------------+ | | 0..* +----------------+ | |<>----------| CorrEvidenceID | | | +----------------+ | | 0..1 +----------------+ | |<>----------| External | | | +----------------+ | | +----------------+ | |<>----------| Data | | | +----------------+ +------------------+ Figure 4.18 The EvidenceData Class The aggregate classes that constitute Classification are: IncidentID Zero or one. A unique identifier for the Incident, the value is equal to IncidentID attribute of Incident class. CorrEvidenceID Zero or more. EvidenceID of the Evidence class that contains Evidence data correlated with current Evidence data. External Zero or one. Contains link or path to externally stored Evidence data. Data Exactly one. Container for the Evidence data. This is represented in the XML DTD as follows: Yixian Yang, et al. Expires May, 2004 [Page 46] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 The EvidenceData class has two attributes: ident Optional. A unique identifier for this source, see Section 3.2.9.. restriction Optional. Indicates restriction level that should applied to element's data by Incident Handling System. Rank Keyword Description ---- ------- ----------- 0 default Restriction level is defined by external policy applied to overall CSIRT process 1 public No restriction is applied to element 2 internal Data is for company's (or constituency) internal use 3 restricted Use strictly for Incident managers at CSIRT 5. Extending the SCIMF As intrusion detection systems evolve, the SCIMF data model and DTD will have to evolve along with them. To allow new features to be added as they are developed, both the data model and the DTD can be extended as described in this section. As these extensions mature, they can then be incorporated into future versions of the specification. 5.1 Extending the Data Model There are two mechanisms for extending the SCIMF data model, inheritance and aggregation: + Inheritance denotes a superclass/subclass type of relationship where the subclass inherits all the attributes, operations, and relationships of the superclass. This type of relationship is also called a "is-a" or "kind-of" relationship. Subclasses may have additional attributes or operations that apply only to the subclass, and not to the superclass. + Aggregation is a form of association in which the whole is related to its parts. This type of relationship is also referred to as a "part-of" relationship. In this case, the aggregate class contains all of its own attributes and as many of the attributes associated with its parts as required and specified by occurrence indicators. Of the two mechanisms, inheritance is preferred, because it preserves the existing data model structure and also preserves the operations (methods) executed on the classes of the structure. Yixian Yang, et al. Expires May, 2004 [Page 47] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Note that the rules for extending the XML DTD (see below) set limits on the places where extensions to the data model may be made. 5.2 Extending the XML DTD There are two ways to extend the SCIMF XML DTD: 1. The AdditionalData class (see Section 4.2.4.6) allows implementors to include arbitrary "atomic" data items (integers, strings, etc.)in an Alert or Heartbeat message. This approach SHOULD be used whenever possible. See Sections 7.4 and 7.6. 2. The AdditionalData class allows implementors to extend the XML DTD with additional DTD "modules" that describe arbitrarily complex data types and relationships. The remainder of this section describes this extension method. To extend the SCIMF DTD with a new DTD "module," the following steps MUST be followed: 1. The SCIMF message MUST include a document type declaration (see Section 3.1.1.3). 2. The document type declaration MUST define a parameter entity (see Section A.2.4) that contains the location of the extension DTD, and then reference that entity: %x-extension; ]> In this example, the "x-extension" parameter entity is defined and then referenced, causing the DTD for the extension to be read by the XML parser. The name of the parameter entity defined for this purpose MUST be a string beginning with "x-"; there are no other restrictions on the name (other than those imposed on all entity names by XML). Multiple extensions may be included by defining multiple entities and referencing them. For example: %x-extension; %x-another; ]> Yixian Yang, et al. Expires May, 2004 [Page 48] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 3. Extension DTDs MUST declare all of their elements and attributes in a separate XML namespace. Extension DTDs MUST NOT declare any elements or attributes in the "SCIMF" or default namespaces. For example, the "test" extension might be declared as follows: 4. Extensions MUST only be included in SCIMF alert and heartbeat messages under an element whose "type" attribute contains the value "xml". For example: ... ... ... ... 6. Special Considerations This section discusses some of the special considerations that must be taken into account by implementors of the SCIMF. Yixian Yang, et al. Expires May, 2004 [Page 49] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 6.1 XML Validity and Well-Formedness It is expected that SCIMF-compliant applications will not normally include the SCIMF DTD itself in their communications. Instead, the DTD will be referenced in the document type declaration in the SCIMF message (see Section 3.1.1.3). Such SCIMF documents will be well-formed and valid as defined in [1]. Other SCIMF documents will be specified that do not include the document prolog (e.g., entries in an SCIMF-format database). Such SCIMF documents will be well-formed but not valid. Generally, well-formedness implies that a document has a single element that contains everything else (e.g., ""), and that all the other elements nest nicely within each other without any overlapping (e.g., a "chapter" does not start in the middle of another "chapter"). Validity further implies that not only is the document well-formed, but it also follows specific rules (contained in the Document Type Definition) about which elements are "legal" in the document, how those elements nest within other elements, and so on (e.g., a "chapter" does not begin in the middle of a "title"). A document cannot be valid unless it references a DTD. XML processors are required to be able to parse any well-formed document, valid or not. The purpose of validation is to make the processing of that document (what's done with the data after it's parsed) easier. Without validation, a document may contain elements in nonsense order, elements "invented" by the author that the processing application doesn't understand, and so forth. SCIMF documents MUST be well-formed. SCIMF documents SHOULD be valid whenever both possible and practical. 6.2 Unrecognized XML Tags On occasion, an SCIMF-compliant application may receive a well-formed, or even well-formed and valid, SCIMF message containing tags that it does not understand. The tags may be either: + Recognized as "legitimate" (a valid document), but the application does not know the semantic meaning of the element's content; or + Not recognized at all. SCIMF-compliant applications MUST continue to process SCIMF messages that contain unknown tags, provided that such messages meet the well-formedness requirement of Section 6.1. It is up to the individual application to decide how to process (or ignore) any content from the unknown elements(s). Yixian Yang, et al. Expires May, 2004 [Page 50] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 6.3 Alertmaker-Manager Time Synchronization Synchronization of time-of-day clocks between alertmakers and managers is outside the scope of this document. However, the following comments and suggestions are offered: 1. Whenever possible, all alertmakers and managers should have their time-of-day clocks synchronized to an external source such as NTP or SNTP [13, 14], GPS/GOES/WWV clocks, or some other reliable time standard. 2. When external time synchronization is not possible, the SCIMF provides the element, which may be used to perform rudimentary time synchronization (see below). 3. SCIMF-compliant applications SHOULD permit the user to enable/disable the method of time synchronization as a configuration option. 1. works best in a "flat" environment where alertmakers report up to a single level of managers. When a tree topology of high-level managers, intermediate relays, and alertmakers is used, the problem becomes more complex. 2. When intermediate message relays (managers or otherwise) are involved, two scenarios are possible: a. The intermediaries may forward entire SCIMF messages, or may perform aggregation or correlation, but MUST NOT inject delay. In this case, time synchronization is end-to-end between the alertmaker and the highest-level manager. b. The intermediaries may inject delay, due to storage or additional processing. In this case, time synchronization MUST be performed at each hop. This means each intermediary must decompose the SCIMF message, adjust all time values, and then reconstruct the message before sending it on. 3. When the environment is mixed, with some alertmakers and managers using external time synchronization and some not, all managers and intermediaries must perform synchronization. This is because determining whether or not compensation is actually needed between two parties rapidly becomes very complex, and requires knowledge of other parts of the topology. 4. If an alert can take alternate paths, or be stored in multiple locations, the recorded times may be different depending on the path taken. The above being said, synchronization is probably still better than nothing in many environments. To implement this type of synchronization, the following procedure is suggested: Yixian Yang, et al. Expires May, 2004 [Page 51] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 1. When an alertmaker or manager sends an SCIMF message, it should place the current value of its time-of-day clock in an element. This should occur as late as possible in the message transmission process, ideally right before the message is "put on the wire." 2. When a manager receives an SCIMF message, it should compute the difference between its own time-of-day clock and the time in the element of the message. This difference should then be used to adjust the times in the and elements (NTP timestamps should also be adjusted). 3. If the manager is an intermediary and sends the SCIMF message on to a higher-level manager, and hop-by-hop synchronization is in effect, it should regenerate the value to contain the value of its own time-of-day clock. 6.4 NTP Timestamp Wrap-Around From [7]: Note that, since some time in 1968 (second 2,147,483,648) the most significant bit (bit 0 of the integer part) has been set and that the 64-bit field will overflow some time in 2036 (second 4,294,967,296). Should NTP or SNTP be in use in 2036, some external means will be necessary to qualify time relative to 1900 and time relative to 2036 (and other multiples of 136 years). There will exist a 200-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable timestamp. SCIMF-compliant applications MUST NOT send a zero-valued NTP timestamp unless they mean to indicate that it is invalid or unavailable. If an SCIMF-compliant application must send an SCIMF message at the time of rollover, the application should wait for 200 picoseconds until the timestamp will have a non-zero value. Also from [7]: As the NTP timestamp format has been in use for the last 17 years, it remains a possibility that it will be in use 40 years from now when the seconds field overflows. As it is probably inappropriate to archive NTP timestamps before bit 0 was set in 1968, a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036-2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036. Yixian Yang, et al. Expires May, 2004 [Page 52] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Note that when calculating the correspondence, 2000 is not a leap year. Note also that leap seconds are not counted in the reckoning. SCIMF-compliant applications in use after 2036-02-07T06:28:16Z MUST adhere to the above convention. 6.5 Digital Signatures Standard XML digital signature processing rules and syntax are specified in [12]. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. The SCIMF requirements document [9] assigns responsibility for message integrity and authentication to the communications protocol, not the message format. However, in situations where SCIMF messages are exchanged over other, less secure protocols, or in cases where the digital signatures must be archived for later use, the inclusion of digital signatures within an SCIMF message itself may be desirable. Specifications for the use of digital signatures within SCIMF messages are outside the scope of this document. However, if such functionality is needed, use of the XML Signature standard is RECOMMENDED. 7. Experimental implementation and examples There is ongoing project among few experiments to implement SCIMF in the daily incident handling work. Results is believed to be available late 2004 year. There may be some other early implementations using SCIMF rather as a general concept for defining data structure. Those implementations must not be treated as valid SCIMF implementations. This section will provide examples of how the SCIMF is used to encode Incident data. The examples will be provided for illustrative purposes only, and will not necessarily represent the only (or even the "best") way to encode these particular alerts). 7.1 Heartbeat This example shows a heartbeat message that provides "I'm alive and working" information to the manager. Note the use of elements, with "meaning" attributes, to provide Yixian Yang, et al. Expires May, 2004 [Page 53] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 some additional information. Headquarters DMZ Network alertmaker01.example.com 2000-03-09T14:07:58Z 62.5 87.1 7.2 XML Extension The following example shows how to extend the SCIMF DTD with XML. In the example, the VendorCo company has decided it wants to add geographic information to the Node class. To do this, VendorCo creates a Document Type Definition that defines how their class will be formatted: 8. The SCIMF Document Type Definition Yixian Yang, et al. Expires May, 2004 [Page 54] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Yixian Yang, et al. Expires May, 2004 [Page 55] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Yixian Yang, et al. Expires May, 2004 [Page 56] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Yixian Yang, et al. Expires May, 2004 [Page 57] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Yixian Yang, et al. Expires May, 2004 [Page 58] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Yixian Yang, et al. Expires May, 2004 [Page 59] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Yixian Yang, et al. Expires May, 2004 [Page 60] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 9. Security Considerations This Internet-Draft describes a data representation for exchanging security-related information between intrusion detection system implementations. Although there are no security concerns directly applicable to the format of this data, the data itself may contain security-sensitive information whose confidentiality, integrity, and/or availability may need to be protected. This suggests that the systems used to collect, transmit, process, and store this data should be protected against unauthorized use, and that the data itself should be protected against unauthorized access. The means for achieving this protection are outside the scope of this document. Section 5 of [9] describes the required and recommended security characteristics of the transmission protocol that will be used to deliver SCIMF data from alertmakers to managers. These requirements include message confidentiality, message integrity, non-repudiation, and avoidance of duplicate messages. Both standard and proposed protocols exist that provide these features. Where a protocol that does not meet the requirements of Section 5 of [9] is used to exchange SCIMF messages, it may be desirable to use digital signatures to certify the integrity of these messages; this is discussed in Section 6.5 of this document. 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Arvidsson, J., Cormack, A., Demchenko, Y., Meijer J. "TERENA's Incident Object Description and Exchange Format Requirements", RFC 3067, February 2001 [3] Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition by D. Curry - September 2003 - http://www.ietf.org/internet-drafts/ draft-ietf-idwg-IDMEF-xml-10.txt. [4] Taxonomy of the Computer Security Incident related terminology - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/ i-taxonomy_terms.html Yixian Yang, et al. Expires May, 2004 [Page 61] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 [5] World Wide Web Consortium (W3C), "Extensible Markup Language (XML) 1.0 (Second Edition)," W3C Recommendation, November 6, 2000. http://www.w3.org/TR/2000/REC-xml-20001006. [6] World Wide Web Consortium (W3C), "Namespaces in XML," W3C Recommendation, January 14, 1999. http://www.w3.org/TR/1999/ REC-xml-names-19990114. [7] XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001. http://www.w3.org/TR/xmlschema-0/. [8] Berners-Lee, T., Fielding, R.T., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, August 1998. [9] Mealling, M., "The IANA XML Registry," draft-mealling-iana- xmlns-registry-00.txt, November 17, 2000, work in progress. [10] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling Language Reference Model," ISBN 020130998X, Addison-Wesley, 1998. [11] Freed, N., "IANA Charset Registration Procedures," BCP 19, RFC 2278, January 1998. [12] Alvestrand, H., "Tags for the Identification of Languages," RFC 3066, BCP 47, January 2001. [13] International Organization for Standardization (ISO), "International Standard: Data elements and interchange formats - Information interchange - Representation of dates and times," ISO 8601, Second Edition, December 15, 2000. [14] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation, and Analysis," RFC 1305, March 1992. [15] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI," RFC 2030, November 1996. [16] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature Syntax and Processing," draft-ietf-xmldsig-core-11.txt, November 1, 2000, work in progress. [17] World Wide Web Consortium (W3C), "Extensible Markup Language (XML) 1.0 (Second Edition)," W3C Recommendation, November 6, 2000. http://www.w3.org/TR/2000/REC-xml-20001006. [18] World Wide Web Consortium (W3C), "Namespaces in XML," W3C Recommendation, January 14, 1999. http://www.w3.org/TR/1999/ REC-xml-names-19990114. [19] Berners-Lee, T., Fielding, R.T., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, August Yixian Yang, et al. Expires May, 2004 [Page 62] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 1998. [20] Alvestrand, H., "Tags for the Identification of Languages," RFC 3066, BCP 47, January 2001. [21] International Organization for Standardization (ISO), "International Standard: Data elements and interchange formats -Information interchange - Representation of dates and times," ISO 8601, Second Edition, December 15, 2000. [22] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation, and Analysis," RFC 1305, March 1992. [23] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI," RFC 2030, November 1996. 11. Acknowledgements Author credit a lot support and contribution received from Jie Zhang, and other members of Beijing University of Posts and Telecom. The authors wish to thank Huiqin Lv, Yafei Yang, Zhansong Wei, Ning An, and Weimin Shi,for their detailed inputs. 12. Authors Address: Yixian Yang Information Security Center, Beijing University of posts and telecom.(BUPT), Beijing, China,100876 Phone:8610-62283366 Email:yxyang@bupt.edu.cn Yixian Yang, et al. Expires May, 2004 [Page 63] INTERNET-DRAFT SCIMF Data Model & DTD November, 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). 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 DISCLAIMS 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Yixian Yang, et al. Expires May, 2004 [Page 64]