Internet DRAFT - draft-boesch-idxp-idpef

draft-boesch-idxp-idpef



Security Area                                         B.-C. Boesch
Internet Draft                                         independent
Intended status: Experimental                    February 28, 2016
Expires: August 2016





        Intrusion Detection Parametrization Exchange Format (IDPEF)


                      draft-boesch-idxp-idpef-04.txt


Status of this Memo

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt





Boesch             Expires August 28, 2016                  [Page 1]

Internet-Draft                The IDPEF                  February 2016


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 28, 2016.

   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.

Abstract

   The Intrusion Detection Parametrization Exchange Format (IDPEF)
   defines data formats and exchange procedures to standardize
   parametrization information exchange within intrusion detection and
   response systems from a Manager to an Analyzer.

   This Internet-Draft describes a data model to represent
   parametrization 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
   parametrization examples are provided.


















Boesch               Expires August 28, 2016               [Page 2]

Internet-Draft                The IDPEF                  February 2016


Table of Contents

   1. Introduction ................................................ 6
      1.1. Intention of this Format................................ 6
      1.2. Structure of this Document.............................. 7
      1.3. Rationale for IDPEF..................................... 7
         1.3.1. Problems Addressed by the Parametrization Data Model8
         1.3.2. Data Model Design Focus............................ 9
      1.4. Architecture Assumptions................................ 9
      1.5. Focus of Format........................................ 11
      1.6. Parametrization Methodology............................ 11
   2. The Communication Proceeding................................ 12
      2.1. Parametrization Communication.......................... 12
      2.2. Version Update on Hierarchical Lower IDS-Entities...... 13
   3. The IDPEF XML Implementation................................ 14
      3.1. Notational Conventions and Formatting Issues........... 15
      3.2. IDPEF XML Documents.................................... 16
         3.2.1. Character Data Processing in IDPEF................ 16
         3.2.2. Languages in IDPEF................................ 16
         3.2.3. The Document Header - The XML Declaration......... 16
      3.3. IDPEF Data Types....................................... 17
      3.4. Case-Sensitivity....................................... 17
   4. The IDPEF Parametrization Data Model........................ 17
      4.1. Overview .............................................. 17
      4.2. Message Nodes ......................................... 18
         4.2.1. IDPEF-Message..................................... 18
         4.2.2. The Entity Section................................ 20
            4.2.2.1. network...................................... 23
            4.2.2.2. address...................................... 25
            4.2.2.3. location..................................... 26
            4.2.2.4. contact...................................... 27
            4.2.2.5. fservice..................................... 28
            4.2.2.6. tadmin....................................... 29
         4.2.3. The Update Section................................ 29
            4.2.3.1. update-file.................................. 30
            4.2.3.2. data ........................................ 32
         4.2.4. The Alert Section................................. 32
            4.2.4.1. group........................................ 32
               4.2.4.1.1. event................................... 33
                  4.2.4.1.1.1. connection......................... 35
                  4.2.4.1.1.2. system............................. 37
                  4.2.4.1.1.3. ipara.............................. 37
               4.2.4.1.2. react................................... 38
   5. Extending the IDPEF ........................................ 39
   6. Special Considerations...................................... 40
      6.1. XML Validity and Well-Formed........................... 40
      6.2. Unrecognized XML Tags.................................. 41


Boesch               Expires August 28, 2016               [Page 3]

Internet-Draft                The IDPEF                  February 2016


   7. Security Considerations..................................... 41
      7.1. Privacy Considerations................................. 42
      7.2. Systems Security Issues................................ 43
      7.3. Communications Security Issues......................... 44
         7.3.1. Passive Attacks................................... 44
            7.3.1.1. Confidentiality Violations (Eavesdropping)... 44
            7.3.1.2. Password Sniffing............................ 45
            7.3.1.3. Offline Cryptographic Attacks................ 45
         7.3.2. Active Attacks.................................... 45
            7.3.2.1. Replay Attacks............................... 45
            7.3.2.2. Message Insertion............................ 45
            7.3.2.3. Message Deletion............................. 45
            7.3.2.4. Message Modification......................... 46
            7.3.2.5. Man-In-The-Middle............................ 46
         7.3.3. Topological Issues................................ 46
         7.3.4. Denial of Service................................. 46
      7.4. Digital Signatures..................................... 46
   8. IANA Considerations ........................................ 46
   9. Conclusions ................................................ 47
   10. Acknowledgments ........................................... 47
   APPENDIX A: Examples .......................................... 48
      A.1. Feature-Requests....................................... 48
         A.1.1. Global Feature-Request............................ 48
         A.1.2. Entity Feature-Request............................ 48
         A.1.3. Single Attribute Request.......................... 48
         A.1.4. Single Alert-Request (Port-Scan).................. 49
         A.1.5. Multiple Alert Request............................ 49
         A.1.6. Global Alert-Request.............................. 50
         A.1.7. Multiple Global Alert-Request..................... 50
         A.1.8. Global Alert-Request to sensor with individual IDPEF
         Port .................................................... 50
      A.2. Feature-Replies........................................ 51
         A.2.1. Global Feature-Reply.............................. 51
         A.2.2. Version-Reply..................................... 55
         A.2.3. Single Alert Feature-Reply (Port-Scan)............ 55
      A.3. Entity Information Update.............................. 56
      A.4. Analyzer-Update........................................ 59
         A.4.1. Single Update..................................... 59
         A.4.2. Multiple Updates and Notifications................ 60
         A.4.3. Single Backup-Request............................. 61
         A.4.4. Single Backup-Reply............................... 62
         A.4.5. Single Backup-Restore............................. 62
      A.5. Alert Parametrization.................................. 63
         A.5.1. Single Parameter-Update (Port-Scan)............... 63
         A.5.2. Multiple Parameter Update......................... 64
   APPENDIX B: The IDPEF Document Type Definition (Normative)..... 67
   APPENDIX C: The IDPEF Schema Definition (Non-normative)........ 83


Boesch               Expires August 28, 2016               [Page 4]

Internet-Draft                The IDPEF                  February 2016


   APPENDIX D: Change History.................................... 106
   11. References ............................................... 107
      11.1. Normative References................................. 107
      11.2. Informative References............................... 108
   Intellectual Property Statement............................... 108
         D.1.1. Author's Address................................. 108










































Boesch               Expires August 28, 2016               [Page 5]

Internet-Draft                The IDPEF                  February 2016


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 Parametrization Exchange Format (IDPEF) is
   intended to be a standard data format to parametrize Intrusion
   Detection Systems (IDS). The development of this standardized format
   and the Intrusion Detection Message Exchange Format (IDMEF) [2] are
   enabling 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 combined with
      server-IDS, WLAN-IDS and/or 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.

   o A common data exchange format would make it easier for different
      organizations (users, vendors, response teams, etc.) to not only
      exchange data, but also communicate about it.



