Security Area B.-C. Boesch
Internet Draft independent
Intended status: Experimental January 12, 2015
Expires: July 2015
Intrusion Detection Parameterization Exchange Format (IDPEF)
draft-boesch-idxp-idpef-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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."
Boesch Expires July 12, 2015 [Page 1]
Internet-Draft The IDPEF January 2015
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 12, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
The Intrusion Detection Parameterization Exchange Format (IDPEF)
defines data formats and exchange procedures to standardize
parameterization information exchange into intrusion detection and
response systems from a Manager to an Analyzer.
This Internet-Draft describes a data model to represent
parameterization information of intrusion detection system entities,
and explains the rationale for using this model. An implementation of
the data model in the Extensible Markup Language (XML) is presented,
a XML Document Type Definition is developed, and parameterization
examples are provided.
Boesch Expires July 12, 2015 [Page 2]
Internet-Draft The IDPEF January 2015
Table of Contents
1. Introduction ................................................ 5
1.1. Structure of this Document .............................. 6
1.2. Rationale for IDPEF ..................................... 6
1.2.1. Problems Addressed by the Parameterization Data Model7
1.2.2. Data Model Design Focus ............................ 8
1.3. Architecture Assumptions ................................ 8
1.4. Focus of Format........................................ 10
1.5. Parameterization Methodology ........................... 10
2. The Communication Proceeding ................................ 11
2.1. Parameterization Communication ......................... 11
2.2. Version Update on Hierarchical Lower IDS-Entities ....... 12
3. The IDPEF XML Implementation ................................ 13
3.1. Notational Conventions and Formatting Issues ........... 14
3.2. IDPEF XML Documents .................................... 14
3.2.1. The Document Header - The XML Declaration.......... 14
3.2.2. Character Data Processing in IDPEF ................ 15
3.2.3. Languages in IDPEF ................................ 15
3.3. IDPEF Data Types ....................................... 15
3.4. Case-sensitivity ....................................... 16
4. The IDPEF Parameterization Data Model ....................... 16
4.1. Overview .............................................. 16
4.2. Message Nodes ......................................... 17
4.2.1. IDPEF-Message ..................................... 17
4.2.2. The Entity Section ................................ 19
4.2.2.1. network ...................................... 22
4.2.2.2. address ...................................... 23
4.2.2.3. location ..................................... 24
4.2.2.4. contact ...................................... 25
4.2.2.5. fservice ..................................... 26
4.2.2.6. tadmin ....................................... 27
4.2.3. The Update Section ................................ 27
4.2.3.1. update-file .................................. 29
4.2.3.2. data ........................................ 30
4.2.4. The Alert Section ................................. 30
4.2.4.1. group........................................ 31
4.2.4.1.1. event ................................... 31
4.2.4.1.1.1. connection ......................... 34
4.2.4.1.1.2. system ............................. 35
4.2.4.1.1.3. ipara .............................. 36
4.2.4.1.2. react ................................... 37
5. Extending the IDPEF ........................................ 38
6. Special Considerations ...................................... 38
6.1. XML Validity and Well-Formalness ....................... 38
6.2. Unrecognized XML Tags .................................. 39
Boesch Expires July 12, 2015 [Page 3]
Internet-Draft The IDPEF January 2015
7. Security Considerations ..................................... 39
7.1. Systems Security Issues ................................ 39
7.2. Communications Security Issues ......................... 40
7.2.1. Passive Attacks ................................... 40
7.2.1.1. Confidentiality Violations (Eavesdropping) .... 40
7.2.1.2. Password Sniffing ............................ 40
7.2.1.3. Offline Cryptographic Attacks ................ 41
7.2.2. Active Attacks .................................... 41
7.2.2.1. Replay Attacks ............................... 41
7.2.2.2. Message Insertion ............................ 41
7.2.2.3. Message Deletion ............................. 41
7.2.2.4. Message Modification ......................... 41
7.2.2.5. Man-In-The-Middle ............................ 42
7.2.3. Topological Issues ................................ 42
7.2.4. Denial of Service ................................. 42
7.3. Digital Signatures ..................................... 42
8. IANA Considerations ........................................ 42
9. Conclusions ................................................ 43
10. Acknowledgments ........................................... 43
Appendix A Examples .......................................... 44
A.1. Feature-Requests ....................................... 44
A.1.1. Global Feature-Request ............................ 44
A.1.2. Entity Feature-Request ............................ 44
A.1.3. Single Attribute Request .......................... 44
A.1.4. Single Alert-Request (Port-Scan) .................. 45
A.1.5. Multiple Alert Request ............................ 45
A.1.6. Global Alert-Request .............................. 46
A.2. Feature-Replies........................................ 46
A.2.1. Global Feature-Reply .............................. 46
A.2.2. Version-Reply ..................................... 50
A.2.3. Single Alert Feature-Reply (Port-Scan) ............ 51
A.3. Entity Information Update .............................. 52
A.4. Analyzer-Update........................................ 54
A.4.1. Single Update ..................................... 55
A.4.2. Multiple Updates and Notifications ................ 55
A.4.3. Single Backup-Request ............................. 57
A.4.4. Single Backup-Reply ............................... 57
A.4.5. Single Backup-Restore ............................. 58
A.5. Alert Parameterization ................................. 59
A.5.1. Single Parameter-Update (Port-Scan) ............... 59
A.5.2. Multiple Parameter Update ......................... 60
Appendix B The IDPEF Document Type Definition (Normative) ...... 62
Appendix C The IDPEF Schema Definition (Non-normative) ......... 77
11. References ............................................... 100
11.1. Normative References ................................. 100
11.2. Informative References ............................... 101
Intellectual Property Statement ............................... 101
Boesch Expires July 12, 2015 [Page 4]
Internet-Draft The IDPEF January 2015
C.1.1. Authors' Addresses ............................... 102
1. Introduction
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [1].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
1.1. Intention of this Format
The Intrusion Detection Parameterization Exchange Format (IDPEF) is
intended to be a standard data format to parameterize Intrusion
Detection Systems (IDS). The development of this standardized format
and the Intrusion Detection Message Exchange Format (IDMEF) [2] will
be enable in combination 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 IDS implementation.
The most obvious place to implement IDPEF is in the data channel
between a Manager and an Analyzer of an IDS within this data channel
where the Manager sends the configuration parameters to the
Analyzers. But there are other places where the IDPEF can be useful:
o Combination of specialized IDS like application-IDS with server-
IDS, WLAN-IDS and network-IDS to one functional interacting meta-
IDS.
o Management of different IDS vendors with one central management
interface.
o Interaction of different IDS by using IDPEF and IDMEF.
Boesch Expires July 12, 2015 [Page 5]
Internet-Draft The IDPEF January 2015
o A common data exchange format would make it easier for different
organizations (users, vendors, response teams) to not only
exchange data, but also communicate about it.
o The diversity of uses for the IDPEF needs to be considered when
selecting its method of implementation.
o Parameterization backups and restore of parameterized IDS
entities.
o For a communication between a Manager and a Manager in a multi-
stage management architecture.
1.2. Structure of this Document
The remaining paper is organized as follows: The rest of section 1 is
focused on the problems that will be addressed by IDPEF,
architectural assumptions and the parameterization methodology.
Section 2 defines basic communication procedures. General XML
conventions for IDPEF are set out in section 3. The IDPEF data model
and its nodes including each single attribute are defined in section
4. Extending of IDPEF and special considerations are set out in the
sections 5 and 6. Subsequent the section 7 to 10 include IANA
considerations, a short conclusion and acknowledgements.
Appendix A provides some examples for IDPEF so that unfamiliar
readers are able to understand this document better. Appendix B shows
the DTD of IDPEF and a non-normative XML Schema Definition of IDPEF
is set out in Appendix C.
1.3. Rationale for IDPEF
Methods of hacking are changing over periods of time and become more
and more complex. As a result of this, techniques are developed to
raise interoperability of IDS. One part is a standardized signalizing
format to collect event messages of different IDS-entities. So the
Intrusion Detection Exchange Format Working Group (IDWG) has
standardized the communication between Analyzer and Manager with the
Intrusion Detection eXchange Protocol (IDXP) [4]. As data format for
events from Analyzer to Manager the Intrusion Detection Message
Exchange Format (IDMEF) [2] was defined.
Today, IDS are operating in encapsulated IT-landscapes. Many vendors
provide IDS-functionalities in their network-components or
applications and IDS-vendors focus their intrusion detection products
to special services. Vendor-dependent tools and configurations are
needed for administration. This is a big barrier of an extensive IDS-
Boesch Expires July 12, 2015 [Page 6]
Internet-Draft The IDPEF January 2015
integration in complex environments. It is important to standardize
the communication between Manager and Analyzer for administration and
operations, to combine IDS-Analyzers and Sensors of different vendors
and integrate them into one IDS.
Continuative of IDMEF, an exchange format for administration of IDS
has to standardize the communication from Manager to Analyzer. As
result a fully standardized communication between Managers and
Analyzers enhance interoperability and integration of different IDS.
As result, management front ends will become independent to IDS-
Analyzers.
1.3.1. Problems Addressed by the Parameterization Data Model
The data model addresses several problems associated with
representing intrusion detection parameters:
o Potential intrusion detection environments are very different. IDS
are more and more specialized. Some Analyzers detect attacks by
analyzing network traffic; others use operating system logs or
application audit trail information. The combination of different
specialized IDS, different vendors and/or analyzing techniques
will be more and more important. Interaction of different IDS
and/or vendors is not trivial, because parameterization
information and formats are vendor-specific. The data model that
represents different parameterization information MUST be highly
standardized, but has to be also so flexible to support different
needs of Analyzers and vendors.
o Large enterprises have several security specialists with different
focuses. The working focus of these security specialists requires
different competences. Organizational upper security groups make
regulations for their work. These groups have to handle different
configuration structures today. So a standardized parameterization
format makes it easier to exchange working results between IDS
security specialists with different vendor focus.
o Administrators are working with several specialized IDS-
parameterization interfaces, sometimes distributed on separate
systems. A standardized parameterization format helps to develop
independent and consistent administration interfaces on one
hardware platform. Administrators are then able to parameterize
IDS of different vendors and analyzing level by using one
administration interface. As result, the best administration
interface for the operation focus could be selected.
Boesch Expires July 12, 2015 [Page 7]
Internet-Draft The IDPEF January 2015
o A standardized communication allows combining several vendors and
IDS-entities to operate like one IDS. The best fitting Analyzer
will be integrated in the solution.
o Research prototypes and specialized IDS like VoIP-IDS are able to
be better integrated in existing IDS-architectures. Research
results are better portable and interoperability of dedicate
research-projects, like IDS management usability, alert
correlations or automated signature generation [14], will be
enhanced.
1.3.2. Data Model Design Focus
The data model is designed to provide standardized parameterization
for IDS entities. Together with IDMEF it allows to combine IDS-
entities of different vendors to one meta-IDS.
IDPEF provide a closed solution together with IDMEF. Therefore IDPEF
provide at least parameters that are necessary for IDMEF.
The data model design is focused on several IDS entities, their
individual parameter structure and the feature set.
Structure and format of the data model MUST be unambiguous. The
information parameter to an event varies by the event itself and its
characterizing parameters. For example, port-scans or ICMP-floods
need a time-interval and a quantity of packets (port-request resp.
icmp-packets) to characterize an intrusion. Also the event-name
varies from vendor to vendor and it SHOULD be directly set as
parameter value. Parameters of an Analyzer are individual and have to
be requested by a general parameter request.
This work is focused to standardize parameterization data and format
to enhance the interoperability of IDS.
1.4. Architecture Assumptions
Figure 1 is an enhanced illustration of functional IDS-entities. It
illustrates the intrusion detection entities as defined in [3] and
their relationships. Not every IDS will have all of these separate
entities exactly as shown. Some IDS combine these components into a
single module; some will have multiple instances of single modules.
Based on a Data Source the Activity will be recognized and the Sensor
examines necessary Event information and sends it to the Analyzer.
The Analyzer checks the Event information against his Security
Policy. The Manager is the entity, which act as single point of
Boesch Expires July 12, 2015 [Page 8]
Internet-Draft The IDPEF January 2015
administration for the system. It provides the Security Policy,
receives the Event notifications and coordinates Response entities
which could be external to the identifying Analyzer.
+----------+
|DataSource|----+--Activity------+
+----------+ | |
A V V
| +------+ +------+
Reaction |Sensor| |Sensor|
| +------+ +------+
| | A | A
| Event | Event |
| | Config | Config
| V | V |
| +--------+ +--------+
| |Analyzer| |Analyzer|
| +--------+ +--------+
| | A A |
+--------+ | | | |
|Response| IDMEF IDPEF IDPEF IDMEF
+--------+ | +-+-------+-+ |
A +----->|Manager|<------+
+--------------+-------+
A | A
+---------------+ | |
| | |
+--------+ | | +-------------+
|Operator|<-Notify--+ +----|Administrator|
+--------+ Security +-------------+
| Policy A
| |
+--Security Process-------------+
Figure 1 Relationship of IDS entities.
For the purposes of this document, we assume that the Analyzer and
the Manager are separate components, and that they are communicating
pair wise across a TCP/IP network. No other form of communication
between these entities is contemplated in this document, and no other
use of IDPEF is considered. As transport protocol for IDPEF the IDXP
[4] will be used.
The following points SHOULD NOT matter for the integration:
o Whether Sensor and Analyzer are integrated or separated.
Boesch Expires July 12, 2015 [Page 9]
Internet-Draft The IDPEF January 2015
o Whether Analyzer and Manager are isolated, or embedded in some
large hierarchy or distributed mesh of components.
o Whether the Manager is used for configuration only or additionally
used for notification and/or alert-correlation.
o Whether a component might act as an Analyzer with respect to one
component, while also acting as a Manager with respect to another.
o Analyzers are homogeneous or meshed by multiple vendors or types.
1.5. Focus of Format
The parameterization format is not designed to be used for initial
setup or basic configuration of new / changed hardware. The focus of
the parameterization format is to administer and operate different
IDS-applications from one instance and by one user front end.
The format is not intent for signalization. Focus is the
administration with parameterization and parameterization request of
different IDS-applications with a standardized procedure.
The format MUST NOT be designed to create signature or anomaly
pattern. This information has to be created external and uploaded as
update file.
1.6. Parameterization Methodology
IDS compares Activity against a reference database. References
consist of a baseline part and a customizing part. The baseline part
describes the event itself (intrusion activity, vulnerability or
baseline). Baseline parts are customized to the individual
implementation. For example, a SYN-flood contains in the baseline
part the attack description. In this case, the TCP/IP protocol with a
set SYN-flag. The customizing part defines threshold and a time
interval for the individual implementation of the event. As result,
the SYN-request (attack description) has to occur more than 200 times
(threshold) within 1 second (time interval) to cause a SYN-flood
signalization. The baseline part of a rule is vendor-specific and
depends on the internal processing of Sensor and Analyzer. Therefore
it is out of scope for parameterization. IDPEF customizes the vendor-
specific baseline-part to the individual implementation of the IDS
entity.
Boesch Expires July 12, 2015 [Page 10]
Internet-Draft The IDPEF January 2015
2. The Communication Proceeding
The communication proceeding has to work in different IDS architec-
tures. The transport protocol IDXP [4] is responsible for transport
and grants appropriate security. The basic communication proceeding
within IDXP for the format exchange is described in detail here.
Protection of the communication and the exchanged content between IDS
entities is focus of TLS [12], BEEP [11] and other integration
mechanisms. These are not part of the communication proceeding of
IDPEF, but MUST be granted by the transport protocol.
The following points do not have influence on communication and
format:
o Different analyzing techniques
o mixed feature sets, versions and/or vendors
o Different sensor types
o Parameterization status of Sensors if they are completely or only
partial or not parameterized or have a mix of parameterization
states.
o If a Manager parameterize an Analyzer directly or over a second
Manager.
2.1. Parameterization Communication
A change of the Manager SHOULD be done with minimal impact and
expenditure of work time. The Manager does not provide any feature or
parameter information of Analyzers. An information request is a good
way to allow more than one Manager to administrate individual
Analyzers. The parameterization proceeds global like:
Manager: Analyzer:
selection of
Analyzer
---- begin of OPTIONAL request ----
-------parameter-request------> preparation of
IDPEF response
Boesch Expires July 12, 2015 [Page 11]
Internet-Draft The IDPEF January 2015
<-------parameter-reply--------
---- end of OPTIONAL request ----
change of
parameters
-------parameter-update-------> update of para-
meters in the
Analyzer
parameterization- <-------parameter-reply--------
check
2.2. Version Update on Hierarchical Lower IDS-Entities
The parameterization format has to support update of hierarchical
lower IDS entities i.e. updates from a Manager to an Analyzer.
Updates will be terminated to a time specification - derivate
absolute (e.g. 23:00) or relative terminations (e.g. +02:00) are
possible. An update file numeration defines the update order.
The update has to be checked after every update execution and an
update status will be send. If an update execution fails, all
following updates SHOULD set out and not be executed. A notification
SHOULD be sent for each update file if the update processing is
canceled. Updates will be applied like:
Manager: Analyzer:
Version update
Initialization
---- begin of OPTIONAL request ----
-------version request-------->
<-------version reply----------
Boesch Expires July 12, 2015 [Page 12]
Internet-Draft The IDPEF January 2015
---- end of OPTIONAL request ----
Update preparation
Selection of files
schedule of update
-------update information------>
----------update files---------> Update termination
Update execution
<--update status notification-- Update check
signalization of (outside of IDPEF)
update status
3. The IDPEF XML Implementation
The IDPEF implementation uses a Document Type Definition (DTD) to
describe XML documents. The XML solution was primary selected,
because it provides a closed solution together with IDMEF.
A widely spread and powerful used standard is XML and its flexibility
makes it a good choice for applications, also for implementing the
IDPEF as well. Other, more specific reasons for choosing XML to
implement the IDPEF are:
o Software tools for processing XML documents are widely available,
as commercial and open source version. Numerous tools and
programming interfaces for parsing and/or validating XML are
available in a variety of languages. Widespread access to tools
makes adoption of the IDPEF by product developers easier and
faster. Web technologies like Java Script enables an easy
processing of XML.
o XML supports fully internationalization and localization for IT
solutions that cross political and/or cultural boarders. So XML
enables a global usage to parameterize the Analyzer to the
individual implementation and to maintain the IDS in operations.
UTF-8, UTF-16 and Unicode makes XML applications compatible with
these common character encodings.
Boesch Expires July 12, 2015 [Page 13]
Internet-Draft The IDPEF January 2015
o XML also provides support for specifying, on a per-element basis,
the language in which the element's content is written, making
IDPEF easy to adapt to "Natural Language Support" versions of a
product.
o XML is free and has no license, license fees or royalties.
o XML is human readable. Security teams are able to revise the para-
meterization or publish specification guidelines for IDS.
3.1. Notational Conventions and Formatting Issues
The IDPEF description bases on three specifications:
o The data-model bases on a Unified Modeling Language description.
o XML describes the markup used in IDPEF documents
o Documents are represented in IDPEF markup.
In appendix A these notations will be described in sufficient detail
by examples so that unfamiliar readers are able to understand the
document. These descriptions are not comprehensive. They only cover
the components of the notations used by the data model and document
format.
Several document formatting issues will be shown in appendix A
(examples) and Appendix C. These will be applying to XML documents,
including formats for particular data types, special character and
white space processing, character sets and languages.
3.2. IDPEF XML Documents
This section describes basic IDPEF XML document formatting rules.
Most of these rules are based of rules for formatting XML documents.
3.2.1. The Document Header - The XML Declaration
IDPEF documents will be exchanged between IDPEF compliant
applications. The exchange begins with an XML declaration, followed
by the used XML version. Specification of the used encoding is
RECOMMENDED.
Each XML document contains a document type declaration (DTD). The DTD
represents significant overhead by bandwidth consume and performance
for XML processing to an IDPEF compliant parameterization message. To
reduce these negatives Analyzers and Managers agree on a particular
Boesch Expires July 12, 2015 [Page 14]
Internet-Draft The IDPEF January 2015
DTD via a local reference to the accessing Manager. Therefore IDPEF
messages has to start with:
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-version="1.0"
xmlns:idpef="http://manager.example.org/idpef"/>
3.2.2. Character Data Processing in IDPEF
The character processing was already defined for IDMEF [2], and will
be also used analogue for IDPEF. The section will be recapitulated
here for better understanding:
IDPEF compliant applications and messages SHOULD use the character
encodings UTF-8 or UTF-16 only to grand portability. If no encoding
is specified for an IDPEF message, UTF-8 will be assumed, consistent
with the XML standard.
IDPEF documents encoded in UTF-16 MUST begin with the Byte Order
Mark. This is consistent to ISO/IEC 10646 Annex E and Unicode
Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character, #xFEFF).
It is RECOMMENDED that IDPEF compliant applications use the entity
form (section 4.1 of [10]) of the characters '&', ,'<', '>', '"', and
''' (single-quote) whenever writing these characters in data, to
avoid any possibility of misinterpretation [2].
Analogue to the IDMEF specification, the "xml:space" attribute have
to be supported for all IDPEF elements for white space processing
[6].
3.2.3. Languages in IDPEF
The language of the content is encoded and has to be specified in
IDPEF compliant communication. This will be done in a generally way
by applying the attribute "xml:lang" for the top-level element [9].
All other elements will inherit that definition else the language has
to be specified separately for a single element branch. This
specification is set for the single / data record.
3.3. IDPEF Data Types
XML is a text formatting language and all data will be expressed as
"text" (as opposed to "binary") within an XML IDPEF message, except
it is explicated declared here.
Boesch Expires July 12, 2015 [Page 15]
Internet-Draft The IDPEF January 2015
Each data type in the model has specific formatting requirements in
an XML IDPEF message. The data types are Integers, Real Numbers,
Bytes, Enumerated Types, Date Time Strings [7], Port Lists and also
Characters and Strings which are already defined in the IDMEF data
model specification [2].
3.4. Case-sensitivity
All values are not case-sensitive, except it will be explicit defined
here.
4. The IDPEF Parameterization Data Model
This section illustrates the structure of the IDPEF parameterization
and the relationship between single elements. The individual elements
are explained in detail in the respective section of parameterization
nodes.
The IDPEF parameterization model describes only the node structure of
the parameterization information. The communication procedure was
already described in section 2.
4.1. Overview
The structure of the IDPEF core components is displayed in figure 2.
The top level node (root node) is called "IDPEF-Message".
The "IDPEF-Message" node is structured in the three sections
"entity", "alert" and "update". Each section focuses on detailed
parameterization information for global analyzer information, event
parameterization and updates.
Boesch Expires July 12, 2015 [Page 16]
Internet-Draft The IDPEF January 2015
+------------------------------------------------------------+
| IDPEF-Message |
+------------------------------------------------------------+
A A A
| | |
V V V
+------------------+ +-----------------+ +-----------------+
| entity | | alert | | update |
+------------------+ +-----------------+ +-----------------+
| +-------------+ | +------------+ | +------------+
+->| network | +->| group | +->| updatefile |
| +-------------+ +------------+ +------------+
| +---------+ |
| +-------------+ | +-----------+ V
+->| location | +--->| event | +----------+
| +-------------+ | +-----------+ | data |
| | | +-------+ +----------+
| V | |
| +---------+ | | +------------+
| | address |<--+ | +->| connection |
| +---------+ | | | +------------+
| +---------+ | | | +------------+
| | contact |<--+ | +->| system |
| +---------+ | | | +------------+
| | | | +------------+
| | | +->| ipara |
| +-------------+ | | +------------+
+->| tadmin |-+ |
| +-------------+ | |
| +-------------+ | | +------------+
+->| fservice |-+ +--->| react |
+-------------+ +------------+
Figure 2 Overview of IDPEF data model
4.2. Message Nodes
4.2.1. IDPEF-Message
The IDPEF-Message is the top-level of the IDPEF data model. All IDPEF
parameterization nodes are child nodes of the IDPEF-Message node. It
is the root node of all IDPEF-Messages as well as the IDPEF DTD. The
root node is represented in the IDPEF DTD as:
Boesch Expires July 12, 2015 [Page 17]
Internet-Draft The IDPEF January 2015
<!ELEMENT IDPEF-Message(
entity?, alert?, update?
)>
<!ATTLIST IDPEF-Message
format (request|reply|update) #REQUIRED
errorcode (100|200|300|400) #OPTIONAL
device (PCDATA) #REQUIRED
>
This node includes the attributes:
format
REQUIRED: The format attribute defines the type of data contents.
Possible values are "request", "reply" or "update".
errorcode
OPTIONAL: RECOMMENDED to be set in case of a reply:
100: ok
200: Request or Update not valid
250: Request or Update not well-formed
300: Internal processing error by the XML
400: Activation of new parameters failed, restart with old
parameterization.
device
REQUIRED: This attribute defines on what device the
parameterization has to be applied. This attribute supports multi-
hop parameterization. In case of a change of analyzerid / name in
the entity section the old attribute value has to be used. In case
of a bulk update, the devices are separated by comma (,).
Boesch Expires July 12, 2015 [Page 18]
Internet-Draft The IDPEF January 2015
4.2.2. The Entity Section
The "entity" node specifies the IDS entity. This includes basic
information about the entity itself and contains also additional
information about the environment of the device. Figure 2 illustrates
the structure of the "entity" section on the left side.
The node "entity" accumulates the child nodes "network", "location",
"tadmin" and "fservice". The three nodes "location", "tadmin" and
"fservice" contain the additional node "address". The nodes "tadmin"
and "fservice" include additionally the node "contact".
The node "entity" contains characterizing attributes of the entity.
The "entity" node is represented in the IDPEF DTD as:
<!ELEMENT entity (
network, location*, tadmin*, fservice*
)>
<!ATTLIST entity
analyzerid PCDATA #REQUIRED
domain PCDATA #REQUIRED
name PCDATA #REQUIRED
version PCDATA #REQUIRED
model PCDATA #REQUIRED
serialnr PCDATA 'unknown'
license PCDATA 'unknown'
expiration PCDATA 'unknown'
time-zone CDATA #REQUIRED
ntp-server PCDATA 'unknown'
dns-server PCDATA 'unknown'
class (active|passive) #REQUIRED
Boesch Expires July 12, 2015 [Page 19]
Internet-Draft The IDPEF January 2015
focus PCDATA #REQUIRED
certificate PCDATA 'unknown'
protect PCDATA 'unknown'
>
So each entity node includes the individual attributes:
analyzerid
Exactly one string: Unique ID to identify the individual IDS-entity
(physical node).
domain
Exactly one string: Domain where the Analyzer belongs to.
name
Exactly one string: Name to identify the individual IDS-entity
(logical node).
version
Exactly one string: This attribute refers to the software version
of each IDS software entity. This is a read-only attribute and will
be set automatically by the IDS-entity itself. This value is case-
sensitive.
model
REQUIRED: The model that characterizes the Analyzer's soft- and /
or hardware.
serialnr
Exactly one string: Contains the serial number of the device for
replacement information purposes. This value is case-sensitive.
license
Exactly one string: Contains the license key / string. If no
license is REQUIRED the value is "none". This value is case-
sensitive.
Boesch Expires July 12, 2015 [Page 20]
Internet-Draft The IDPEF January 2015
expiration
Exactly one data string: Indicates the expire date of the license
(date or "never").
time-zone
Exactly one time-string: Difference of local time to UTC.
ntp-server
Exactly one string: IP-addresses of the NTP servers in dotted
notation (IPv4 or IPv6) or server name separated by comma (,).
dns-server
Exactly one string: IP-addresses of the DNS servers in dotted
notation (IPv4 or IPv6) separated by comma (,).
class
REQUIRED: This attribute specifies globally, if this entity SHOULD
be execute active response or notify only.
focus
Exactly one value or more: Specification of the protected system.
Keywords are defined as: "network", "server", "application" and
"wireless". This is a read-only attribute and will be set
automatically by the IDS-entity itself.
certificate
OPTIONAL: String with the certificate that has to be used for the
next management access via IDXP. This value is case-sensitive.
protect
OPTIONAL: This attribute will be used to provide additional
information about the protected systems and/or networks of this
IDS-entity for incident handling. It is a string with a free
description.
Boesch Expires July 12, 2015 [Page 21]
Internet-Draft The IDPEF January 2015
4.2.2.1. network
Network configuration parameters of the IDS management interface of
the entity will be summarized in this node. This node is represented
in the IDPEF DTD as:
<!ATTLIST network
IP-address PCDATA #OPTIONAL
netmask PCDATA #OPTIONAL
gateway PCDATA #OPTIONAL
ifspeed PCDATA #OPTIONAL
port CDATA '603' #REQUIRED
>
The individual attributes are brief described here:
IP-address
None or exactly one IP-address: IP-address of the IDS communication
interface in dotted IPv4 or IPv6 notation. This interface is used
for IDS communication only. For redundant systems the collective
IP-address will be set. If no dedicated IDS management interface is
in place, this attribute value will be not set.
netmask
None or exactly one netmask: Netmask of the IDS communication
interface in dotted IPv4 or IPv6 notation corresponding to the
attribute IP-address of this node. This interface is used for IDS
communication only. If no dedicated IDS management interface is in
place, this attribute value will be not set.
gateway
None or exactly one IP-address: IP-address of the gateway for the
IDS communication in dotted IPv4 or IPv6 notation, corresponding to
the attribute IP-address of this node. This interface is used for
IDS communication only. If no dedicated IDS management interface is
in place, this attribute value will be not set.
Boesch Expires July 12, 2015 [Page 22]
Internet-Draft The IDPEF January 2015
ifspeed
None or exact one string: Settings for the interface like interface
speed, negotiations or duplex parameters. These parameters will be
set for the IDS communication interface only. This value is case-
sensitive. For redundant systems the value will be set on all
entities. If no dedicated IDS management interface is in place,
this attribute value will be not set.
port
Exact one number: Port of the IDS management application (IDPEF
port for IDXP). The default port is 603 that is already defined for
IDXP by the IANA.
4.2.2.2. address
The node "address" contains information about the geographical
location. These are (location)name, street, building number, ZIP-code
and city. The address node is represented in the IDPEF DTD as:
<!ATTLIST address
name PCDATA 'unknown'
street PCDATA 'unknown'
number PCDATA 'unknown'
ZIP PCDATA 'unknown'
city PCDATA 'unknown'
country PCDATA 'unknown'
>
It is RECOMMENDED to set all attributes of this node. Undefined
attributes will be accepted, but in case of problems with the entity
hardware, more time MUST be spend to locate the geographical address
of the physical device.
name
OPTIONAL, but SHOULD be set: Defines the company- or location-name
in which rooms the physical IDS entity is located. This value is
case-sensitive.
Boesch Expires July 12, 2015 [Page 23]
Internet-Draft The IDPEF January 2015
street
OPTIONAL, but SHOULD be set: Defines the street where the physical
IDS entity is located. This value is case-sensitive.
number
OPTIONAL, but SHOULD be set: Specifies the building number where
the physical IDS entity is located. This value is case-sensitive.
ZIP
OPTIONAL, but SHOULD be set: Specifies the ZIP-Code where the
physical IDS entity is located. This value is case-sensitive.
city
OPTIONAL, but SHOULD be set: Specifies the city where the physical
IDS entity is located. This value is case-sensitive.
country
OPTIONAL, but SHOULD be set: Specifies the country where the
physical IDS entity is located. This value is case-sensitive.
4.2.2.3. location
The node "location" contains the child node "address" and enriches
this by the attributes "floor", "room", "rack" and "position" to
specify the location more in detail. In case of one logical but
physical redundant Analyzers with two different postal addresses this
node will be used two-times. The node "location" is represented in
the IDPEF DTD as:
<!ELEMENT location (
address
)>
<!ATTLIST location
floor PCDATA 'unknown'
room PCDATA 'unknown'
Boesch Expires July 12, 2015 [Page 24]
Internet-Draft The IDPEF January 2015
rack PCDATA 'unknown'
position PCDATA 'unknown'
>
floor
OPTIONAL, but SHOULD be set: Specifies the floor where the physical
IDS entity is located. This value is case-sensitive.
room
OPTIONAL, but SHOULD be set: Specifies the room where the physical
IDS entity is located. This value is case-sensitive.
rack
OPTIONAL, but SHOULD be set: Specifies the rack where the physical
IDS entity is located. This value is case-sensitive.
position
OPTIONAL: locates the hardware by an individual description. This
could be any hints or also longitude, latitude and altitude for an
open graphical position system. This value is case-sensitive.
4.2.2.4. contact
The node "contact" contains information to inform the corresponding
group or person. In "contact" are information about the communication
channel and the preferred communication channel. This node is
represented in the IDPEF DTD as:
<!ELEMENT contact>
<!ATTLIST contact
mobile PCDATA 'unknown'
e-mail PCDATA 'unknown'
phone PCDATA 'unknown'
FAX PCDATA 'unknown'
TTS PCDATA 'unknown'
Boesch Expires July 12, 2015 [Page 25]
Internet-Draft The IDPEF January 2015
preferred (mobile|e-mail|phone|FAX|TTS) #REQUIRED
>
mobile
OPTIONAL, but SHOULD be set: Provides the mobile phone number of
the contact.
e-mail
OPTIONAL, but SHOULD be set: Provides the e-mail address of the
contact.
phone
OPTIONAL, but SHOULD be set: Provides the landline number of the
contact.
FAX
OPTIONAL, but SHOULD be set: Provides the FAX number of the
contact.
TTS
OPTIONAL, but SHOULD be set: Provides the assignment group of the
trouble ticket system for the contact. This value is case-
sensitive.
preferred
REQUIRED: Defines, which contact interface is preferred by the
contact. This attribute SHOULD be used, when more than one contact
information is defined.
4.2.2.5. fservice
The node "fservice" includes information about a local field service
to solve problems. This node uses the node "contact" with the
attribute "contactname" for additional contact information like name
of a person or the group name. This node is represented in the IDPEF
DTD as:
<!ELEMENT fservice (
Boesch Expires July 12, 2015 [Page 26]
Internet-Draft The IDPEF January 2015
contact, address
)>
<!ATTLIST fservice
contactname PCDATA #REQUIRED
>
contactname
REQUIRED: "contactname" is an open field to specify additional
information i.e. name of a contact person or the name of the field
service department. This value is case-sensitive.
4.2.2.6. tadmin
The node "tadmin" includes information about the technical
administrative (responsible) for this IDS entity. This node uses the
node "contact" with the attribute "contactname" for additional
contact information like name of a person or the group name. This
node is represented in the IDPEF DTD as:
<!ELEMENT tadmin (
contact, address
)>
<!ATTLIST tadmin
contactname PCDATA #REQUIRED
>
contactname
REQUIRED: "contactname" is an open field to specify additional
information i.e. name of a main contact person or a team-name. This
value is case-sensitive.
4.2.3. The Update Section
The "update" section specifies all relevant information and data of
IDS entity updates. Therefore a unique ID, execution- and reference-
Boesch Expires July 12, 2015 [Page 27]
Internet-Draft The IDPEF January 2015
time will be set. Additional the update files, update schedule and
update notification are defined.
So this node will be represented in the IDPEF DTD as:
<!ELEMENT update (
update-file*
)>
<!ATTLIST update
ID CDATA '0' #REQUIRED
reference-time time #OPTIONAL
exec-time time #REQUIRED
type (update|backup|restore) #REQUIRED
>
The update node has four attributes:
ID
REQUIRED: The "ID" is the unique identifier for the update. This
MUST be defined unique by the Manager or the Administrator. This
value is case-sensitive.
reference-time
OPTIONAL: The "reference-time" is the time of the Manager. Time
differences between the local IDS entity and the central IDS
Manager will be eliminated. By timely relative updates this
attribute is REQUIRED.
exec-time
REQUIRED: The "exec-time" terminates the time of execution start.
If no reference-time is specified, the exec-time refer to the
system time of the entity.
Boesch Expires July 12, 2015 [Page 28]
Internet-Draft The IDPEF January 2015
type
REQUIRED: Defines the kind of update. The value "update" is used
for patches, updates and upgrades. "backup" is used to collect all
important files for a parameter restore and the value "restore" is
used to restore a parameter configuration by the transferred file.
4.2.3.1. update-file
The "update-file" node specifies name and location of the update
files. Additional notifications for each update result will be
specified. This node uses the attribute "notification" to specify the
result notification of each update file execution. So this node will
be represented in the IDPEF DTD as:
<!ELEMENT update-file (
data
)>
<!ATTLIST update-file
filename PCDATA #REQUIRED
location PCDATA #REQUIRED
updateparameter PCDATA #REQUIRED
rank PCDATA #OPTIONAL
notification PCDATA 'none'
ninfo PCDATA 'none'
>
The update node has six attributes:
filename
REQUIRED: This attribute contains the name of the file. This value
is case-sensitive.
Boesch Expires July 12, 2015 [Page 29]
Internet-Draft The IDPEF January 2015
location
REQUIRED: This attribute specifies the location of the update file
on the local updated IDS entity. This value is case-sensitive.
updateparameter
REQUIRED: This attribute contains the execution parameters. This
value is case-sensitive.
rank
OPTIONAL: Specify the update-schedule by numeration.
notification
OPTIONAL: Notification refers to the attribute "rid" of "react",
which general notification channel has to be used for notification.
This value is case-sensitive.
ninfo
OPTIONAL: This attribute contains additional static information to
the IDS entity or the notification. This value is case-sensitive.
4.2.3.2. data
This node is REQUIRED and contains the (binary) update file in
base64 coded format. This value is case-sensitive.
4.2.4. The Alert Section
The "alert" section includes the groups for parameterization of
events and reactions. The "alert" section is used to group and
parameterize single "event" and the "react" nodes for signalizations
or responses. So the "alert" section structures all "event" and
"react" nodes with group nodes. The "alert" section will be
represented in the IDPEF DTD as:
<!ELEMENT alert (
group*
)>
Boesch Expires July 12, 2015 [Page 30]
Internet-Draft The IDPEF January 2015
4.2.4.1. group
The node "group" contains the parameterization nodes for events and
reactions. The "event" nodes are used to parameterize single events
and the "react" nodes contain general notification parameters for
signalizations or responses. So the "group" node structures all
"event" and "react" nodes for a clustering of events and responses.
The "group" child node will be represented in the IDPEF DTD as:
<!ELEMENT group (
event*, react*
)>
<!ATTLIST group
name PCDATA #REQUIRED
name
REQUIRED: This attribute defines the identification for the goup.
This value is case-sensitive.
4.2.4.1.1. event
In the "event" node all parameters to an alert will be defined. So
this node based on the nodes "connection", "system" and "ipara".
So the node "event" will be represented in the IDPEF DTD as:
<!ELEMENT event (
connection*, system*, ipara*
)>
<!ATTLIST event
enable (yes|no) 'yes' #REQUIRED
name PCDATA #REQUIRED
Boesch Expires July 12, 2015 [Page 31]
Internet-Draft The IDPEF January 2015
displayedas PCDATA #REQUIRED
impact (conficence | integrity |
availability | none) 'none'
severity ((informational | low |
medium | high)* | CDATA) '1'
priority CDATA '1'
interface PCDATA 'all'
origin PCDATA 'unknown'
frequency CDATA '0'
interval CDATA '0'
ignore CDATA '0'
ngroup PCDATA 'unknown'
>
Each "event" node contains 12 attributes:
enable
REQUIRED: The "enable" attribute defines if this alert is active or
not ("yes" or "no").
name
REQUIRED: This attribute defines the vendor-specific identification
for the event. This value is case-sensitive.
displayedas
REQUIRED: This value will be displayed in case of alarming /
notification. It SHOULD briefly characterize the occurred event.
This value is case-sensitive.
Boesch Expires July 12, 2015 [Page 32]
Internet-Draft The IDPEF January 2015
impact
OPTIONAL: This attribute specifies, which security value
(preferred: "confidence", "integrity", "availability" and/or
"none") would be affected by this attack.
severity
REQUIRED: The value of the attribute severity characterizes the
intrusion impact in context to other systems and/or applications.
The severity supports Operators to aggregate all severities of a
complex and several intrusions. This value is split in
"informational", "low", "medium", and "high" or a numeric rating
(e.g CVSS base value).
priority
OPTIONAL: The priority supports Operators to decide which intrusion
has to be observed and what will be primary reported for
statistical information like port-scans or sporadic connection
failures. In case of multiple detections of several simultaneous
intrusions this value supports the Operator on which intrusion
should be the focus and in which order are the intrusions to
respond. This value covers a range from 1 to 255.
interface
OPTIONAL: The attribute interface defines the interface for the
alert parameters if possible / necessary.
origin
OPTIONAL: References the origin of this event: unknown, vendor-
specific, user-specific, bugtraqid, cve, osvdb, etc. It could also
include a link for more information about this event. This value is
case-sensitive.
frequency
OPTIONAL: Specifies the threshold within the measure interval, how
often the event has to occur or a percentage value (threshold or
change), before the event will be raised.
Boesch Expires July 12, 2015 [Page 33]
Internet-Draft The IDPEF January 2015
interval
OPTIONAL: The "interval" attribute specifies the measure interval
in seconds for the value in "frequency", before the event will be
raised.
ignore
OPTIONAL: Defines an inactivity period of this event in seconds,
after it was raised. This prevents that a recurrent event floods
the alert panel.
ngroup
REQUIRED: This attribute will be used to map the notification for
this event.
4.2.4.1.1.1. connection
The "connection" node summarizes all parameters related to the
network connection. So the node "connection" will be represented in
the IDPEF DTD as:
<!ATTLIST connection
source PCDATA #REQUIRED
destination PCDATA #REQUIRED
port PCDATA #REQUIRED
direction (bidirectional|unidirectional) #REQUIRED
>
Each "connection" node contains the four attributes:
source
REQUIRED: This attribute defines the initiating IP-address of the
connection. It will be used in dotted form with OPTIONAL "/" with
netmask in dotted or bit-noted form. Multiple IP-addresses or
address ranges will be separated with a comma. IP-address ranges
could be specified by a hyphen (-) operator or netmask after a
slash (/) or wild card operator (*) like 192.168.*.10.
Boesch Expires July 12, 2015 [Page 34]
Internet-Draft The IDPEF January 2015
destination
REQUIRED: This attribute defines the destination IP-address of the
connection. It will be used in dotted form with OPTIONAL "/" with
netmask in dotted or bit-noted form. Multiple IP-Addresses will be
separated with a comma. IP-address ranges could be specified by a
hyphen (-) operator or netmask after a slash (/) or wild card
operator (*) like 192.168.*.10.
port
REQUIRED: Defines the destination port or a port range for this
event. A port range will be specified by a hyphen operator (-).
Multiple ports or port ranges are separated by a comma (,).
direction
REQUIRED: This attribute defines if the connection parameters will
be analyzed in both directions (bidirectional) or only in the
defined direction from source to destination (unidirectional).
4.2.4.1.1.2. system
The node "system" pools the attributes for system specific
parameters. The DTD representation for this node is:
<!ATTLIST system
type PCDATA #Required
value PCDATA #Required
enable (yes|no) 'yes' #Required
>
type
REQUIRED: This attribute defines the type for the value, e.g. if it
is a directory or a file.
value
REQUIRED: This attribute defines the value of the attribute.
Multiple values are separated with a comma (,). This value is case-
sensitive.
Boesch Expires July 12, 2015 [Page 35]
Internet-Draft The IDPEF January 2015
enable
REQUIRED: The "enable" attribute defines if this alert is active or
not.
4.2.4.1.1.3. ipara
The "ipara" node provides individual parameter-extensions. So it is
possible to set individual parameter names which are not predefined.
The "ipara" node provides the attributes "name", "value" and "time".
So the DTD representation for this node is:
<!ATTLIST ipara
enable (yes|no) 'yes' #Required
name PCDATA #Required
value PCDATA #Required
time (time)
>
So this node includes this four attributes:
enable
REQUIRED: The "enable" attribute defines if this alert is active or
not.
name
REQUIRED: The attribute "name" defines the name of the individual
parameter for a correct assignment. This value is case-sensitive.
value
REQUIRED: The attribute "value" contains the individual parameter
of the individual attribute. This value is case-sensitive.
time
OPTIONAL: This attribute defines a time interval (i.e. 3600) in
seconds or a local time window (i.e. 10:00:00 - 23:00:00) for the
Boesch Expires July 12, 2015 [Page 36]
Internet-Draft The IDPEF January 2015
specified attribute. The time interval specifies an increase or
decrease of the attribute "value". If a time interval will be
defined the value of the attribute "value" is a fixed threshold.
4.2.4.1.2. react
The response and notification parameterization depends mainly on the
feature set of the single IDS entity. All parameterized responses and
notifications MUST be checked before the local IDS entity accepts the
configuration. The "react" node will be represented in the IDPEF DTD
as:
<!ATTLIST react
enable (yes|no) 'yes' #REQUIRED
rid PCDATA #REQUIRED
type PCDATA #REQUIRED
structure PCDATA
iaddress PCDATA #REQUIRED
>
The "react" node contains the five attributes:
enable
REQUIRED: The "enable" attribute defines if this alert is active or
not ("yes" or "no").
rid
REQUIRED: This attribute specifies the unique ID of the reaction
(response or notification).
type
REQUIRED: This attribute specifies the notification or response
type that will be taken by an identified attack. This could be a
block of this packet / connection by the Sensor or another device,
a redirect to a honey net, to take the sever offline, or an attack
signalization only.
Boesch Expires July 12, 2015 [Page 37]
Internet-Draft The IDPEF January 2015
structure
OPTIONAL: Some notification content has an open structure. This
attribute defines the notification content. This value is case-
sensitive.
iaddress
REQUIRED: The attribute "iaddress" contains the IP-address (IPv4 or
IPv6) of the notification receiving system or phone-number for SMS
notification.
5. Extending the IDPEF
IDS will be still developed in the future. Standardized protocols
MUST be the cutting edge to support research prototypes. So IDPEF has
to support state of the art requirements of research projects.
To fulfill the requirements IDPEF will be extended by using
individual parameter option "ipara". This will support a lot of
variants to extend the IDPEF.
6. Special Considerations
6.1. XML Validity and Well-Formalness
Instead to include the DTD in the IDPEF compliant communication, it
will be defined in the header of the IDPEF-Message. Such IDPEF
documents will be well-formed and valid as defined in [5]. Other
IDPEF documents will be specified that a document header will be not
included (e.g. entries in an IDPEF-format configuration file). This
IDPEF documents are well-formed but not valid.
A document has a single element that contains everything else, and
that all other elements embedded nicely within each other without any
overlapping. Only in this case a document is valid and well-formed.
A document is valid when it is well-formed, but it follows also
specific events (contained in the DTD) about which elements are
allowed in the document. A document could not be valid without a DTD.
XML processors have to parse valid documents only. Without
validation, a document may contain elements in nonsense order and
could not process correctly. A not valid document is not suited for a
proper parameter transfer. So IDPEF documents MUST be valid.
Documents which are not valid abet misparameterizations and will be
not processed or applied.
Boesch Expires July 12, 2015 [Page 38]
Internet-Draft The IDPEF January 2015
6.2. Unrecognized XML Tags
In case that an IDPEF compliant application receives a well-formed
and valid IDPEF message containing tags that it does not understand,
this IDPEF message MUST continue to process, provided that such
messages meet the well-formatting requirement of section 6.1. It is
up to the individual application to decide how to process (or ignore)
any content from the unknown element(s). Unrecognized tags MUST be
notified and the new running parameterization of the entity will be
sent back as reply message. Within the replied IDPEF message the
errorcode has to be set with the errorcodes:
100: ok
200: Request or Update not valid
250: Request or Update not well-formed
300: Internal processing error by the XML
400: Activation of new parameters failed, restart with old
parameterization.
7. Security Considerations
IDPEF does not treat security matters directly. It is only an
exchange format to standardize and structure parameterization
information of IDS. So IDPEF could be used local by the IDS software
or in combination with a transport protocol like IDXP [4] between
Manager and Analyzers. So the security considerations are made in the
rfc of IDXP [4], BEEP [11], TLS [12] and SASL [13]. So summarized
considerations are made here:
7.1. Systems Security Issues
The local usage of IDPEF data (i.e. configuration files) MUST be
protected at least against unauthorized usage, inappropriate usage
and / or Denial of Service of the data. So confidentiality and
integrity of local IDPEF data (e.g. configuration files) MUST be
handled in responsibility of the particular IDS software. A peer
entity authentication within closed local software is not required.
To provide most flexibility the IDS software MUST be choose which
mechanisms are adequate and have to ensure that its configuration
data is sufficient and state of the art protected.
Boesch Expires July 12, 2015 [Page 39]
Internet-Draft The IDPEF January 2015
The remote provisioning of IDPEF data MUST be protected against
unauthorized usage, inappropriate usage. All transmitted IDPEF data
have to be accepted from the Analyzers. The Manager has to ensure,
that only appropriate data corresponding to the authorization will be
transmitted to the Analyzers. The Manager authorizes as appropriate
managing peer entity. So the Manager has to check and enforce the
authorization of its local users or managing peer entities. The
Manager will be authorized as appropriate Manager based on SASL
mechanisms.
7.2. Communications Security Issues
IDPEF itself provides no transport security and depends on the
security of the transport protocol. In case of transmission of IDPEF
between Manager and Analyzer the transport protocol IDXP [4] MUST be
guaranteed adequate data integrity, confidentiality and peer entity
authentication of the transferred message. The IDPEF use the security
features of the transport protocol IDXP [4].
The IDXP profile is a profile of BEEP [11]. The BEEP provides
separate mechanisms for transport security, user authentication, and
data exchange. The IDXP profile MUST initially negotiate a BEEP
security profile between the peers that offers the REQUIRED security
properties. The TLS and SASL profile MUST be used to provide for
transport security for IDPEF data. TLS supports cipher suites that
provide varying levels of security. Administrators SHOULD use the
strongest cipher suite but SHOULD also carefully choose which cipher
suites are provisioned.
7.2.1. Passive Attacks
7.2.1.1. Confidentiality Violations (Eavesdropping)
Confidentiality violations such as eavesdropping are a serious attack
against IDPEF data. So the transport protocol IDXP [4] MUST be used
with the TLS and SASL profiles so that the communication is adequate
protected.
7.2.1.2. Password Sniffing
IDPEF MAY also handle among others authentication information. Due to
the circumstances that IDPEF provides itself no transport security
confidentiality, integrity and peer entity authentication MUST be
provided by SASL and TLS profile option of the BEEP framing
mechanisms of IDXP. IDPEF MUST NOT used without the TLS and SASL
options of BEEP.
Boesch Expires July 12, 2015 [Page 40]
Internet-Draft The IDPEF January 2015
7.2.1.3. Offline Cryptographic Attacks
Offline cryptographic attacks are a serious risk to configuration
information. To hamper this kind of attacks Analyzer and Manager
SHOULD provide and use always state of the art algorithms. So the
Analyzer SHOULD refuse weak cryptographic algorithms for
confidentiality and / or authentication. The BEEP as framing
mechanism for IDXP has to be used with the TLS and SASL option.
7.2.2. Active Attacks
7.2.2.1. Replay Attacks
To protect messages against replay IDPEF will be transmitted via IDXP
[4] with TLS [12] option of the BEEP [11] framing mechanisms. The
appropriate level of security MUST be chosen by the administrator
carefully. To protect application data refer to Appendix F2 of [12]
for a discussion of security considerations.
7.2.2.2. Message Insertion
To protect messages against insertions IDPEF will be transmitted via
IDXP [4] with TLS [12] option of the BEEP [11] framing mechanisms.
The appropriate level of security MUST be chosen by the administrator
carefully. To protect application data refer to Appendix F of [12]
for a discussion of security considerations.
7.2.2.3. Message Deletion
The communication proceeding of IDPEF ensures, that parameter
modification messages (classified as parameter-update) MUST send back
(classified as parameter-reply) so that the send Manager is able to
compare the send update message and the received update response.
Other deleted messages are uncritical and could be requested a second
time.
On transport layer IDXP as profile of the BEEP framing mechanisms
provided additional mechanisms to ensure a correct message transport
to the peer entity.
7.2.2.4. Message Modification
To protect messages against modification IDPEF will be transmitted
via IDXP [4] with TLS [12] option of the BEEP [11] framing
mechanisms. The appropriate level of security MUST be chosen by the
administrator carefully. To protect application data refer to
Appendix F2 of [12] for a discussion of security considerations.
Boesch Expires July 12, 2015 [Page 41]
Internet-Draft The IDPEF January 2015
7.2.2.5. Man-In-The-Middle
IDPEF MUST be transported with TLS and SASL options in BEEP of IDXP.
IDXP as profile of the BEEP framing mechanisms with focus on man-in-
the-middle-attacks is already under discussion in Section 9 of [11]
for the security considerations.
7.2.3. Topological Issues
Architectural solutions like firewalls and separated networks keep
the IDS communication in a WALLED GARDEN to make the communication
safer. This protect also against Denial of Service attacks.
7.2.4. Denial of Service
None of these security measures provides any real protection against
denial of service. Based on the transport layer security (SASL and
TLS) of BEEP connections, it is possible to limit a variety of
attacks on individual connections using forged RSTs or other kinds of
packet injection.
7.3. Digital Signatures
IDPEF assigns responsibility for integrity and authentication of the
message to the communications protocol IDXP [4], not the message
format. However, in situations where IDPEF messages are
parameterization part of a local configuration file, or in cases
where the digital signatures MUST be archived for later use, the
inclusion of digital signatures within an IDPEF message itself may be
desirable.
Specifications for the use of digital signatures [14] within IDPEF
messages are outside the scope of this document. However, if such
functionality is needed, use of the XML signature standard is
RECOMMENDED.
8. IANA Considerations
The IDMEF is registered by the IANA. For the IDPEF there will be no
need to register the specifications by the IANA [15]. The individual
development and/or enhancement of the DTD and their attribute values
SHOULD offer more flexibility for the use of the IDPEF and the DTD
reference links to the Manager of the IDS composite. So no IANA
registrations will be aspired.
Boesch Expires July 12, 2015 [Page 42]
Internet-Draft The IDPEF January 2015
9. Conclusions
With IDPEF IDS are able to operate under one common independent IDS
Manager. As result, the IDS Manager was separated from the rest of an
IDS and could integrate Analyzers of different vendors and analyzing
levels.
Customizing of IDS could be due to a small amount of parameters and
values. Baseline configuration and references depend on the internal
processing and are not able to be standardized by a common format.
With a single central administration entity it is possible to
operate, manage, maintain and administer a heterogeneous IDS
composite based on a small format. All connections are initialized
from the central Manager to the distributed Analyzer entities. All
updates (parameter and software) could be controlled, downloaded and
distributed to each single IDS entity from one central management
entity.
Connections from an IDS Analyzer entity to a system outside the
administrative IDS LAN are not necessary. The Manager still defines
the border of autonomous acted IDS but the environment is not longer
vendor-specific. The Manager is an independent system of IDS and
could be separated from the rest of the IDS. It is possible to
operate different IDS with one consistently administration front end.
This enables new and independent evolution streams for IDS Analyzer
as well as Manager.
10. Acknowledgments
A great inspiration was the IDMEF document [2] from Debar, Curry and
Feinstein and the IDXP document [4] from Feinstein and Metthews.
For writing this document [8] and [15] are very helpful for the IANA
section.
This document was prepared using 2-Word-v2.0.template.dot.
Boesch Expires July 12, 2015 [Page 43]
Internet-Draft The IDPEF January 2015
Appendix A Examples
This section shows different scenarios of IDPEF data exchange. For
all communication progressions at least one example will be
presented.
A.1. Feature-Requests
With a feature-request the current parameter setting will be
requested from an Analyzer. This section describes possible forms of
feature-requests of the Manager:
A.1.1. Global Feature-Request
<?xml version="1.0" encoding="UTF-8"? >
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="request" device="testsensor4711">
</IDPEF:IDMEF-Message>
A.1.2. Entity Feature-Request
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="request" device="testsensor4711">
<entity></entity>
</IDPEF:IDPEF-Message>
A.1.3. Single Attribute Request
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="request" device="testsensor4711">
Boesch Expires July 12, 2015 [Page 44]
Internet-Draft The IDPEF January 2015
<entity version="" />
</IDPEF:IDPEF-Message>
A.1.4. Single Alert-Request (Port-Scan)
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="request" device="testsensor4711">
<alert>
<group name="pre-attacks">
<event name="port-scan" />
</group>
</alert>
</IDPEF:IDPEF-Message>
A.1.5. Multiple Alert Request
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="request" device="testsensor4711">
<alert>
<group name="pre-attacks">
<event name="port-scan" />
</group>
<group name="DoS-attacks">
<event name="Ping-of-Death" />
Boesch Expires July 12, 2015 [Page 45]
Internet-Draft The IDPEF January 2015
</group>
</alert>
</IDPEF:IDPEF-Message>
A.1.6. Global Alert-Request
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="request" device="testsensor4711">
<alert></alert>
</IDPEF:IDPEF-Message>
A.2. Feature-Replies
The feature reply is the response of the contacted system with the
requested information. In this section the replies correspond with
the feature request of the section before.
A.2.1. Global Feature-Reply
This reply is based on the feature-set of two identifiable alerts by
this IDS-entity.
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="reply" errorcode="100" device="testsensor4711">
<entity
analyzerID="testsensor4711"
domain="monitored.net"
name="testsensor-monitored-net-01"
Boesch Expires July 12, 2015 [Page 46]
Internet-Draft The IDPEF January 2015
model="IDS vendor123"
version="1.2.3a"
serialnr="1234567-1234"
license="09876543-0987"
expiration="2010-12-09"
time-zone="+01:00:00"
ntp-server="192.168.2.1,192.168.2.2, 2001:DB8::1044"
dns-server="192.168.2.1,192.168.2.2, 2001:DB8::1045"
class="active"
focus="network">
<network IP-address="192.168.2.8"
netmask="255.255.255.0"
gateway="192.168.2.1"
ifspeed="speed 100 duplex full autoneg off"
port="603"
protect="free description of monitored system or network"/>
<location floor="3"
room="3.111"
rack="15">
<address name="big-company ltd. "
street="Datacenter-lane"
number="10"
ZIP="12345"
city="security-village"/>
Boesch Expires July 12, 2015 [Page 47]
Internet-Draft The IDPEF January 2015
</location>
<tadmin contactname="securityteam 01">
<contact mobile="+44-7700-900456"
e-mail="security-team@example.com"
phone="+44-20-496-0123"
FAX="+44-20-496-0456"
TTS="Sec-Team03"
preferred="mobile"/>
<address name="big-company ltd. "
street="security-lane"
number="10"
ZIP="12345"
city="security-village"/>
</tadmin>
<fservice contactname="local-service04">
<contact mobile="+44-7700-900456"
e-mail="fservice-city@example.com"
phone="+44-20-496-0123"
FAX="+44-20-496-0456"
TTS="service-Team04"
preferred="TTS"/>
<address name="big-company ltd. "
street="Datacenter-lane"
number="10"
Boesch Expires July 12, 2015 [Page 48]
Internet-Draft The IDPEF January 2015
ZIP="12345"
city="security-village"/>
</fservice>
</entity>
<alert>
<group name ="group1">
<event name="port-scan"
impact="none"
severity="informational"
priority="3"
interface="qfe0"
interface="qfe2"
enable="yes">
frequency="20"
interval="60"
ngroup="portscan" >
<connection port="0-65535"
destination="*" />
</event>
<event
name="Denial-of-Service"
assessment="availability"
severity="high"
impact="DoS"
Boesch Expires July 12, 2015 [Page 49]
Internet-Draft The IDPEF January 2015
priority="220"
interface="qfe0"
interface="qfe2"
enable="yes">
frequency="20"
interval="900"
ngroup="DoS" >
</event>
</group>
<group name ="responses">
<react
enable="yes"
rid="DoS"
type="email"
structure="%s currently under Dos attack"
iaddress="192.168.3.4" />
</group>
</alert>
</IDPEF:IDMEF-Message>
A.2.2. Version-Reply
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
Boesch Expires July 12, 2015 [Page 50]
Internet-Draft The IDPEF January 2015
format="reply" errorcode="100"
device="testsensor4711">
<entity>
<version="10.3.x" />
</entity>
</IDPEF:IDPEF-Message>
A.2.3. Single Alert Feature-Reply (Port-Scan)
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="reply" errorcode="100"
device="testsensor4711">
<alert>
<group name ="pre-attacks">
<event name="port-scan"
impact="none"
severity="informational"
priority="3"
interface="qfe0"
interface="qfe2"
enable="yes">
frequency="20"
interval="60"
ngroup="portscan"
Boesch Expires July 12, 2015 [Page 51]
Internet-Draft The IDPEF January 2015
<connection port="0-65535"
destination="*" />
</event>
</group>
</alert>
</IDPEF:IDPEF-Message>
A.3. Entity Information Update
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="update" device="testsensor4711">
<entity
analyzerID="testsensor4711"
domain="monitored.net"
name="testsensor-monitored-net-01"
model="IDS vendor123"
version="1.2.3a"
serialnr="1234567-1234"
License="09876543-0987"
expiration="2010-12-09"
time-zone="+01:00:00"
ntp-server="192.168.2.1,192.168.2.2"
dns-server="192.168.2.1,192.168.2.2"
class="active"
Boesch Expires July 12, 2015 [Page 52]
Internet-Draft The IDPEF January 2015
focus="network" >
<network IP-address="192.168.2.8"
netmask="255.255.255.0"
gateway="192.168.2.1"
ifspeed="speed 100 duplex full autoneg off"
port="603"
protect="free description of monitored system or network"/>
<location floor="3"
room="3.111"
rack="15">
<address name="big-company ltd. "
street="Datacenter-lane"
number="10"
ZIP="12345"
city="security-village"/>
</location>
<tadmin contactname="securityteam 01">
<contact mobile="+44-7700-900456"
e-mail="security-team@example.com"
phone="+44-20-496-0123"
FAX="+44-20-496-0456"
TTS="Sec-Team03"
preferred="mobile" />
<address name="big-company ltd. "
Boesch Expires July 12, 2015 [Page 53]
Internet-Draft The IDPEF January 2015
street="security-lane"
number="10"
ZIP="12345"
city="security-village" />
</tadmin>
<fservice contactname="local-service04">
<contact mobile="+44-7700-900456"
e-mail="fservice-city@example.com"
phone="+44-20-496-0123"
FAX="+44-20-496-0456"
TTS="service-Team04"
preferred="TTS" />
<address name="big-company ltd. "
street="Datacenter-lane"
number="10"
ZIP="12345"
city="security-village" />
</fservice>
</entity>
</IDPEF:IDPEF-Message>
A.4. Analyzer-Update
The Analyzer-update sets the values of the alert-attributes. This
will be described with an update by one and by two update-files.
Boesch Expires July 12, 2015 [Page 54]
Internet-Draft The IDPEF January 2015
A.4.1. Single Update
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="update" device="testsensor4711">
<update ID="1234567890"
reference-time="13:45:30"
exec-time="20:00:00"
type="update" >
<update-file file="updatefile.rpm"
location="/usr/local/src"
notification="email_info_update"
ninfo="Update %u Status: %r" >
<data>
// binary Update file in base64 coded format
</data>
</update-file>
</update>
</IDPEF:IDPEF-Message>
A.4.2. Multiple Updates and Notifications
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="update" device="testsensor4711">
Boesch Expires July 12, 2015 [Page 55]
Internet-Draft The IDPEF January 2015
<update ID="1234567890"
reference-time="13:45:30"
exec-time="20:00:00"
type="update" >
<update-file file="updatefile1.rpm"
location="/usr/local/src"
rank="0"
notification="email_info_update"
ninfo="Update %u Part %t of %a Status: %r" >
<data>
// binary Update file in base64 coded format
</data>
</update-file>
<update-file file="updatefile2.rpm"
location="/usr/local/src"
rank="1"
notification="sms"
ninfo="Update %u Part %t of %a Status: %r" >
<data>
// binary Update file in base64 coded format
</data>
</update-file>
</update>
</IDPEF:IDPEF-Message>
Boesch Expires July 12, 2015 [Page 56]
Internet-Draft The IDPEF January 2015
A.4.3. Single Backup-Request
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="update" device="testsensor4711">
<update ID="1234567890"
reference-time="13:45:30"
exec-time="20:00:00"
type="backup"
notification="sms"
ninfo="Backup %u Status: %r" >
<update-file file="backupfile.zip"
location="/usr/local/src" />
</update-file>
</update>
</IDPEF:IDPEF-Message>
A.4.4. Single Backup-Reply
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="reply" errorcode="100"
device="testsensor4711">
<update ID="1234567890"
type="backup" >
Boesch Expires July 12, 2015 [Page 57]
Internet-Draft The IDPEF January 2015
<update-file file="backupfile.zip"
<data>
// binary restore file package in base64 coded format
</data>
</update-file>
</update>
</IDPEF:IDPEF-Message>
A.4.5. Single Backup-Restore
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="update" device="testsensor4711">
<update ID="1234567890"
reference-time="13:45:30"
exec-time="20:10:00"
type="restore" >
<update-file file="backupfile.zip"
location="/usr/local/src"
notification="sms_restore"
ninfo="Restore of sensor x.yy %result">
<data>
// binary restore file in base64 coded format
</data>
</update-file>
Boesch Expires July 12, 2015 [Page 58]
Internet-Draft The IDPEF January 2015
</update>
</IDPEF:IDPEF-Message>
A.5. Alert Parameterization
Within this section the update of alert-parameter will be described
by update of the port scan alert and a multi-update including a port-
scan and a denial-of-service alert.
A.5.1. Single Parameter-Update (Port-Scan)
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="update" device="testsensor4711">
<alert>
<group name ="pre-attacks">
<event name="port-scan"
impact="none"
severity="informational"
priority="3"
interface="qfe0"
interface="qfe2"
enable="yes"
frequency="20"
interval="60"
ngroup="portscan" >
</event>
</group>
Boesch Expires July 12, 2015 [Page 59]
Internet-Draft The IDPEF January 2015
</alert>
</IDPEF:IDPEF-Message>
A.5.2. Multiple Parameter Update
<?xml version="1.0" encoding="UTF-8"?>
<IDPEF:IDPEF-Message version="1.0"
xmlns:idpef="http://manager.example.org/idpef"
format="update" device="testsensor4711">
<alert>
<group name ="pre-attacks">
<event name="port-scan"
impact="none"
severity="informational"
priority="3"
interface="qfe0"
interface="qfe2"
enable="yes"
frequency="20"
interval="60"
ngroup="portscan"
<connection port="0-65535"
destination="*" />
</event>
</group>
<group name="DoS-Attacks">
Boesch Expires July 12, 2015 [Page 60]
Internet-Draft The IDPEF January 2015
<event
name="Denial-of-Service"
assessment="availability"
severity="high"
impact="200"
priority="220"
interface="qfe0"
interface="qfe2"
enable="yes"
frequency="20"
interval="900"
ngroup="DoS" />
</group>
</alert>
</IDPEF:IDPEF-Message>
Boesch Expires July 12, 2015 [Page 61]
Internet-Draft The IDPEF January 2015
Appendix B The IDPEF Document Type Definition (Normative)
<?xml version="1.0" encoding="UTF-8"?>
<!-- *************************************************************
*****************************************************************
*** Intrusion Detection Parameterization Exchange Format (IDPEF)***
*** XML Document Type Definition ***
*** Version 1.0, 07 July 2012 ***
*** ***
*** The use and extension of the IDPEF XML DTD are described in ***
*** XXXX, "Intrusion Detection Message Exchange Format Data ***
*** Model and Extensible Markup Language (XML) Document Type ***
*** Definition." B.-C. Boesch. ***
*******************************************************************
*************************************************************** -->
<!-- ===============================================================
===================================================================
=== SECTION 1: Attribute list declarations.
===================================================================
=============================================================== -->
<!--
Boesch Expires July 12, 2015 [Page 62]
Internet-Draft The IDPEF January 2015
| Attributes of the IDPEF element. In general, the fixed values of
| these attributes will change each time a new version of the DTD
| is released.
-->
<!ENTITY % attlist.idmef "
version CDATA #FIXED '1.0'
format (request | reply | update ) #REQUIRED
errorcode (100 | 200 | 300 | 400 )
device PCDATA #REQUIRED
">
<!--
| Attributes of all elements. These are the "XML" attributes that
| every element should have. Space handling, language, and name
| space.
-->
<!ENTITY % attlist.global "
xmlns:IDPEF CDATA #FIXED 'http://manager.example.org/IDPEF'
xmlns CDATA #FIXED 'http://manager.example.org/IDPEF'
xml:space (default | preserve) 'default'
xml:lang NMTOKEN #IMPLIED
">
Boesch Expires July 12, 2015 [Page 63]
Internet-Draft The IDPEF January 2015
<!-- ===============================================================
===================================================================
=== SECTION 2: Attribute value declarations. Enumerated values for
=== many of the element-specific attribute lists.
===================================================================
=============================================================== -->
<!--
| Values for active/passive attributes such as entity.type
-->
<!ENTITY % attvals.actpav "
( active | passive)
">
<!--
| Values for the contact.preferred attribute.
-->
<!ENTITY % attvals.cpreferred "
( mobile | e-mail | phone | FAX | TTS )
">
<!--
| Values for the alert.severity attribute.
-->
Boesch Expires July 12, 2015 [Page 64]
Internet-Draft The IDPEF January 2015
<!ENTITY % attvals.severityt "
( informational | low | medium | high | none )
">
<!--
| Values for the alert.impact attribute.
-->
<!ENTITY % attvals.impactvals "
(( confidence | integrity | availability )* | none )
">
<!--
| Values for yes/no attributes such as alert.enable
-->
<!ENTITY % attvals.yesno "
( yes | no )
">
<!--
| Values for update type attribute
-->
<!ENTITY % attvals.utype "
( update | backup | restore )
">
Boesch Expires July 12, 2015 [Page 65]
Internet-Draft The IDPEF January 2015
<!--
| Values for direction attribute
-->
<!ENTITY % attvals.direction "
( unidirectional | bidirectional )
">
<!-- ===============================================================
===================================================================
=== SECTION 3: Top-level element declarations: The IDPEF-Message
=== element and the types of messages it can include.
===================================================================
=============================================================== -->
<!ELEMENT IDPEF-Message (
(entity , alert , update)?
)>
<!ATTLIST IDPEF-Message
%attlist.global;
%attlist.idpef;
>
<!ELEMENT entity (
Boesch Expires July 12, 2015 [Page 66]
Internet-Draft The IDPEF January 2015
network, location*, tadmin*, fservice*
)>
<!ATTLIST entity
analyzerid PCDATA #REQUIRED
domain PCDATA #REQUIRED
name PCDATA #REQUIRED
version PCDATA #REQUIRED
model PCDATA #REQUIRED
serialnr PCDATA 'unknown'
license PCDATA 'unknown'
expiration PCDATA 'unknown'
time-zone CDATA #REQUIRED
ntp-server PCDATA 'unknown'
dns-server PCDATA 'unknown'
class %attvals.actpav #REQUIRED
focus PCDATA #REQUIRED
certificate PCDATA 'unknown'
protect PCDATA 'unknown'
>
<!ELEMENT update (
update-file*
)>
<!ATTLIST update
Boesch Expires July 12, 2015 [Page 67]
Internet-Draft The IDPEF January 2015
ID CDATA #REQUIRED '0'
reference-time time #OPTIONAL
exec-time time #REQUIRED
type %attvals.utype #REQUIRED
>
<!ELEMENT alert (
group*
)>
<!-- ===============================================================
===================================================================
=== SECTION 4: Child nodes of the entity element that provide more
=== data for specific types of the entity.
===================================================================
=============================================================== -->
<!ATTLIST network
IP-address PCDATA
netmask PCDATA
gateway PCDATA
ifspeed PCDATA
port CDATA #REQUIRED '603'
>
<!ELEMENT location (
Boesch Expires July 12, 2015 [Page 68]
Internet-Draft The IDPEF January 2015
address
)>
<!ATTLIST location
floor PCDATA 'unknown'
room PCDATA 'unknown'
rack PCDATA 'unknown'
position PCDATA 'unknown'
>
<!ELEMENT fservice (
contact, address
)>
<!ATTLIST fservice
contactname PCDATA #REQUIRED
>
<!ELEMENT tadmin (
contact, address
)>
<!ATTLIST tadmin
contactname PCDATA #REQUIRED
>
<!-- ===============================================================
===================================================================
Boesch Expires July 12, 2015 [Page 69]
Internet-Draft The IDPEF January 2015
=== SECTION 5: Child nodes of the update element that provide more
=== data for specific types of updates.
===================================================================
=============================================================== -->
<!ELEMENT update-file (
data
)>
<!ATTLIST update-file
filename PCDATA #REQUIRED
location PCDATA #REQUIRED
rank PCDATA #OPTIONAL
updateparameter PCDATA #REQUIRED
notification PCDATA 'none'
ninfo PCDATA 'none'
>
<!ELEMENT data #PCDATA >
<!-- ===============================================================
===================================================================
=== SECTION 6: Child nodes of the alert element that goups
=== the specific react and event nodes.
===================================================================
Boesch Expires July 12, 2015 [Page 70]
Internet-Draft The IDPEF January 2015
=============================================================== -->
<!ELEMENT group (
event*, react*
)>
<!ATTLIST group
name PCDATA #REQUIRED
>
<!-- ===============================================================
===================================================================
=== SECTION 6.1: Child nodes of the group element that provide more
=== data for specific types of alerts.
===================================================================
=============================================================== -->
<!ELEMENT event (
connection*, system*, ipara*
)>
<!ATTLIST event
enable %attvals.yesno 'yes' #REQUIRED
name PCDATA #REQUIRED
displayedas PCDATA #REQUIRED
impact %attvals.impactvals 'none'
Boesch Expires July 12, 2015 [Page 71]
Internet-Draft The IDPEF January 2015
severity %attvals.severiy 'high'
priority CDATA '1'
interface PCDATA 'all'
origin PCDATA 'unknown'
frequency CDATA '0'
interval CDATA '0'
ignore CDATA '0'
ngroup PCDATA 'unknown'
>
<!ATTLIST react
enable (yes|no) 'no' #REQUIRED
rid PCDATA #REQUIRED
type PCDATA #REQUIRED
structure PCDATA
iaddress PCDATA #REQUIRED
>
<!-- ===============================================================
===================================================================
=== SECTION 7. Support elements used for providing detailed info
=== about addresses, contacts, etc.
===================================================================
=============================================================== -->
Boesch Expires July 12, 2015 [Page 72]
Internet-Draft The IDPEF January 2015
<!ATTLIST address
name PCDATA 'unknown'
street PCDATA 'unknown'
number PCDATA 'unknown'
ZIP PCDATA 'unknown'
city PCDATA 'unknown'
country PCDATA 'unknown'
>
<!ATTLIST contact
mobile PCDATA 'unknown'
e-mail PCDATA 'unknown'
phone PCDATA 'unknown'
FAX PCDATA 'unknown'
TTS PCDATA 'unknown'
preferred %attvals.cpreferred #REQUIRED
>
<!-- ===============================================================
===================================================================
=== SECTION 8. Simple elements with sub-elements or attributes of a
=== special nature.
===================================================================
=============================================================== -->
Boesch Expires July 12, 2015 [Page 73]
Internet-Draft The IDPEF January 2015
<!ATTLIST connection
source PCDATA #REQUIRED
destination PCDATA #REQUIRED
port PCDATA #REQUIRED
direction %attvals.direction #REQUIRED
>
<!ATTLIST system
type PCDATA #REQUIRED
value PCDATA #REQUIRED
enable %attvals.yesno 'yes' #REQUIRED
>
<!ATTLIST ipara
enable %attvals.yesno 'yes' #REQUIRED
name PCDATA #REQUIRED
value PCDATA #REQUIRED
time (time)
>
<!-- ===============================================================
===================================================================
=== SECTION 9. Simple elements with no sub-elements and no special
Boesch Expires July 12, 2015 [Page 74]
Internet-Draft The IDPEF January 2015
=== attributes.
===================================================================
=============================================================== -->
<!ELEMENT iaddress (#PCDATA) >
<!ATTLIST iaddress %attlist.global; >
<!ELEMENT netmask (#PCDATA) >
<!ATTLIST netmask %attlist.global; >
<!ELEMENT string (#PCDATA) >
<!ATTLIST string %attlist.global; >
<!ELEMENT boolean (#PCDATA) >
<!ATTLIST boolean %attlist.global; >
<!ELEMENT byte (#PCDATA) >
<!ATTLIST byte %attlist.global; >
<!ELEMENT character (#PCDATA) >
<!ATTLIST character %attlist.global; >
<!ELEMENT time (#PCDATA) >
<!ATTLIST time %attlist.global; >
Boesch Expires July 12, 2015 [Page 75]
Internet-Draft The IDPEF January 2015
<!ELEMENT integer (#PCDATA) >
<!ATTLIST integer %attlist.global; >
<!-- End of IDPEF DTD -->
Boesch Expires July 12, 2015 [Page 76]
Internet-Draft The IDPEF January 2015
Appendix C The IDPEF Schema Definition (Non-normative)
<?xml version="1.0"?>
<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:idmef=http://manager.example.org/IDPEF
targetNamespace=http://manager.example.org/IDPEF
elementFormDefault="qualified" >
<xsd:annotation>
<xsd:documentation>
Intrusion Detection Parameterization Exchange Format
(IDPEF) Version 1.0
</xsd:documentation>
</xsd:annotation>
<!-- Section 1 -->
<!-Values for the format attribute -->
<xsd:simpleType name="format">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="request"/>
<xsd:enumeration value="reply"/>
<xsd:enumeration value="update"/>
</xsd:restriction>
</xsd:simpleType>
<!-Values for the errorcode attribute -->
<xsd:simpleType name="errorcode">
<xsd:restriction base="xsd:token">
Boesch Expires July 12, 2015 [Page 77]
Internet-Draft The IDPEF January 2015
<xsd:enumeration value="100"/>
<xsd:enumeration value="200"/>
<xsd:enumeration value="300"/>
<xsd:enumeration value="400"/>
</xsd:restriction>
<xsd:attribute name="device"
type="xsd=string"
use="required" />
<xsd:attribute name="version"
type="xsd=string"
value="1.0"
use="required" />
</xsd:simpleType>
<!-- Section 2 -->
<!-Values for the entity.class attribute -->
<xsd:simpleType name="type">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="active"/>
<xsd:enumeration value="passive"/>
</xsd:restriction>
</xsd:simpleType>
<!-Values for the update.type attribute -->
<xsd:simpleType name="utype">
<xsd:restriction base="xsd:token">
Boesch Expires July 12, 2015 [Page 78]
Internet-Draft The IDPEF January 2015
<xsd:enumeration value="update"/>
<xsd:enumeration value="backup"/>
<xsd:enumeration value="restore"/>
</xsd:restriction>
</xsd:simpleType>
<!-Values for the contact.preferred attribute -->
<xsd:simpleType name="preferred">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="mobile"/>
<xsd:enumeration value="e-mail"/>
<xsd:enumeration value="phone"/>
<xsd:enumeration value="FAX"/>
<xsd:enumeration value="TTS"/>
</xsd:restriction>
</xsd:simpleType>
<!-Values for the alert.severity attribute -->
<xsd:simpleType name="severity">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="informational"/>
<xsd:enumeration value="low"/>
<xsd:enumeration value="medium"/>
<xsd:enumeration value="high"/>
<xsd:enumeration value="none"/>
<xsd: restriction base="xsd:integer">
Boesch Expires July 12, 2015 [Page 79]
Internet-Draft The IDPEF January 2015
<xsd:minInclusive value="0"/>
<xs:maxInclusive value="255"/>
</xsd:restriction>
</xsd:restriction>
default = "high"
</xsd:simpleType>
<!-Values for the alert.impact attribute -->
<xsd:simpleType name="impact">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="confidence"/>
<xsd:enumeration value="integrity"/>
<xsd:enumeration value="availability"/>
</xsd:restriction>
default = "none"
</xsd:simpleType>
<!-Values for the alert.priority attribute -->
<xsd:simpleType name="priority">
<xsd: restriction base="xsd:integer">
<xsd:minInclusive value="1"/>
<xs:maxInclusive value="255"/>
</xsd:restriction>
default = "1"
</xsd:simpleType>
Boesch Expires July 12, 2015 [Page 80]
Internet-Draft The IDPEF January 2015
<!-Values for the alert_connection_direction attribute -->
<xsd:simpleType name="direction">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="bidirectional"/>
<xsd:enumeration value="unidirectional"/>
</xsd:restriction>
</xsd:simpleType>
<!-Values for the alert.enable attribute -->
<xsd:simpleType name="enable">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="yes"/>
<xsd:enumeration value="no"/>
</xsd:restriction>
</xsd:simpleType>
<!-Values for the Update.update-file.data attribute -->
<xsd:simpleType name="base64Binary" id="base64Binary">
<xsd:restriction base="xsd:anySimpleType">
<xsd:whiteSpace value="collapse" fixed="true"/>
</xsd:restriction>
</xsd:simpleType>
<!-- Section 3 -->
<!-Values for the IDPEF message -->
<xsd:simpleType name="IDPEF-Message">
<xsd:restriction base="xsd:token">
Boesch Expires July 12, 2015 [Page 81]
Internet-Draft The IDPEF January 2015
<xsd:enumeration value="entity"
minOccurs="0"
maxOccurs="1" />
<xsd:enumeration value="alert"
minOccurs="0"
maxOccurs="1" />
<xsd:enumeration value="update"
minOccurs="0"
maxOccurs="1" />
</xsd:restriction>
</xsd:simpleType>
<xsd:attribute type="xsd=IDPEF.global"
type="xsd=IDPEF.idpef" />
</xsd:simpleType>
<!-Values for the entity element -->
<xsd:complexType name="entity">
<xsd:sequence>
<xsd:element name="network"
type="xsd=IDPEF.network"
default="unknown"
minOccurs="1"
maxOccurs="1" />
<xsd:element name="location"
type="xsd=IDPEF.location"
Boesch Expires July 12, 2015 [Page 82]
Internet-Draft The IDPEF January 2015
default="unknown"
minOccurs="1"
maxOccurs="2" />
<xsd:element name="fservice"
type="xsd=IDPEF.fservice"
default="unknown"
minOccurs="0"
maxOccurs="1" />
<xsd:element name="tadmin"
type="xsd=IDPEF.tadmin"
default="unknown"
minOccurs="0"
maxOccurs="1" />
</xsd:sequence>
<xsd:attribute name="analyzerid"
type="xsd=string"
use="required" />
<xsd:attribute name="domain"
type="xsd=string"
use="required" />
<xsd:attribute name="name"
type="xsd=string"
use="required" />
<xsd:attribute name="version"
Boesch Expires July 12, 2015 [Page 83]
Internet-Draft The IDPEF January 2015
type="xsd=string"
use="required"
<xsd:attribute name="model"
type="xsd=string"
default="unknown"
use="required" />
<xsd:attribute name="serialnr"
type="xsd=string"
default="unknown"
use="required" />
<xsd:attribute name="license"
type="xsd=string"
default="unknown"
use="required" />
<xsd:attribute name="expiration"
type="xsd=string"
default="unknown"
use="required" />
<xsd:attribute name="time-zone"
type="xsd=IDPEF.time"
use="required" />
<xsd:attribute name="ntp-server"
type="xsd=string"
use="required" />
Boesch Expires July 12, 2015 [Page 84]
Internet-Draft The IDPEF January 2015
<xsd:attribute name="dns-server"
type="xsd=string"
use="required" />
<xsd:attribute name="class"
type="xsd=IDPEF.type"
default="unknown"
use="required" />
<xsd:attribute name="focus"
type="xsd=IDPEF.focus"
use="required" />
<xsd:attribute name="certificate"
type="xsd=string"
default="unknown"
use="required" />
<xsd:attribute name="protect"
type="xsd=string"
default="unknown"
use="required" />
</xsd:complexType>
<!-Values for the update element-->
<xsd:complexType name="update">
<xsd:sequence>
<xsd:element name="update-file"
type="xsd=IDPEF.update-file"
Boesch Expires July 12, 2015 [Page 85]
Internet-Draft The IDPEF January 2015
minOccurs="1"
maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="ID"
type="xsd=integer"
default="0"
use="required" />
<xsd:attribute name="reference-time"
type="xsd=IDPEF.time"
default="unknown" />
<xsd:attribute name="exec-time"
type="xsd=IDPEF.time"
use="required" />
<xsd:attribute name="type"
type="xsd=IDPEF.utype"
use="required" />
</xsd:complexType>
<!-Values for the alert element-->
<xsd:complexType name="alert">
<xsd:element name="event"
type="xsd=IDPEF.event"
minOccurs="0"
maxOccurs="unbounded" />
</xsd:complexType>
Boesch Expires July 12, 2015 [Page 86]
Internet-Draft The IDPEF January 2015
<!-- Section 4 -->
<!-Values for the network attribute -->
<xsd:complexType name="network">
<xsd:attribute name="IP-address"
type="xsd=idpef.ipaddress"
default="unknown" />
<xsd:attribute name="netmask"
type="xsd=idpef.netmask"
default="unknown" />
<xsd:attribute name="gateway"
type="xsd=idpef.ipaddress"
default="unknown" />
<xsd:attribute name="ifspeed"
type="xsd=string"
default="unknown" />
<xsd:attribute name="port"
type="xsd=idpef.port"
default="603"
use="required" />
</xsd:complexType>
<!-Values for the location attribute -->
<xsd:complexType name="location">
<xsd:sequence>
<xsd:element name="address"
Boesch Expires July 12, 2015 [Page 87]
Internet-Draft The IDPEF January 2015
type="xsd=IDPEF.address"
minOccurs="1"
maxOccurs="1" />
</xsd:sequence>
<xsd:attribute name="room"
type="xsd=string"
default="unknown" />
<xsd:attribute name="rack"
type="xsd=string"
default="unknown" />
<xsd:attribute name="floor"
type="xsd=string"
default="unknown" />
<xsd:attribute name="position"
type="xsd=string"
default="unknown" />
</xsd:complexType>
<!-Values for the field service attribute -->
<xsd:complexType name="fservice" >
<xsd:sequence>
<xsd:element name="contact"
type="xsd=IDPEF.contact"
minOccurs="1"
maxOccurs="1" />
Boesch Expires July 12, 2015 [Page 88]
Internet-Draft The IDPEF January 2015
</xsd:sequence>
<xsd:attribute name="contactname"
type="xsd=string"
default="unknown"
use="required" />
</xsd:complexType>
<!-Values for the technical admin attribute -->
<xsd:complexType name="tadmin">
<xsd:sequence>
<xsd:element name="contact"
type="xsd=IDPEF.contact"
minOccurs="1"
maxOccurs="1" />
</xsd:sequence>
<xsd:attribute name="contactname"
type="xsd=string"
default="unknown"
use="required" />
</xsd:complexType>
<!-- Section 5 -->
<!-Values for the update-file attribute -->
<xsd:complexType name="update-file">
<xsd:sequence>
<xsd:element name="data"
Boesch Expires July 12, 2015 [Page 89]
Internet-Draft The IDPEF January 2015
type="xsd=IDPEF.data"
minOccurs="1"
maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="filename"
type="xsd=string"
default="unknown"
use="required" />
<xsd:attribute name="location"
type="xsd=string"
default="unknown"
use="required"/>
<xsd:attribute name="rank"
type="xsd=integer"
default="0" />
<xsd:attribute name="updateparameter"
type="xsd=string"
default=""
use="required"/>
<xsd:attribute name="notification"
type="xsd=string"
default="none"
use="required"/>
<xsd:attribute name="ninfo"
Boesch Expires July 12, 2015 [Page 90]
Internet-Draft The IDPEF January 2015
type="xsd=string"
default="none"
use="required"/>
</xsd:complexType>
<!-- Section 6 -->
<!-Values for the group attribute -->
<xsd:complexType name="group">
<xsd:sequence>
<xsd:element name="event"
type="xsd=IDPEF.event"
minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="react"
type="xsd=IDPEF.react"
minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="name"
type="xsd=string"
default="unknown"
use="required" />
</xsd:complexType>
Boesch Expires July 12, 2015 [Page 91]
Internet-Draft The IDPEF January 2015
<!-- Section 6.1 -->
<!-Values for the event attribute -->
<xsd:complexType name="event">
<xsd:sequence>
<xsd:element name="connection"
type="xsd=IDPEF.connection"
minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="system"
type="xsd=IDPEF.system"
minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="ipara"
type="xsd=IDPEF.ipara"
minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="name"
type="xsd=string"
use="required" />
<xsd:attribute name="displayedas"
type="xsd=string"
use="required" />
Boesch Expires July 12, 2015 [Page 92]
Internet-Draft The IDPEF January 2015
<xsd:attribute name="severity"
type="xsd=IDPEF.severity"
default="none"
use="required" />
<xsd:attribute name="impact"
type="xsd= IDPEF.impact"
default="high"
use="required" />
<xsd:attribute name="priority"
type="xsd= IDPEF.priority"
default="1"
use="required" />
<xsd:simpleType name="interface">
</xsd:restriction>
use="required"
</xsd:simpleType>
<xsd:attribute name="enable"
type="xsd=IDPEF.yesno"
default="yes"
use="required" />
<xsd:attribute name="origin"
type="xsd=string"
default="unknown"
use="required" />
Boesch Expires July 12, 2015 [Page 93]
Internet-Draft The IDPEF January 2015
<xsd:attribute name="frequency"
type="xsd=integer"
default="0" />
<xsd:attribute name="interval"
type="xsd=integer"
default="0" />
<xsd:attribute name="ignore"
type="xsd=integer"
default="0" />
<xsd:attribute name="ngroup"
type="xsd=string"
default="unknown"
use="required" />
</xsd:complexType>
<!-Values for the react attribute -->
<xsd:complexType name="react">
<xsd:attribute name="enable"
type="xsd=IDPEF.yesno"
default="no"
use="required" />
<xsd:attribute name="rid"
type="xsd=string"
use="required" />
<xsd:attribute name="type"
Boesch Expires July 12, 2015 [Page 94]
Internet-Draft The IDPEF January 2015
type="xsd=string"
use="required" />
<xsd:attribute name="structure"
type="xsd=string" />
<xsd:attribute name="iaddress"
type="xsd=ipaddress"
use="required" />
</xsd:complexType>
<!-- Section 7 -->
<!-Values for the address attribute -->
<xsd:complexType name="address">
<xsd:attribute name="name"
type="xsd=string"
default="unknown" />
<xsd:attribute name="street"
type="xsd=string"
default="unknown" />
<xsd:attribute name="number"
type="xsd=string"
defaut="unknown" />
<xsd:attribute name="ZIP"
type="xsd=string"
default="unknown" />
Boesch Expires July 12, 2015 [Page 95]
Internet-Draft The IDPEF January 2015
<xsd:attribute name="city"
type="xsd=string"
default="unknown" />
<xsd:attribute name="country"
type="xsd=string"
default="unknown" />
</xsd:complexType>
<!-Values for the contact attribute -->
<xsd:complexType name="contact">
<xsd:attribute name="mobile"
type="xsd=string"
default="unknown" />
<xsd:attribute name="e-mail"
type="xsd=string"
default="unknown" />
<xsd:attribute name="phone"
type="xsd=string"
defaut="unknown" />
<xsd:attribute name="FAX"
type="xsd=string"
default="unknown" />
<xsd:attribute name="TTS"
type="xsd=string"
default="unknown" />
Boesch Expires July 12, 2015 [Page 96]
Internet-Draft The IDPEF January 2015
<xsd:attribute name="preferred"
type="xsd=IDPEF.cpreferred"
use="required" />
</xsd:complexType>
<!-- Section 8 -->
<!-Values for the data attribute of update-->
<xsd:complexType name="data"
type="xsd=IDPEF.Base64Binary" />
</xsd:complexType>
<!-- Section 8 -->
<!-Values for the connection, ipara and system attribute of
event-->
<xsd:complexType name="connection">
<xsd:attribute name="source"
type="xsd=ipaddress"
use="required" />
<xsd:attribute name="destination"
type="xsd=ipaddress"
use="required" />
<xsd:attribute name="port"
type=" xsd=string"
use="required" />
<xsd:attribute name="direction"
Boesch Expires July 12, 2015 [Page 97]
Internet-Draft The IDPEF January 2015
type="xsd=IDPEF.direction"
use="required" />
</xsd:complexType>
<xsd:complexType name="system">
<xsd:attribute name="type"
type="xsd=string" />
<xsd:attribute name="value"
type="xsd=string"
use="required" />
<xsd:attribute name="enable"
type="xsd=IDPEF.yesno"
use="required"
default ="yes" />
</xsd:complexType>
<xsd:complexType name="ipara">
<xsd:attribute name="name"
type="xsd=string"
use="required"
default="unknown" />
<xsd:attribute name="value"
type="xsd=string"
use="required" />
Boesch Expires July 12, 2015 [Page 98]
Internet-Draft The IDPEF January 2015
<xsd:attribute name="time"
type="xsd=string" />
<xsd:attribute name="enable"
type="xsd=IDPEF.yesno"
use="required" />
</xsd:complexType>
Boesch Expires July 12, 2015 [Page 99]
Internet-Draft The IDPEF January 2015
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Debar H., Curry, D., and Feinstein, B., "Intrusion Detection
Message Exchange Format", RfC4765, 2007.
[3] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange
Requirements", RFC 4766, March 2007.
[4] Feinstein, B., Matthews, G., "The Intrusion Detection Exchange
Protocol (IDXP) ", RFC 4767, March 2007.
[5] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
First Edition REC-xml-20001006, October 2000.
[6] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML",
W3C REC REC-xml-names-19990114, January 1999.
[7] International Organization for Standardization, "Data elements
and interchange formats - Information interchange -
Representation of dates and times", ISO Standard 8601, Second
Edition, December 2000.
[8] Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[9] Phillips, A. and Davis, M., "Matching of Language Tags", BCP
47, RFC 4647, September 2006.
[10] Hollenbeck, S., Rose, M., Masinter, L., "Guideline for the Use
of Extensible Markup Language (XML) within IETF Protocols",
BCP70, RfC 3470, January 2003
[11] Rose, M., "The Blocks Extensible Exchange Protocol Core", RfC
3080, March 2001
[12] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.2", RfC 5246, August 2008
[13] Myers, J., "Simple Authentication and Security Layer (SASL)",
RfC 2222, October 1997
Boesch Expires July 12, 2015 [Page 100]
Internet-Draft The IDPEF January 2015
11.2. Informative References
[14] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, March
2002.
[15] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
Intellectual Property Statement
Copyright (c) 2015 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Boesch Expires July 12, 2015 [Page 101]
Internet-Draft The IDPEF January 2015
C.1.1. Authors' Address
Bjoern-C. Boesch
Independent
undisclosed
Email: bjoernboesch@gmx.net
Boesch Expires July 12, 2015 [Page 102]