One document matched: draft-yang-scimf-xml-00.txt
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:
<!DOCTYPE SCIMF-Message PUBLIC
"-//IETF//DTD RFC XXXX SCIMF v1.0//EN">
The last component of the document type declaration is the formal
public identifier (FPI) specified in the previous section.
<!DOCTYPE SCIMF-Message SYSTEM
"/some/path/to/the/SCIMF-message.dtd">
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:
<!ENTITY % attlist.SCIMF "
version CDATA #FIXED '1.0'
">
<!ELEMENT SCIMF-Message (
(Alert | Heartbeat | Command)*
)>
<!ATTLIST SCIMF-Message
%attlist.SCIMF;
>
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:
<!ELEMENT Heartbeat (
Alertmaker, CreateTime, AlertmakerTime?, AdditionalData*
)>
<!ATTLIST Heartbeat
ident CDATA '0'
>
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:
<!ELEMENT Alert
(
Yixian Yang, et al. Expires May, 2004 [Page 21]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
Alertmaker, CreateTime, DetectTime?, AlertmakerTime?,Source*,
Target*, Classification+, Assessment?, (ToolAlert |
OverflowAlert | CorrelationAlert)?, AdditionalData*
)>
<!ATTLIST Alert
ident CDATA '0'
>
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:
<!ELEMENT Command (
CommandTime?, Source, Target, Parameter, AdditionalData*
)>
<!ATTLIST Command
ident CDATA '0'
name CDATA #IMPLIED
>
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:
<!ELEMENT Parameter (
Cost*, Time*, Result?, Certificate*, Update?, AdditionalData*
)>
<!ATTLIST Alert
ident CDATA '0'
type CDATA #IMPLIED
number CDATA #IMPLIED
content CDATA #IMPLIED
>
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:
<!ENTITY % attvals.yesno "
( unknown | yes | no )
">
<!ELEMENT Source (
Node?, User?, Process?, Service?
)>
<!ATTLIST Source
Yixian Yang, et al. Expires May, 2004 [Page 27]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
ident CDATA '0'
spoofed %attvals.yesno; 'unknown'
interface CDATA #IMPLIED
>
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:
<!ENTITY % attvals.yesno "
( unknown | yes | no )
">
<!ELEMENT Target (
Node?, User?, Process?, Service?, FileList?
)>
<!ATTLIST Target
ident CDATA '0'
decoy %attvals.yesno; 'unknown'
interface CDATA #IMPLIED
>
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:
<!ELEMENT Alertmaker (
Node?, Process?
)>
<!ATTLIST Alertmaker
alertmakerid CDATA '0'
manufacturer CDATA #IMPLIED
model CDATA #IMPLIED
version CDATA #IMPLIED
class CDATA #IMPLIED
ostype CDATA #IMPLIED
osversion CDATA #IMPLIED
>
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:
<!ENTITY % attvals.adtype "
( boolean | byte | character | date-time | integer |
ntpstamp | portlist | real | string | xml )
">
<!ELEMENT AdditionalData ANY >
<!ATTLIST AdditionalData
type %attvals.adtype; 'string'
meaning CDATA #IMPLIED
>
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:
<!ELEMENT CommandTime (
CreateTime) >
<!ATTLIST CommandTime
ntpstamp CDATA #DEMAND
>
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:
<!ELEMENT CreateTime (#PCDATA) >
<!ATTLIST CreateTime
ntpstamp CDATA #REQUIRED
>
The DATETIME format of the <CreateTime> 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:
<!ENTITY % attvals.nodecat "
( unknown | ads | afs | coda | dfs | dns | hosts | kerberos |
nds | nis | nisplus | nt | wfw )
">
<!ELEMENT Node (
location?, (name | Address), Address*
)>
<!ATTLIST Node
ident CDATA '0'
category %attvals.nodecat; 'unknown'
>
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:
<!ENTITY % attvals.usercat "
( unknown | application | os-device )
">
<!ELEMENT User (
UserId+
)>
<!ATTLIST User
ident CDATA '0'
category %attvals.usercat; 'unknown'
>
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:
<!ELEMENT Process (
name, pid?, path?, arg*, env*
)>
<!ATTLIST Process
ident CDATA '0'
>
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:
<!ELEMENT Service (
(((name, port?) | (port, name?)) | portlist), protocol?,
SNMPService?, WebService?
)>
<!ATTLIST Service
ident CDATA '0'
>
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:
<!ENTITY % attvals.origin "
( unknown | bugtraqid | cve | vendor-specific )
">
<!ELEMENT Classification (
name, url
)>
<!ATTLIST Classification
origin %attvals.origin; 'unknown'
>
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:
<!ELEMENT Alertpath (
Address)>
<!ATTLIST Alertpath
ident CDATA '0'
number CDATA '0'
category CDATA 'beginning'
>
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:
<!ELEMENT Certificate (
AdditionalData)>
<!ATTLIST Certificate
ident CDATA '0'
version CDATA '0'
Yixian Yang, et al. Expires May, 2004 [Page 42]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
authority CDATA '0'
serial CDATA '0'
date CDATA '0'
time CDATA '0'
crladdress CDATA '0'
>
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:
<!ELEMENT Cost (
AdditionalData)>
<!ATTLIST Cost
ident CDATA '0'
cpu CDATA '0'
mem CDATA '0'
time CDATA '0'
network CDATA '0'
pagefile CDATA '0'
>
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:
<!ENTITY % attvals.restriction "
( default | public | internal |
restricted )
">
<!ELEMENT Evidence (
EvidenceData*)>
<!ATTLIST Evidence
ident ID #IMPLIED
restriction %attvals.restriction; 'default'
>
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:
<!ENTITY % attvals.restriction "
( default | public | internal |
restricted )
">
<!ELEMENT EvidenceData (
IncidentID?, CorrEvidence*, External?, Data
)>
<!ATTLIST EvidenceData
origin %attvals.origin; 'unknown'
>
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:
<!DOCTYPE SCIMF-Message SYSTEM "/path/to/SCIMF-message.dtd" [
<!ENTITY % x-extension SYSTEM "/path/to/extension.dtd">
%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:
<!DOCTYPE SCIMF-Message SYSTEM "/path/to/SCIMF-message.dtd" [
<!ENTITY % x-extension SYSTEM "/path/to/extension.dtd">
<!ENTITY % x-another SYSTEM "/path/to/another.dtd">
%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:
<!ELEMENT test:test (
test:a, test:b, test:c
)>
<!ATTLIST test:test
xmlns CDATA #IMPLIED
xmlns:test CDATA #IMPLIED
>
<!ELEMENT test:a (#PCDATA)>
<!ATTLIST test:a
test:attr CDATA #IMPLIED
>
<!ELEMENT test:b (#PCDATA)>
<!ELEMENT test:c (#PCDATA)>
4. Extensions MUST only be included in SCIMF alert and heartbeat
messages under an <AdditionalData> element whose "type" attribute
contains the value "xml". For example:
<SCIMF-Message version="1.0">
<Alert ident="...">
...
<AdditionalData type="xml">
<test:test xmlns:test="http://www.ietf.org/test.html"
xmlns="http://www.ietf.org/test.html">
<test:a test:attr="...">...</test:a>
<test:b>...</test:b>
<test:c>...</test:c>
</test:test>
</AdditionalData>
</Alert>
</SCIMF-Message>
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., "<Book>"), 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 <AlertmakerTime> element, which may be used to
perform rudimentary time synchronization (see below).
3. SCIMF-compliant applications SHOULD permit the user to
enable/disable the <AlertmakerTime> method of time
synchronization as a configuration option.
1. <AlertmakerTime> 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 <AlertmakerTime> 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, <AlertmakerTime> 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
<AlertmakerTime> 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
<AlertmakerTime> element of the message. This difference should
then be used to adjust the times in the <CreateTime> and
<DetectTime> 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 <AlertmakerTime> 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
<AdditionalData> 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.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE SCIMF-Message PUBLIC "-//IETF//DTD RFC XXXX SCIMF v1.0//EN"
"SCIMF-message.dtd">
<SCIMF-Message version="1.0">
<Heartbeat ident="abc123456789">
<Alertmaker alertmakerid="hq-dmz-alertmaker01">
<Node category="dns">
<location>Headquarters DMZ Network</location>
<name>alertmaker01.example.com</name>
</Node>
</Alertmaker>
<CreateTime ntpstamp="0xbc722ebe.0x00000000">
2000-03-09T14:07:58Z
</CreateTime>
<AdditionalData type="real" meaning="%memused">
62.5
</AdditionalData>
<AdditionalData type="real" meaning="%diskused">
87.1
</AdditionalData>
</Heartbeat>
</SCIMF-Message>
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:
<!ELEMENT VendorCo:NodeGeography (
VendorCo:latitude, VendorCo:longitude, VendorCo:elevation?
)>
<!ATTLIST VendorCo:NodeGeography
xmlns CDATA #FIXED
'SCIMF+vendorco'
xmlns:VendorCo CDATA #FIXED
'SCIMF+vendorco'
VendorCo:node-ident CDATA #REQUIRED
>
<!ELEMENT VendorCo:latitude (#PCDATA) >
<!ELEMENT VendorCo:longitude (#PCDATA) >
<!ELEMENT VendorCo:elevation (#PCDATA) >
8. The SCIMF Document Type Definition
<?xml version="1.0" encoding="UTF-8"?>
Yixian Yang, et al. Expires May, 2004 [Page 54]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
<!--Security Components Interactive Message Format (SCIMF) XML
DTD Version 1.0, November 2003. The use and extension of the
SCIMF XML DTD are described in RFC XXXX, "Security Components
Interactive Messag Format Data Model and Extensible Markup Language
(XML) Document Type Definition," Yixian Yang.-->
<!--Attribute list declarations. -->
<!--
| Attributes of the SCIMF element. In general, the fixed values of
| these attributes will change each time a new version of the DTD
| is released.
-->
<!ENTITY % attlist.SCIMF "
version CDATA #FIXED '1.0'
">
<!--
| Attributes of all elements. These are the "XML" attributes that
| every element should have. Space handling, language, and name
| space.
-->
<!ENTITY % attlist.global "
xmlns:SCIMF CDATA #FIXED
'urn:iana:xml:ns:SCIMF'
xmlns CDATA #FIXED
'urn:iana:xml:ns:SCIMF'
xml:space (default | preserve) 'default'
xml:lang NMTOKEN #IMPLIED
">
<!--Attribute value declarations. Enumerated values for
many of the element-specific attribute lists.-->
<!--
| Values for the Action.category attribute.
-->
<!ENTITY % attvals.actioncat "
( block-installed | notification-sent | taken-offline | other )
">
<!--
| Values for the Address.category attribute.
-->
<!ENTITY % attvals.addrcat "
( unknown | atm | e-mail | lotus-notes | mac | sna | vm |
ipv4-addr | ipv4-addr-hex | ipv4-net | ipv4-net-mask |
ipv6-addr | ipv6-addr-hex | ipv6-net | ipv6-net-mask )
">
<!--
| Values for the AdditionalData.type attribute.
-->
Yixian Yang, et al. Expires May, 2004 [Page 55]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
<!ENTITY % attvals.adtype "
( boolean | byte | character | date-time | integer | ntpstamp |
portlist | real | string | xml )
">
<!--
| Values for the Impact.completion attribute.
-->
<!ENTITY % attvals.completion "
( failed | succeeded )
">
<!--
| Values for the File.category attribute.
-->
<!ENTITY % attvals.filecat "
( current | original )
">
<!--
| Values for the Id.type attribute.
-->
<!ENTITY % attvals.idtype "
( current-user | original-user | target-user | user-privs |
current-group | group-privs | other-privs )
">
<!--
| Values for the Impact.type attribute.
-->
<!ENTITY % attvals.impacttype "
( admin | dos | file | recon | user | other )
">
<!--
| Values for the Linkage.category attribute.
-->
<!ENTITY % attvals.linkcat "
( hard-link | mount-point | reparse-point | shortcut | stream |
symbolic-link )
">
<!--
| Values for the Node.category attribute.
-->
<!ENTITY % attvals.nodecat "
( unknown | ads | afs | coda | dfs | dns | hosts | kerberos |
nds | nis | nisplus | nt | wfw )
">
<!--
| Values for the Classification.origin attribute.
-->
Yixian Yang, et al. Expires May, 2004 [Page 56]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
<!ENTITY % attvals.origin "
( unknown | bugtraqid | cve | vendor-specific )
">
<!--
| Values for the Confidence.rating attribute.
-->
<!ENTITY % attvals.rating "
( low | medium | high | numeric )
">
<!--
| Values for the Impact.severity attribute.
-->
<!ENTITY % attvals.severity "
( low | medium | high )
">
<!--
| Values for the User.category attribute.
-->
<!ENTITY % attvals.usercat "
( unknown | application | os-device )
">
<!--
| Values for yes/no attributes such as Source.spoofed and
| Target.decoy.
-->
<!ENTITY % attvals.yesno "
( unknown | yes | no )
">
<!--Top-level element declarations. The SCIMF-Message element and
the types of messages it can include.-->
<!ELEMENT SCIMF-Message (
(Alert | Heartbeat|Command)*
)>
<!ATTLIST SCIMF-Message
%attlist.global;
%attlist.SCIMF;
>
<!ELEMENT Alert (
Alertmaker, CreateTime, DetectTime?, AlertmakerTime?, Source*,
Target*, Classification+, Assessment?, (ToolAlert |
OverflowAlert | CorrelationAlert)?, AdditionalData*
)>
<!ATTLIST Alert
ident CDATA '0'
%attlist.global;
>
Yixian Yang, et al. Expires May, 2004 [Page 57]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
<!ELEMENT Heartbeat (
Alertmaker, CreateTime, AlertmakerTime?, AdditionalData*
)>
<!ATTLIST Heartbeat
ident CDATA '0'
%attlist.global;
>
<!ELEMENT Command (
CommandTime?, Source, Target, Parameter, AdditionalData*
)>
<!ATTLIST Command
ident CDATA '0'
name CDATA #IMPLIED
>
<!ELEMENT AdditionalData ANY >
<!ATTLIST AdditionalData
type %attvals.adtype; 'string'
meaning CDATA #IMPLIED
%attlist.global;
>
<!ELEMENT Alertmaker (
Node?, Process?
)>
<!ATTLIST Alertmaker
Alertmakerid CDATA '0'
manufacturer CDATA #IMPLIED
model CDATA #IMPLIED
version CDATA #IMPLIED
class CDATA #IMPLIED
ostype CDATA #IMPLIED
osversion CDATA #IMPLIED
%attlist.global;
>
<!ELEMENT Source (
Node?, User?, Process?, Service?
)>
<!ATTLIST Source
ident CDATA '0'
spoofed %attvals.yesno; 'unknown'
interface CDATA #IMPLIED
%attlist.global;
>
<!ELEMENT Target (
Node?, User?, Process?, Service?, FileList?
)>
Yixian Yang, et al. Expires May, 2004 [Page 58]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
<!ATTLIST Target
ident CDATA '0'
decoy %attvals.yesno; 'unknown'
interface CDATA #IMPLIED
%attlist.global;
>
<!ELEMENT Classification (
name, url
)>
<!ATTLIST Classification
origin %attvals.origin; 'unknown'
%attlist.global;
>
<!ELEMENT Node (
location?, (name | Address), Address*
)>
<!ATTLIST Node
ident CDATA '0'
category %attvals.nodecat; 'unknown'
%attlist.global;
>
<!ELEMENT Process (
name, pid?, path?, arg*, env*
)>
<!ATTLIST Process
ident CDATA '0'
%attlist.global;
>
<!ELEMENT Service (
(((name, port?) | (port, name?)) | portlist), protocol?,
SNMPService?, WebService?
)>
<!ATTLIST Service
ident CDATA '0'
%attlist.global;
>
<!ELEMENT User (
UserId+
)>
<!ATTLIST User
ident CDATA '0'
category %attvals.usercat; 'unknown'
%attlist.global;
>
Yixian Yang, et al. Expires May, 2004 [Page 59]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
<!ELEMENT AlertmakerTime (#PCDATA) >
<!ATTLIST AlertmakerTime
ntpstamp CDATA #REQUIRED
%attlist.global;
>
<!ELEMENT CreateTime (#PCDATA) >
<!ATTLIST CreateTime
ntpstamp CDATA #REQUIRED
%attlist.global;
>
<!ELEMENT command (#PCDATA) >
<!ATTLIST command
%attlist.global;
>
<!ELEMENT name (#PCDATA) >
<!ATTLIST name
%attlist.global;
>
<!ELEMENT netmask (#PCDATA) >
<!ATTLIST netmask
%attlist.global;
>
<!ELEMENT number (#PCDATA) >
<!ATTLIST number
%attlist.global;
>
<!ELEMENT path (#PCDATA) >
<!ATTLIST path
%attlist.global;
>
<!ELEMENT port (#PCDATA) >
<!ATTLIST port
%attlist.global;
>
<!ELEMENT portlist (#PCDATA) >
<!ATTLIST portlist
%attlist.global;
>
<!ELEMENT protocol (#PCDATA) >
<!ATTLIST protocol
%attlist.global;
>
Yixian Yang, et al. Expires May, 2004 [Page 60]
INTERNET-DRAFT SCIMF Data Model & DTD November, 2003
<!ELEMENT url (#PCDATA) >
<!ATTLIST url
%attlist.global;
>
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:13 |