Boesch               Expires August 28, 2016               [Page 6]

Internet-Draft                The IDPEF                  February 2016


   o The diversity of uses for the IDPEF needs to be considered when
      selecting its method of implementation.

   o Parametrization backups and restore of network basic configured
      (connected and reachable) 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 parametrization 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 sections 7 to 10 include IANA
   considerations, a short conclusion and acknowledgements.

   Appendix A provides some examples for IDPEF in such a way 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. 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 event signalization from Analyzer to Manager the
   Intrusion Detection Message Exchange Format (IDMEF) [2] was defined.

   Today, IDS are still 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 still needed for administration. This is a big
   barrier for an extensive IDS-integration in complex environments. It
   is important to standardize the communication and data exchange
   between Manager and Analyzer for administration and operations, to



Boesch               Expires August 28, 2016               [Page 7]

Internet-Draft                The IDPEF                  February 2016


   combine IDS-Analyzers with its 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 Parametrization 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 parametrization
      information and formats are vendor-specific. The data model that
      represents different parametrization 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. A
      standardized parametrization format makes it easier to exchange
      and auditing working results between IDS security specialists
      with different vendor focus.

   o Administrators are working with several specialized IDS-
      parametrization interfaces, sometimes distributed on separate
      systems. A standardized parametrization format helps to develop
      independent and consistent administration interfaces on one
      hardware platform. Administrators are then able to parametrize
      IDS of different vendors and analyzing levels by using one
      administration interface. As result, the best administration
      interface for the operations focus could be selected.





Boesch               Expires August 28, 2016               [Page 8]

Internet-Draft                The IDPEF                  February 2016


   o A standardized communication allows combining several vendors and
      IDS-entities to operate like one IDS. The best fitting Analyzer
      could 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 [13], will be
      enhanced.

1.3.2. Data Model Design Focus

   The data model is designed to provide standardized parametrization
   for IDS entities. It allows together with IDMEF to combine IDS-
   entities of different vendors and analyzing levels to one meta-IDS.

   IDPEF provides 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 parameters to an event vary 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-requests 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 parametrization 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 has 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 and database. The Manager is the entity, which acts


Boesch               Expires August 28, 2016               [Page 9]

Internet-Draft                The IDPEF                  February 2016


   as single point of administration for the complete system. It
   provides the Security Policy, receives the Event notifications and
   coordinates Response entities which could be separated from 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.





Boesch               Expires August 28, 2016               [Page 10]

Internet-Draft                The IDPEF                  February 2016


   The following points SHOULD NOT matter for the integration:

   o Whether Sensor and Analyzer are integrated or separated.

   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 mixed by multiple vendors or types.

1.5. Focus of Format

   The parametrization format is not designed to be used for initial
   setup or basic configuration of new/replaced hardware. The focus of
   the parametrization 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 parametrization and parametrization 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. Parametrization Methodology

   IDS compare 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). The references will be customized by baseline part 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 a
   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



Boesch               Expires August 28, 2016               [Page 11]

Internet-Draft                The IDPEF                  February 2016


   parametrization. IDPEF customizes the vendor-specific baseline-part
   to the individual implementation of the IDS entity.

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 by the transport protocol e.g. IDXP [4]. At
   least TLS 1.2 [11] and password protection of SASL [12] MUST be
   supported. 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 Parametrization status of Sensors if they are completely or only
      partial or not parameterized or have a mix of parametrization
      states.

   o If a Manager parameterize an Analyzer directly or over a second
      Manager.

2.1. Parametrization Communication

   A change of the Manager SHOULD be done with minimal impact and
   expenditure of work time. The Manager does not keep any feature or
   parameter information of Analyzers after the parametrization
   session. An information request is a good way to allow more than one
   Manager to administrate individual Analyzers. The parametrization
   proceeds global like:









Boesch               Expires August 28, 2016               [Page 12]

Internet-Draft                The IDPEF                  February 2016


   Manager:                                                   Analyzer:

   selection of

      Analyzer

   ---- begin of OPTIONAL request ----

                     -------parameter-request------>     preparation of

                                                         IDPEF response

                     <-------parameter-reply--------

   ---- end of OPTIONAL request ----

      change of

      parameters

                    -------parameter-update------->     update of para-

                                                         meters in the

                                                            Analyzer

   parametrization-   <-------parameter-reply--------

      check

2.2. Version Update on Hierarchical Lower IDS-Entities

   The parametrization 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 MUST be checked after every update execution and an
   update status MUST 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:






Boesch               Expires August 28, 2016               [Page 13]

Internet-Draft                The IDPEF                  February 2016


   Manager:                                             Analyzer:

   Version update

   Initialization

   ---- begin of OPTIONAL request ----

                     -------version request-------->

                     <-------version reply----------

   ---- 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:







Boesch               Expires August 28, 2016               [Page 14]

Internet-Draft                The IDPEF                  February 2016


   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 enable an easy
      processing of XML.

   o XML supports fully internationalization and localization for IT
      solutions that cross political and/or cultural boarders. XML
      enables a global usage to parameterize the Analyzer to the
      individual implementation and to maintain the IDS in operations.
      UTF-8 and UTF-16 make XML applications compatible with these
      common character encodings.

   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
      parametrization 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 in a way 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.




Boesch               Expires August 28, 2016               [Page 15]

Internet-Draft                The IDPEF                  February 2016


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. Character Data Processing in IDPEF

   The character processing was already defined for IDMEF [2], and will
   be also used analogue for IDPEF. This section recapitulates it here
   for better understanding:

   IDPEF compliant applications and messages SHOULD use the character
   encodings UTF-8 or UTF-16 only to grant portability. If no encoding
   is specified for an IDPEF message, UTF-8 will be assumed, consistent
   with the XML standard. At least UTF-8 MUST be supported. Not more
   than UTF-8 and UTF-16 SHOULD be used.

   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 [9]) 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 has
   to be supported for all IDPEF elements for white space processing
   [6].

3.2.2. 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 [8].
   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.2.3. 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.




Boesch               Expires August 28, 2016               [Page 16]

Internet-Draft                The IDPEF                  February 2016


   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 parametrization
   message. To reduce these negatives Analyzers and Managers agree on a
   particular DTD via a local reference to the accessing Manager.
   Therefore IDPEF messages have to as example start with:

   <?xml version="1.0" encoding="UTF-8"?>

   <IDPEF:IDPEF-version="1.0"

                    xmlns:idpef="http://manager.example.org/idpef"/>

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 explicate declared here.

   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 Parametrization Data Model

   This section illustrates the structure of the IDPEF parametrization
   and the relationship between single elements. The individual
   elements are explained in detail in the respective section of the
   parametrization nodes.

   The IDPEF parametrization model describes only the node structure of
   the parametrization 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".




