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