Boesch               Expires August 28, 2016               [Page 17]

Internet-Draft                The IDPEF                  February 2016


   The "IDPEF-Message" node is structured in the three sections
   "entity", "alert" and "update". Each section focuses on detailed
   parametrization information for global analyzer information, event
   parametrization and updates.

   +------------------------------------------------------------+
   |                           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 node is the top-level of the IDPEF data model. All
   IDPEF parametrization 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 August 28, 2016               [Page 18]

Internet-Draft                The IDPEF                  February 2016


   <!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 parametrization.

   device

     REQUIRED: This attribute defines on which device the
     parametrization has to be applied. This attribute supports multi-
     hop parametrization. In case of a change of "analyzer-ID"/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 (,). In case
     of a port other than the standard port the port will be specified


Boesch               Expires August 28, 2016               [Page 19]

Internet-Draft                The IDPEF                  February 2016


     by a double point (:) after the device name (i.e.
     analyzer.example.com:603 or 192.168.2.1:603).

4.2.2. The Entity Section

   The "entity" node specifies the IDS entity. It includes basic
   information about the entity itself and contains also additional
   information about the environment of the device. Figure 2
   illustrates the sub-node 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 additional 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

       analyzer-ID     PCDATA               #REQUIRED

       domain          PCDATA               #REQUIRED

       name            PCDATA               #REQUIRED

       version         PCDATA               #REQUIRED

       model           PCDATA               #REQUIRED

       manufacturer    PCDATA               #IMPLIED

       ostype          PCDATA               #IMPLIED

       osversion       PCDATA               #IMPLIED

       serialnr        PCDATA               'unknown'

       license         PCDATA               'unknown'



Boesch               Expires August 28, 2016               [Page 20]

Internet-Draft                The IDPEF                  February 2016


       expiration      PCDATA               'unknown'

       time-zone       CDATA                #REQUIRED

       ntp-server      PCDATA               'unknown'

       dns-server      PCDATA               'unknown'

       class           (active|passive)     #REQUIRED

       focus            PCDATA              #REQUIRED

       certificate      PCDATA              'unknown'

       protect          PCDATA              'unknown'

   >

   Each entity node includes the individual attributes:

   analyzer-ID

     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 attribute characterizes the Analyzer's soft-
     and/or hardware.




Boesch               Expires August 28, 2016               [Page 21]

Internet-Draft                The IDPEF                  February 2016


   manufacturer

     OPTIONAL: Manufacturer of the Analyzer's soft- and/or hardware.
     Set by the Analyzer to identify the manufacturer for update
     selection.

   ostype

     OPTIONAL: Operating systems type of the Analyzer. On POSIX 1003.1
     compliant systems, is this the value returned in utsname.sysname
     by the uname() system call, or the output of the "uname -s"
     command. This is a read-only attribute and will be set
     automatically by the IDS-entity itself to identify the os type for
     update selections. This value is case-sensitive.

   osversion

     OPTIONAL: Operating systems version of the Analyzer. On POSIX
     1003.1 compliant systems, is this the value returned in
     utsname.release by the uname() system call, or the output of the
     "uname -r" command. This is a read-only attribute and will be set
     automatically by the IDS-entity itself to identify the current os
     version for update selections. This value is case-sensitive.

   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 used the value is "none". This value is case-sensitive.

   expiration

     Exactly one data string: Indicates the expiration date of the
     license (date or "never"). The date format is yyyy/mm/dd.

   time-zone

     Exactly one time-string: Difference of local time to UTC.
     (+/-00:00)






Boesch               Expires August 28, 2016               [Page 22]

Internet-Draft                The IDPEF                  February 2016


   ntp-server

     Exactly one string: IP-addresses of the NTP servers in dotted
     notation (IPv4 or IPv6) or server name. Multiple entries are
     separated by comma (,).

   dns-server

     Exactly one string: IP-addresses of the DNS servers in dotted
     notation (IPv4 or IPv6). Multiple entries are separated by comma
     (,).

   class

     REQUIRED: This attribute specifies global, if this entity executes
     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 for the Manager. 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.

4.2.2.1. network

   Network configuration parameters of the IDS management interface of
   the entity will be summarized in this node. The network node is
   represented in the IDPEF DTD as:

     <!ATTLIST network

         IP-address      PCDATA               #OPTIONAL



Boesch               Expires August 28, 2016               [Page 23]

Internet-Draft                The IDPEF                  February 2016


         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 exclusive IDS
     management interface is in place, this attribute value MUST NOT be
     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 exclusive IDS management interface is in
     place, this attribute value MUST NOT be 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 exclusive IDS management
     interface is in place, this attribute value MUST NOT be set.

   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 exclusive IDS management interface
     is in place, this attribute value MUST NOT be set.

   port


Boesch               Expires August 28, 2016               [Page 24]

Internet-Draft                The IDPEF                  February 2016


     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 has 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.

   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.



Boesch               Expires August 28, 2016               [Page 25]

Internet-Draft                The IDPEF                  February 2016


   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 different postal addresses this
   node will be used multiple times. The node "location" is represented
   in the IDPEF DTD as:

   <!ELEMENT location    (

       address

   )>

   <!ATTLIST location

       floor      PCDATA      'unknown'

       room       PCDATA      'unknown'

       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.



Boesch               Expires August 28, 2016               [Page 26]

Internet-Draft                The IDPEF                  February 2016


   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'

       preferred  (mobile|e-mail|phone|FAX|TTS)    #REQUIRED

   >

   mobile

     OPTIONAL, but SHOULD be set: Provides the mobile phone number of
     the contact.




Boesch               Expires August 28, 2016               [Page 27]

Internet-Draft                The IDPEF                  February 2016


   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     (

        contact, address

   )>

   <!ATTLIST fservice

       contactname      PCDATA      #REQUIRED

   >



Boesch               Expires August 28, 2016               [Page 28]

Internet-Draft                The IDPEF                  February 2016


   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 an unique ID, execution- and
   reference-time have be set. Additional the update files, update
   schedule and update notification are defined.

   This node will be represented in the IDPEF DTD as:

   <!ELEMENT update     (

        update-file*

   )>



Boesch               Expires August 28, 2016               [Page 29]

Internet-Draft                The IDPEF                  February 2016


   <!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 refers to the
     system time of the entity.

   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
     "update-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



Boesch               Expires August 28, 2016               [Page 30]

Internet-Draft                The IDPEF                  February 2016


   the result notification of each update file execution. 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 on the
     local updated IDS entity. This value is case-sensitive.

   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: Specifies the update-schedule by numeration.




Boesch               Expires August 28, 2016               [Page 31]

Internet-Draft                The IDPEF                  February 2016


   notification

     OPTIONAL: "notification" refers to the attribute "response-ID" 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 groups for parametrization of events
   and reactions. The "alert" section is used to group and parameterize
   single "event" and the "react" nodes for signalizations or
   responses. The "alert" section structures all "event" and "react"
   nodes by "group" nodes. The "alert" section will be represented in
   the IDPEF DTD as:

     <!ELEMENT alert     (

          group*

     )>



4.2.4.1. group

   The node "group" contains the parametrization 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. 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*

     )>


Boesch               Expires August 28, 2016               [Page 32]

Internet-Draft                The IDPEF                  February 2016


   <!ATTLIST group

       name            PCDATA               #REQUIRED

   name

     REQUIRED: This attribute defines the identification for the group.
     This value is case-sensitive.

4.2.4.1.1. event

   In the "event" node all customizing parameters to an alert will be
   defined. This node based on the nodes "connection", "system" and
   "ipara".

   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

       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'



Boesch               Expires August 28, 2016               [Page 33]

Internet-Draft                The IDPEF                  February 2016


       interval       CDATA                      '0'

       ignore         CDATA                      '0'

       ngroup         PCDATA                     'unknown'

   >

   Each "event" node contains these 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 unique
     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.

   impact

     OPTIONAL: This attribute specifies, which security value
     (preferred: "confidence", "integrity", "availability" and/or
     "none") would be affected primary 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 attack 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 connections
     overload. In case of multiple detections of several simultaneous


Boesch               Expires August 28, 2016               [Page 34]

Internet-Draft                The IDPEF                  February 2016


     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. Multiple interfaces are
     separated by a comma (,). This value is case-sensitive.

   origin

     OPTIONAL: Reference link to more information 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 be occur or a percentage value (threshold
     or change), before the event will be raised.

   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. The node "connection" will be represented in the
   IDPEF DTD as:




Boesch               Expires August 28, 2016               [Page 35]

Internet-Draft                The IDPEF                  February 2016


   <!ATTLIST connection

       source         PCDATA                           #REQUIRED

       destination    PCDATA                           #REQUIRED

       port           PCDATA                           #REQUIRED

       direction      (bidirectional|unidirectional)   #REQUIRED

   >

   Each "connection" node could contain these four attributes:

   source

     REQUIRED: This attribute defines initiating IP-addresses of the
     connection. It will be used in dotted form with OPTIONAL "/" for
     the 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.

   destination

     REQUIRED: This attribute defines destination IP-addresses of the
     connection. It will be used in dotted form with OPTIONAL "/" for
     the 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").






Boesch               Expires August 28, 2016               [Page 36]

Internet-Draft                The IDPEF                  February 2016


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.

   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. It makes
   it possible to set individual parameter names which are not
   predefined. The "ipara" node provides the attributes "name", "value"
   and "time". The DTD representation for this node is:

   <!ATTLIST ipara

       enable        (yes|no)      'yes'     #Required

       name          PCDATA                  #Required

       value         PCDATA                  #Required

       time          (time)                               >


Boesch               Expires August 28, 2016               [Page 37]

Internet-Draft                The IDPEF                  February 2016


   This node could include these 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 parameters
     of the individual attribute "name". 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
     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 parametrization depends primary 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

       response-ID PCDATA                    #REQUIRED

       type        PCDATA                    #REQUIRED

       structure   PCDATA

       iaddress    PCDATA                    #REQUIRED

   >



Boesch               Expires August 28, 2016               [Page 38]

Internet-Draft                The IDPEF                  February 2016


   The "react" node could contain the five attributes:

   enable

     REQUIRED: The "enable" attribute defines if this alert is active
     or not ("yes" or "no").

   response-ID

     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 to
     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/
     event signalization only.

   structure

     OPTIONAL: Some notification contents have 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. Also IDPEF
   has to support state of the art requirements of research projects.

   To fulfill these requirements IDPEF will be extended by using the
   individual parameter option "ipara". This technique is designed in a
   way that adding new data will not require a change to the base IDPEF
   schema and supports a lot of variants to extend the IDPEF.

   If the extension with the "ipara" section does not provide needed
   extension of IDPEF this section discusses how additional new data
   elements that have no current representation in the data model could
   be incorporated into the IDPEF. These techniques are designed in


Boesch               Expires August 28, 2016               [Page 39]

Internet-Draft                The IDPEF                  February 2016


   such a way that adding new data will not require a change to the
   base IDPEF schema. This approach also supports extension of values
   and attribute-names and an extension with specially marked
   attributes and values is not necessary.

   For example, an extended instance of the attributes of the event
   class with the "ipara" option would look as follows:

   <alert>

     <group name ="group1">

       <event name="port-scan"   [....]     ngroup="portscan" >

         <connection port="0-65535" destination="*" />

         <ipara enable="yes" name="increase" value="20" time="1000"/>

       </event>

     </group>

   </alert>

6. Special Considerations

6.1. XML Validity and Well-Formed

   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


Boesch               Expires August 28, 2016               [Page 40]

Internet-Draft                The IDPEF                  February 2016


   could not process correctly. A not valid document is not suited for
   a proper parameter transfer. Therefore IDPEF documents MUST be
   valid. Documents which are not valid abet misparametrizations and
   will be not processed or applied.

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 parametrization of the entity
   will be sent back as reply message. Within the replied IDPEF message
   the error code has to be set with the error codes:

              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 parametrization.

7. Security Considerations

   IDPEF itself does not treat security matters directly. It is only an
   exchange format to standardize and structure parametrization
   information of IDS. The data encoded by the IDPEF might be
   considered privacy sensitive information. Therefore care needs to be
   taken in ensuring the appropriate disclosure during both document
   exchange and subsequent processing entities.

   IDPEF could be used local by the IDS software or in combination with
   a transport protocol like IDXP [4] between Manager and Analyzers.
   The exchange of the information MUST be handled by a transport
   protocol, but the latter risk must be addressed by the systems that
   process, store, and archive IDPEF data and information derived from
   them.

   The underlying messaging format and protocol used to exchange
   instances of the IDPEF MUST provide appropriate guarantees of


Boesch               Expires August 28, 2016               [Page 41]

Internet-Draft                The IDPEF                  February 2016


   confidentiality, integrity, and authenticity. The use of a
   standardized security protocol is encouraged. The security
   considerations are provided by e.g. IDXP [4], TLS [10] and SASL
   [12]. At least TLS 1.2 [11] and password authentication MUST be
   used.

   After the submission of IDPEF, care must be taken by the parser to
   properly authenticate the recipient of the document and ascribe an
   appropriate confidence to the data prior to action. Summarized
   considerations are made here:

7.1. Privacy Considerations

   Privacy is primary focused on information relating to an individual
   or information which makes it possible to identify an individual.
   Based on local law this could be defined very different. In this
   context IP-addresses (of Analyzer and Manager as well as IP-
   addresses for customizing the reference database) are not classified
   as personnel information. The Administrator manages Analyzers of the
   IDS over the Manager as intermediate with an individual user
   interface.

   The IDPEF standardizes the information exchange between Manager and
   Analyzer. A trust relationship exists between these two
   communication peers. The Manager controls the parametrization rights
   of each individual (access control). The Manager entity acts as
   intermediate between the Administrator and the Analyzer and provides
   an individual user interface for the Administrator. A correct
   identification and admission control of the individual Administrator
   MUST be provided by the Manager. The authorization of the individual
   Administrator on the manager entity is beyond the scope of IDPEF.

   A correct processing of the information of IDPEF is part of the IDS
   applications (Analyzer and Manager). Attributes and values that
   could not be processed correctly MUST be signalized as described in
   2.1. Parametrization Communication. Based on the parametrization
   check the difference MUST be displayed to the Administrator. This
   supports a check of the input (input control) to avoid
   misparametrization of attributes and values.

   The IDPEF is designed that the Manager holds no data permanently
   about the parametrization of any Analyzer. Therefore the Manager has
   to request the actual parametrization if needed. It is up to the
   Analyzer application to store and protect the IDPEF information in a
   safe environment and protects it against unattended access
   (confidentiality) and modifications (integrity).



Boesch               Expires August 28, 2016               [Page 42]

Internet-Draft                The IDPEF                  February 2016


   It is assumed that the entities (Manager and Analyzer) are located
   in a safe environment with a physical access control. The IDPEF is
   created to parametrize IDS in a common structured way. To achieve
   most interoperability all values are set in clear text. The IDPEF
   information MUST be safely processed and stored (e.g. encrypted) by
   the Analyzer application after receive. During the transport the
   transport protocol MUST ensure appropriate confidence and integrity
   for all IDPEF information. The logical access control has to be
   handled also by the transport protocol to ensure that the Manager
   will be authorized to set the transmitted parameters.

   Analyzers provide requested information to any authorized Manager.
   If there has to be set a transmission control, a proxy gateway
   (intermediate handler) e.g. a Manager has to be set up at the border
   to control the transmitted IDPEF parameters. The Manager (acting as
   intermediate handler) checks and controls the transmitted
   information to and from the peering Manager. The Manager (acting as
   Administrator interface) MUST identify and control the input of the
   individual Administrator (admission control).

   IDPEF may contain personnel information (team names or names of
   individuals, e-mail-addresses and/or telephone numbers) in the
   entity section. It is not required but recommended to set these
   attributes. It is up to the Administrator to decide if any of these
   values is set or not. This information is intended to be used by the
   Analyzer application for signalization of events or defects.
   Therefore a subsequent transmission might be possible of this
   personnel information. The Administrator should be aware who is able
   to request the information and where the information will be
   transmitted by the Analyzer. If these attributes are used, the
   Administrator has to care that these values are not in conflict with
   local law (on site of the Analyzer and the Manager as well as his
   local site).

   In any case the Analyzer application MUST grant confidence,
   availability and integrity of received, processed, and stored IDPEF
   information. Confidence and integrity of the IDPEF information
   during the communication between Analyzer and Manager has to be
   granted by the transport protocol. The subsequent sections are
   focused on several security issues and its prevention during the
   transport.

7.2. Systems Security Issues

   The local usage of IDPEF data (i.e. stored in IDS configuration
   files) MUST be protected at least against unauthorized usage,
   inappropriate usage and/or Denial of Service. Confidentiality and


Boesch               Expires August 28, 2016               [Page 43]

Internet-Draft                The IDPEF                  February 2016


   integrity of local IDPEF configuration files MUST be handled in
   responsibility of the particular IDS software. A peer entity
   authentication within closed local software is RECOMMENDED. To
   provide most flexibility the IDS software MUST choose which
   mechanisms are adequate and has to ensure that its IDS configuration
   files (IDPEF) is sufficient and state of the art protected.

   The remote provisioning of IDPEF data MUST be protected against
   unauthorized and inappropriate usage. All transmitted IDPEF
   information has to be accepted from the Analyzers. The Manager has
   to ensure, that only appropriate IDPEF 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.3. 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 e.g. 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 transport protocol has to provide separate mechanisms for
   transport security, user authentication, and secure data exchange.
   The transport protocol e.g. IDXP profile MUST offer the REQUIRED
   security properties. At least TLS 1.2 [11] and SASL MUST be used to
   provide transport security for IDPEF data. TLS supported cipher
   suites provide varying levels of security. Administrators SHOULD use
   the strongest cipher suite but SHOULD also carefully choose which
   cipher suites are provisioned.

7.3.1. Passive Attacks

7.3.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.






Boesch               Expires August 28, 2016               [Page 44]

Internet-Draft                The IDPEF                  February 2016


7.3.1.2. Password Sniffing

   IDPEF MAY also handle authentication information among others. 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 IDXP. IDPEF MUST
   NOT used without the TLS and SASL options of the transport protocol.

7.3.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. IDXP has to be used with the
   TLS 1.2 [11] and SASL option.

7.3.2. Active Attacks

7.3.2.1. Replay Attacks

   To protect messages against replay IDPEF will be transmitted with
   TLS [10] option of IDXP [4]. The appropriate level of security MUST
   be chosen by the administrator carefully. To protect application
   data refer to Appendix F2 of [10] for a discussion of security
   considerations.

7.3.2.2. Message Insertion

   To protect messages against insertions IDPEF will be transmitted
   with TLS [10] option of IDXP [4]. The appropriate level of security
   MUST be chosen by the administrator carefully. To protect
   application data refer to Appendix F of [10] for a discussion of
   security considerations.

7.3.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.

   Transport layer of IDXP provides additional mechanisms to ensure a
   correct message transport to the peer entity.



Boesch               Expires August 28, 2016               [Page 45]

Internet-Draft                The IDPEF                  February 2016


7.3.2.4. Message Modification

   To protect messages against modification IDPEF will be transmitted
   with TLS [10] option of IDXP [4]. The appropriate level of security
   MUST be chosen by the administrator carefully. To protect
   application data refer to Appendix F2 of [10] for a discussion of
   security considerations.

7.3.2.5. Man-In-The-Middle

   IDPEF MUST be transported with TLS and SASL options of IDXP.

7.3.3. Topological Issues

   Architectural solutions like firewalls and separated networks keep
   the IDS communication in a WALLED GARDEN to make the communication
   safer. This protects also against Denial of Service attacks.

7.3.4. Denial of Service

   None of these security measures provide any real protection against
   denial of service. Based on the transport layer security (SASL and
   TLS 1.2) of the transport protocol e.g. IDXP [4], it is possible to
   limit a variety of attacks on individual connections using forged
   RSTs or other kinds of packet injection.

7.4. 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
   parametrization 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 [13] 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 already. IDPEF will be used
   local in closed environments primary. DTD reference links
   preferential to the Manager of the IDS composite.



Boesch               Expires August 28, 2016               [Page 46]

Internet-Draft                The IDPEF                  February 2016


   For the IDPEF there will be no need to register the specifications
   by the IANA [14]. 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. The individual submission route of the RfC editor
   accepts no IANA registrations and so no IANA registrations will be
   aspired.

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 configurations 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 [14] and [15] are very helpful for the
   IANA section.

   This document was prepared using 2-Word-v2.0.template.dot.



Boesch               Expires August 28, 2016               [Page 47]

Internet-Draft                The IDPEF                  February 2016


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:IDPEF-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 August 28, 2016               [Page 48]

Internet-Draft                The IDPEF                  February 2016


      <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 August 28, 2016               [Page 49]

Internet-Draft                The IDPEF                  February 2016


       </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.1.7. Multiple 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, testsensor4712, testsensor4713">

      <alert></alert>

   </IDPEF:IDPEF-Message>

A.1.8. Global Alert-Request to sensor with individual IDPEF Port

   <?xml version="1.0" encoding="UTF-8"?>

   <IDPEF:IDPEF-Message version="1.0"

                         xmlns:idpef="http://manager.example.org/idpef"

                         format="request" device="testsensor4711:608">

      <alert></alert>

   </IDPEF:IDPEF-Message>


Boesch               Expires August 28, 2016               [Page 50]

Internet-Draft                The IDPEF                  February 2016


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

          analyzer-ID="testsensor4711"

          domain="monitored.net"

          name="testsensor-monitored-net-01"

          model="IDS vendor123"

          version="1.2.3a"

          manufacturer="xy"

          ostype="GNU/Linux"

          osversion="2.6.18-194.e15PAE"

          serialnr="1234567-1234"

          license="09876543-0987"


          expiration="2010-12-09"

          time-zone="+01:00:00"



Boesch               Expires August 28, 2016               [Page 51]

Internet-Draft                The IDPEF                  February 2016


          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"/>

           </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"


Boesch               Expires August 28, 2016               [Page 52]

Internet-Draft                The IDPEF                  February 2016


              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"

               ZIP="12345"

               city="security-village"/>

           </fservice>

        </entity>

        <alert>

        <group name ="group1">


Boesch               Expires August 28, 2016               [Page 53]

Internet-Draft                The IDPEF                  February 2016


         <event name="port-scan"

          impact="none"

          severity="informational"

          priority="3"

          interface="qfe0, 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"

          priority="220"

          interface="qfe0, qfe2"

          enable="yes">

          frequency="20"

          interval="900"

          ngroup="DoS" >

         </event>


Boesch               Expires August 28, 2016               [Page 54]

Internet-Draft                The IDPEF                  February 2016


        </group>

        <group name ="responses">

         <react

          enable="yes"

          response-ID="DoS"

          type="email"

          structure="%s currently under Dos attack"

          iaddress="192.168.3.4" />

        </group>

        </alert>

   </IDPEF:IDPEF-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"

                        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"


Boesch               Expires August 28, 2016               [Page 55]

Internet-Draft                The IDPEF                  February 2016


                         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, qfe2"

          enable="yes">

          frequency="20"

          interval="60"

          ngroup="portscan"

          <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"


Boesch               Expires August 28, 2016               [Page 56]

Internet-Draft                The IDPEF                  February 2016


                        format="update" device="testsensor4711">

        <entity

          analyzer-ID="testsensor4711"

          domain="monitored.net"

          name="testsensor-monitored-net-01"

          model="IDS vendor123"

          version="1.2.3a"

          manufacturer="xy"

          ostype="GNU/Linux"

          osversion="2.6.18-194.e15PAE"

          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"

          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"/>


Boesch               Expires August 28, 2016               [Page 57]

Internet-Draft                The IDPEF                  February 2016


          <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. "

              street="security-lane"

              number="10"

              ZIP="12345"

              city="security-village" />

           </tadmin>

           <fservice contactname="local-service04">

             <contact mobile="+44-7700-900456"


Boesch               Expires August 28, 2016               [Page 58]

Internet-Draft                The IDPEF                  February 2016


               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.

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"



Boesch               Expires August 28, 2016               [Page 59]

Internet-Draft                The IDPEF                  February 2016


           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">

        <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"


Boesch               Expires August 28, 2016               [Page 60]

Internet-Draft                The IDPEF                  February 2016


             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>

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"


Boesch               Expires August 28, 2016               [Page 61]

Internet-Draft                The IDPEF                  February 2016


           type="backup"

           notification="sms"

           ninfo="Backup %u Status: %r" >

           <update-file file="backupfile.zip"

             location="/usr/local/src" />

        </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" >

         <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"?>


Boesch               Expires August 28, 2016               [Page 62]

Internet-Draft                The IDPEF                  February 2016


   <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>

      </update>

   </IDPEF:IDPEF-Message>

A.5. Alert Parametrization

   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"


Boesch               Expires August 28, 2016               [Page 63]

Internet-Draft                The IDPEF                  February 2016


                         format="update" device="testsensor4711">

       <alert>

        <group name ="pre-attacks">

         <event name="port-scan"

          impact="none"

          severity="informational"

          priority="3"

          interface="qfe0, qfe2"

          enable="yes"

          frequency="20"

          interval="60"

          ngroup="portscan" >

         </event>

        </group>

       </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"


Boesch               Expires August 28, 2016               [Page 64]

Internet-Draft                The IDPEF                  February 2016


          impact="none"

          severity="informational"

          priority="3"

          interface="qfe0, qfe2"

          enable="yes"

          frequency="20"

          interval="60"

          ngroup="portscan" >

          <connection port="0-65535"

           destination="*" />

         </event>

        </group>

        <group name="DoS-Attacks">

         <event

          name="Denial-of-Service"

          assessment="availability"

          severity="high"

          impact="200"

          priority="220"

          interface="qfe0, qfe2"

          enable="yes"

          frequency="20"

          interval="900"

          ngroup="DoS" />


Boesch               Expires August 28, 2016               [Page 65]

Internet-Draft                The IDPEF                  February 2016


        </group>

       </alert>

   </IDPEF:IDPEF-Message>











































Boesch               Expires August 28, 2016               [Page 66]

Internet-Draft                The IDPEF                  February 2016


APPENDIX B: The IDPEF Document Type Definition (Normative)



      <?xml version="1.0" encoding="UTF-8"?>



   <!-- *************************************************************

    *****************************************************************

    *** Intrusion Detection Parametrization 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 August 28, 2016               [Page 67]

Internet-Draft                The IDPEF                  February 2016




      <!--

     | 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'



Boesch               Expires August 28, 2016               [Page 68]

Internet-Draft                The IDPEF                  February 2016


        xml:space     (default | preserve)       'default'

        xml:lang      NMTOKEN            #IMPLIED

      ">





    <!--
   ===============================================================


   ===================================================================

     === 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             "


Boesch               Expires August 28, 2016               [Page 69]

Internet-Draft                The IDPEF                  February 2016


          ( mobile | e-mail | phone | FAX | TTS )

        ">



      <!--

       | Values for the alert.severity attribute.

       -->

      <!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 )

        ">




Boesch               Expires August 28, 2016               [Page 70]

Internet-Draft                The IDPEF                  February 2016


      <!--

       | Values for update type attribute

       -->

      <!ENTITY % attvals.utype                "

          ( update | backup | restore )

        ">



      <!--

       | 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                 (


Boesch               Expires August 28, 2016               [Page 71]

Internet-Draft                The IDPEF                  February 2016


          (entity , alert , update)?

        )>

      <!ATTLIST IDPEF-Message

          %attlist.global;

          %attlist.idpef;

        >



   <!ELEMENT entity (

       network, location*, tadmin*, fservice*

   )>

   <!ATTLIST entity

       analyzer-ID     PCDATA               #REQUIRED

       domain          PCDATA               #REQUIRED

       name            PCDATA               #REQUIRED

       version         PCDATA               #REQUIRED

       model           PCDATA               #REQUIRED

       manufacturer    PCDATA               #IMPLIED

       ostype          PCDATA               #IMPLIED

       osversion       PCDATA               #IMPLIED

       serialnr        PCDATA               'unknown'

       license         PCDATA               'unknown'

       expiration      PCDATA               'unknown'

       time-zone       CDATA                #REQUIRED

       ntp-server      PCDATA               'unknown'


Boesch               Expires August 28, 2016               [Page 72]

Internet-Draft                The IDPEF                  February 2016


       dns-server      PCDATA               'unknown'

       class           %attvals.actpav      #REQUIRED

       focus           PCDATA               #REQUIRED

       certificate     PCDATA               'unknown'

       protect         PCDATA               'unknown'

   >



      <!ELEMENT update     (

           update-file*

      )>

      <!ATTLIST update

          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


Boesch               Expires August 28, 2016               [Page 73]

Internet-Draft                The IDPEF                  February 2016


     ===            data for specific types of the entity.


   ===================================================================

     =============================================================== --
   >



   <!ATTLIST network

       IP-address      PCDATA

       netmask         PCDATA

       gateway         PCDATA

       ifspeed         PCDATA

       port            CDATA      #REQUIRED       '603'

   >

   <!ELEMENT location    (

       address

   )>

   <!ATTLIST location

       floor         PCDATA      'unknown'

       room          PCDATA      'unknown'

       rack          PCDATA      'unknown'

       position      PCDATA      'unknown'

   >



   <!ELEMENT fservice     (

        contact, address


Boesch               Expires August 28, 2016               [Page 74]

Internet-Draft                The IDPEF                  February 2016


   )>

   <!ATTLIST fservice

       contactname         PCDATA      #REQUIRED

   >



   <!ELEMENT tadmin     (

        contact, address

   )>

   <!ATTLIST tadmin

       contactname         PCDATA      #REQUIRED

   >

    <!--
   ===============================================================


   ===================================================================

     === SECTION 5: Child nodes of the update element that provide more

     ===            data for specific types of updates.


   ===================================================================

     =============================================================== --
   >



   <!ELEMENT update-file     (

        data

   )>

   <!ATTLIST update-file


Boesch               Expires August 28, 2016               [Page 75]

Internet-Draft                The IDPEF                  February 2016


       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.


   ===================================================================

     =============================================================== --
   >



      <!ELEMENT group     (

           event*, react*

      )>

   <!ATTLIST group

       name          PCDATA      #REQUIRED


Boesch               Expires August 28, 2016               [Page 76]

Internet-Draft                The IDPEF                  February 2016


   >



   <!-- ===============================================================


   ===================================================================

     === 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'

       severity       %attvals.severiy                       'high'

       priority       CDATA                                  '1'

       interface      PCDATA                                 'all'

       origin         PCDATA                                 'unknown'

       frequency      CDATA                                  '0'


Boesch               Expires August 28, 2016               [Page 77]

Internet-Draft                The IDPEF                  February 2016


       interval       CDATA                                  '0'

       ignore         CDATA                                  '0'

       ngroup         PCDATA                                 'unknown'

   >



   <!ATTLIST react

       enable      (yes|no)       'no'     #REQUIRED

       response-ID  PCDATA                 #REQUIRED

       type         PCDATA                 #REQUIRED

       structure    PCDATA

       iaddress     PCDATA                 #REQUIRED

   >



    <!--
   ===============================================================


   ===================================================================

     === SECTION 7. Support elements used for providing detailed info

     ===            about addresses, contacts, etc.


   ===================================================================

     =============================================================== --
   >



   <!ATTLIST address

       name        PCDATA      'unknown'


Boesch               Expires August 28, 2016               [Page 78]

Internet-Draft                The IDPEF                  February 2016


       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 August 28, 2016               [Page 79]

Internet-Draft                The IDPEF                  February 2016




   <!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)

   >



    <!--
   ===============================================================


   ===================================================================


Boesch               Expires August 28, 2016               [Page 80]

Internet-Draft                The IDPEF                  February 2016


     === SECTION 9. Simple elements with no sub-elements and no special

     === 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;  >




Boesch               Expires August 28, 2016               [Page 81]

Internet-Draft                The IDPEF                  February 2016


      <!ELEMENT time              (#PCDATA)         >

      <!ATTLIST time              %attlist.global;  >



      <!ELEMENT integer           (#PCDATA)         >

      <!ATTLIST integer           %attlist.global;  >



      <!-- End of IDPEF DTD -->



































Boesch               Expires August 28, 2016               [Page 82]

Internet-Draft                The IDPEF                  February 2016


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 Parametrization 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 August 28, 2016               [Page 83]

Internet-Draft                The IDPEF                  February 2016


               <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 August 28, 2016               [Page 84]

Internet-Draft                The IDPEF                  February 2016


               <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 August 28, 2016               [Page 85]

Internet-Draft                The IDPEF                  February 2016


                 <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 August 28, 2016               [Page 86]

Internet-Draft                The IDPEF                  February 2016


            <!-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 August 28, 2016               [Page 87]

Internet-Draft                The IDPEF                  February 2016


               <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 August 28, 2016               [Page 88]

Internet-Draft                The IDPEF                  February 2016


                             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="analyzer-ID"

                             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 August 28, 2016               [Page 89]

Internet-Draft                The IDPEF                  February 2016


                             type="xsd=string"

                             use="required"

               <xsd:attribute name="model"

                             type="xsd=string"

                             default="unknown"

                             use="required" />

               <xsd:attribute name="manufacturer"

                             type="xsd=string"

                             default="unknown" />

               <xsd:attribute name="ostype"

                             type="xsd=string"

                             default="unknown" />

               <xsd:attribute name="osversion"

                             type="xsd=string"

                             default="unknown" />

               <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"


Boesch               Expires August 28, 2016               [Page 90]

Internet-Draft                The IDPEF                  February 2016


                             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" />

               <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"


Boesch               Expires August 28, 2016               [Page 91]

Internet-Draft                The IDPEF                  February 2016


                             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"

                             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"


Boesch               Expires August 28, 2016               [Page 92]

Internet-Draft                The IDPEF                  February 2016


                             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>

        <!-- 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" />


Boesch               Expires August 28, 2016               [Page 93]

Internet-Draft                The IDPEF                  February 2016


               <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"

                             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"


Boesch               Expires August 28, 2016               [Page 94]

Internet-Draft                The IDPEF                  February 2016


                             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" />

              </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"


Boesch               Expires August 28, 2016               [Page 95]

Internet-Draft                The IDPEF                  February 2016


                             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"

                             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" />


Boesch               Expires August 28, 2016               [Page 96]

Internet-Draft                The IDPEF                  February 2016


               <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"

                             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"


Boesch               Expires August 28, 2016               [Page 97]

Internet-Draft                The IDPEF                  February 2016


                             minOccurs="0"

                             maxOccurs="unbounded" />

              </xsd:sequence>

               <xsd:attribute name="name"

                             type="xsd=string"

                             default="unknown"

                             use="required" />

            </xsd:complexType>



        <!-- 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"


Boesch               Expires August 28, 2016               [Page 98]

Internet-Draft                The IDPEF                  February 2016


                             minOccurs="0"

                             maxOccurs="unbounded" />

              </xsd:sequence>

               <xsd:attribute name="name"

                             type="xsd=string"

                             use="required" />

               <xsd:attribute name="displayedas"

                             type="xsd=string"

                             use="required" />

               <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"


Boesch               Expires August 28, 2016               [Page 99]

Internet-Draft                The IDPEF                  February 2016


               </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" />

               <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 -->


Boesch               Expires August 28, 2016               [Page 100]

Internet-Draft                The IDPEF                  February 2016


            <xsd:complexType name="react">

               <xsd:attribute name="enable"

                             type="xsd=IDPEF.yesno"

                             default="no"

                             use="required" />

               <xsd:attribute name="response-ID"

                             type="xsd=string"

                             use="required" />

               <xsd:attribute name="type"

                             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" />


Boesch               Expires August 28, 2016               [Page 101]

Internet-Draft                The IDPEF                  February 2016


               <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" />

               <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" />


Boesch               Expires August 28, 2016               [Page 102]

Internet-Draft                The IDPEF                  February 2016


               <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" />

               <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"



Boesch               Expires August 28, 2016               [Page 103]

Internet-Draft                The IDPEF                  February 2016


                             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"

                             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>


Boesch               Expires August 28, 2016               [Page 104]

Internet-Draft                The IDPEF                  February 2016




            <xsd:complexType name="ipara">

               <xsd:attribute name="name"

                             type="xsd=string"

                             use="required"

                             default="unknown" />

               <xsd:attribute name="value"

                             type="xsd=string"

                             use="required" />

               <xsd:attribute name="time"

                             type="xsd=string" />

               <xsd:attribute name="enable"

                             type="xsd=IDPEF.yesno"

                             use="required" />

            </xsd:complexType>



















Boesch               Expires August 28, 2016               [Page 105]

Internet-Draft                The IDPEF                  February 2016


APPENDIX D: Change History

   Changes from January 12, 2015 version to April 11, 2015 version:

   o Typo-correction of "parameterization" to "parametrization".

   o Add of "manufacturer", "ostype" and "osversion" attributes for
      closer alignment with IDMEF and improved selection of Analyzer
      criteria.

   Changes from April 11, 2015 version to October 18, 2015 version:

   o Several typo and grammar corrections.

   o Correction of ToC misalignment.

   o Drop out of BEEP usage (more common and open to transport
      protocols)

   o More precise to UFT-8 and UTF-16 usage in section 3.2.1

   o Add Privacy Conditions

   o Check to align with RfC5070-bis-14

   o Update IANA Considerations (section8)

   o Minor changes for better reading and understanding

   Changes from October 18, 2015 version to November 21, 2015 version:

   o Add informational reference RfC 6973 to list

   o Move Privacy Considerations to Security Consideration's section
      and rewrite privacy section

   o Corrections of XML format in example Appendix.

   Changes from November 21, 2015 version to February 28, 2016 version:

   o Change back IANA Considerations (section8) that it fits to
      individual submission route (No IANA actions)







Boesch               Expires August 28, 2016               [Page 106]

Internet-Draft                The IDPEF                  February 2016


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]  Phillips, A. and Davis, M., "Matching of Language Tags", BCP
         47, RFC 4647, September 2006.

   [9]  Hollenbeck, S., Rose, M., Masinter, L., "Guideline for the Use
         of Extensible Markup Language (XML) within IETF Protocols",
         BCP70, RfC 3470, January 2003

   [10] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS)
         Protocol Version 1.2", RfC 5246, August 2008

   [11] Sheffer, Y., Holz, R., P. Saint-Andre, P., "Recommendations
         for Secure Use of Transport Layer Security (TLS) and Datagram
         Transport Layer Security (DTLS) ", RfC 5725, May 2015

   [12] Myers, J., "Simple Authentication and Security Layer (SASL)",
         RfC 2222, October 1997





Boesch               Expires August 28, 2016               [Page 107]

Internet-Draft                The IDPEF                  February 2016


11.2. Informative References

   [13] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
         Language) XML-Signature Syntax and Processing", RFC 3275,
         March 2002.

   [14] Freed, N. and J. Postel, "IANA Charset Registration
         Procedures", BCP 19, RFC 2978, October 2000.

   [15] Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

   [16] Cooper, A., Tschofenig, H., et al.,"Privacy Considerations for
         Internet Protocols", RfC 6973, July 2013



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).



D.1.1. Author's Address

   Bjoern-C. Boesch
   Independent,
   undisclosed
   Germany

   Email: bjoernboesch@gmx.net











Boesch               Expires August 28, 2016               [Page 108]