Network Working Group G. Lehmann Internet-Draft Telecom SudParis Obsoletes: 4765 (if approved) T. Andrejak Intended status: Experimental Bytes'n AI Expires: 27 April 2027 24 October 2026 The Incident Detection Message Exchange Format version 2 (IDMEFv2) draft-lehmann-idmefv2-09 Abstract The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This draft is maintained by the IDMEFv2 Task Force. Please consult our website for more information: https://www.idmefv2.org. If approved this draft will obsolete RFC4765. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 27 April 2027. Lehmann & Andrejak Expires 27 April 2027 [Page 1] Internet-Draft IDMEFv2 October 2026 Copyright Notice Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. IDMEFv2 deployment architecture . . . . . . . . . . . . . 6 1.2. IDMEFv1 (Intrusion Detection Message Exchange Format) - RFC 4765 - Legacy . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Relationship between IDMEFv2 and other event/incident formats . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Existing Deployments and Adoption . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Normative sections . . . . . . . . . . . . . . . . . . . 8 2.3. Concepts related to event processing . . . . . . . . . . 8 2.3.1. Event . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Incident . . . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Alert . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.4. Manager . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.5. Operator . . . . . . . . . . . . . . . . . . . . . . 9 2.3.6. Analyst . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.7. Attack . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.8. Correlation . . . . . . . . . . . . . . . . . . . . . 10 2.3.9. Aggregation . . . . . . . . . . . . . . . . . . . . . 10 3. The IDMEF Data Types . . . . . . . . . . . . . . . . . . . . 10 3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Integers . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Floating-point values . . . . . . . . . . . . . . . . 10 3.3. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Enumerations . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Timestamps . . . . . . . . . . . . . . . . . . . . . 11 3.3.3. Geographical Locations . . . . . . . . . . . . . . . 12 3.3.4. UNECE Location Codes (UN/LOCODE) . . . . . . . . . . 12 3.3.5. Uniform Resource Identifiers (URIs) . . . . . . . . . 12 3.3.6. IP Addresses . . . . . . . . . . . . . . . . . . . . 13 Lehmann & Andrejak Expires 27 April 2027 [Page 2] Internet-Draft IDMEFv2 October 2026 3.3.7. E-mail addresses . . . . . . . . . . . . . . . . . . 13 3.3.8. Attachment names . . . . . . . . . . . . . . . . . . 13 3.3.9. Media types . . . . . . . . . . . . . . . . . . . . . 13 3.3.10. Universally Unique IDentifiers (UUIDs) . . . . . . . 14 3.3.11. Protocol Names . . . . . . . . . . . . . . . . . . . 14 3.3.12. IDMEF Paths . . . . . . . . . . . . . . . . . . . . . 14 3.3.13. Hashes . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. The IDMEF extension . . . . . . . . . . . . . . . . . . . . . 16 4.1. Extending the Enumerated Values of Attributes . . . . . . 16 4.1.1. Private Extension of Enumerated Values . . . . . . . 17 4.1.2. Public Extension of Enumerated Values . . . . . . . . 17 4.2. Private Extension of Attributes . . . . . . . . . . . . . 18 5. The IDMEF Data Model . . . . . . . . . . . . . . . . . . . . 18 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. The Alert Class . . . . . . . . . . . . . . . . . . . . . 19 5.3. The Analyzer Class . . . . . . . . . . . . . . . . . . . 28 5.4. The Sensor Class . . . . . . . . . . . . . . . . . . . . 30 5.5. The Source Class . . . . . . . . . . . . . . . . . . . . 32 5.6. The Target Class . . . . . . . . . . . . . . . . . . . . 35 5.7. The Attachment Class . . . . . . . . . . . . . . . . . . 37 5.8. The JavaScript Object Notation Serialization Method . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Normative References . . . . . . . . . . . . . . . . . . 43 9.2. Informative References . . . . . . . . . . . . . . . . . 44 Appendix A. Using IDMEFv2 in Dynamic Environments . . . . . . . 45 A.1. The Dynamic Asset Problem . . . . . . . . . . . . . . . . 45 A.2. Complementary Identification Attributes . . . . . . . . . 46 A.2.1. ID . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.2.2. IP . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.2.3. Hostname . . . . . . . . . . . . . . . . . . . . . . 47 A.2.4. Locator . . . . . . . . . . . . . . . . . . . . . . . 47 A.3. Platform-Specific Resource References . . . . . . . . . . 48 A.3.1. Kubernetes . . . . . . . . . . . . . . . . . . . . . 48 A.3.2. Docker and Podman . . . . . . . . . . . . . . . . . . 50 A.3.3. Google Cloud GKE . . . . . . . . . . . . . . . . . . 50 A.3.4. AWS ECS . . . . . . . . . . . . . . . . . . . . . . . 51 A.3.5. Microsoft Azure AKS . . . . . . . . . . . . . . . . . 52 A.3.6. HashiCorp Nomad . . . . . . . . . . . . . . . . . . . 52 A.4. Scope of the Service Attribute . . . . . . . . . . . . . 53 A.5. Temporal Context and Historical Retention . . . . . . . . 53 A.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54 Appendix B. IDMEFv2 Alert Signature Specification . . . . . . . 55 B.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 55 B.2. Signature Format: JWS Compact Serialization . . . . . . . 56 Lehmann & Andrejak Expires 27 April 2027 [Page 3] Internet-Draft IDMEFv2 October 2026 B.2.1. Structure . . . . . . . . . . . . . . . . . . . . . . 56 B.2.2. Protected Header . . . . . . . . . . . . . . . . . . 56 B.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 56 B.3. Signed Attributes and Payload Construction . . . . . . . 57 B.3.1. Path Syntax . . . . . . . . . . . . . . . . . . . . . 57 B.3.2. Payload Structure (Normative) . . . . . . . . . . . . 57 B.3.3. Absent or Invalid Attributes . . . . . . . . . . . . 58 B.3.4. Constraints on SignedAttributes . . . . . . . . . . . 58 B.4. Attributes Added to the Alert Class . . . . . . . . . . . 58 B.4.1. SignedAttributes . . . . . . . . . . . . . . . . . . 58 B.4.2. Signature . . . . . . . . . . . . . . . . . . . . . . 58 B.4.3. Consistency . . . . . . . . . . . . . . . . . . . . . 59 B.5. Attribute Order: Not Significant . . . . . . . . . . . . 59 B.6. Normalization: JSON Canonicalization Scheme (JCS) . . . . 59 B.6.1. JCS Rules . . . . . . . . . . . . . . . . . . . . . . 59 B.6.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 59 B.7. Signature Algorithms . . . . . . . . . . . . . . . . . . 59 B.7.1. Supported Algorithms . . . . . . . . . . . . . . . . 59 B.7.2. Excluded Algorithms . . . . . . . . . . . . . . . . . 60 B.7.3. Verification Policy . . . . . . . . . . . . . . . . . 60 B.8. Key Management . . . . . . . . . . . . . . . . . . . . . 60 B.8.1. Key Identification . . . . . . . . . . . . . . . . . 60 B.8.2. Key Representation . . . . . . . . . . . . . . . . . 61 B.8.3. Key Distribution . . . . . . . . . . . . . . . . . . 61 B.9. Verification Procedure . . . . . . . . . . . . . . . . . 61 B.10. Security Considerations . . . . . . . . . . . . . . . . . 62 B.10.1. Key Protection . . . . . . . . . . . . . . . . . . . 62 B.10.2. Algorithm Agility . . . . . . . . . . . . . . . . . 62 B.10.3. Replay Attacks . . . . . . . . . . . . . . . . . . . 62 B.10.4. Key Rotation . . . . . . . . . . . . . . . . . . . . 62 B.11. Complete Example . . . . . . . . . . . . . . . . . . . . 62 B.12. Conformance and Test Vectors . . . . . . . . . . . . . . 63 B.13. References . . . . . . . . . . . . . . . . . . . . . . . 63 B.13.1. Normative References . . . . . . . . . . . . . . . . 64 B.13.2. Informative References . . . . . . . . . . . . . . . 64 Appendix C. Enumerations . . . . . . . . . . . . . . . . . . . . 64 C.1. Entity Sector . . . . . . . . . . . . . . . . . . . . . . 64 C.2. Alert Category . . . . . . . . . . . . . . . . . . . . . 76 C.3. Analyzer Category . . . . . . . . . . . . . . . . . . . . 113 C.4. Analyzer Data . . . . . . . . . . . . . . . . . . . . . . 128 C.5. Analyzer Method . . . . . . . . . . . . . . . . . . . . . 131 C.6. Source Category . . . . . . . . . . . . . . . . . . . . . 136 C.7. Target Category . . . . . . . . . . . . . . . . . . . . . 150 Appendix D. Examples . . . . . . . . . . . . . . . . . . . . . . 152 D.1. Physical intrusion . . . . . . . . . . . . . . . . . . . 153 D.2. Cyberattack . . . . . . . . . . . . . . . . . . . . . . . 154 D.3. Server outage . . . . . . . . . . . . . . . . . . . . . . 155 D.4. Combined incident . . . . . . . . . . . . . . . . . . . . 156 Lehmann & Andrejak Expires 27 April 2027 [Page 4] Internet-Draft IDMEFv2 October 2026 D.5. Hazard incident . . . . . . . . . . . . . . . . . . . . . 158 Appendix E. JSON Validation Schema (Non-normative) . . . . . . . 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 187 1. Introduction The Incident Detection Message Exchange Format (IDMEF) is intended to solve the problem of security monitoring compartmentalization by proposing a single format to represent any type of incident, whether cyber or physical, intentional or accidental, natural or man-made. Indeed security is often associated to the Confidentiality-Integrity- Availability triad, performance and availability management systems are still run independently from security management systems. Additionally, with the adoption and integration of Internet of Things (IoT) and Industrial Internet of Things (IIoT) devices, and the exponential emergence of smart systems (transport, cities, buildings, etc), an increasingly interconnected mesh of cyber-physical systems (CPS) has emerged. This expansion of the attack and incident surfaces blurs the once-clear functions of cybersecurity and physical security. Finally, as IT infrastructure moves out of data centers it becomes more exposed to external threats, including natural and man-made hazards. Incident detection systems have traditionally focused on detecting cyber incidents or physical incident or availability incidents. There is an increasing need nowadays to have a unified view and management of all those incidents and their interconnection. To achieve this goal the Incident Detection Message Exchange Format offers a unique data representation for multiple types of events: * Cyber-security events (e.g. authentication failure/success, virus/ malware detection, bruteforce/scan detection, etc.) * Physical security events (e.g. intrusion detection, object detection, face or activity recognition, fire/smoke/noise/rain detection, etc.) * Availability/observability/performance events (e.g. system failure, service malfunction, performance decrease, etc.) * Natural and man made hazards events (e.g. wildfires, avalanches, droughts, earthquakes, pollution, fire, explosion, etc.) Lehmann & Andrejak Expires 27 April 2027 [Page 5] Internet-Draft IDMEFv2 October 2026 1.1. IDMEFv2 deployment architecture IDMEFv2 can be used to exchange incident detection information between specialized managers (SIEM, PSIM, NMS) and a universal "Cyber & Physical SIEM" (CPSIEM) or directly from specialized analyzers and a CPSIEM. +-----------------------------+ +---------+ | "Universal" CPSIEM |<---| Hazards | +-----------------------------+ +---------+ | | | +------+ +-----+ +------+ Managers | PSIM | | NMS | | SIEM | +------+ +-----+ +------+ | | | +--------+ +----------+ +-----+ Analyzers/Sensors |Physical| |Monitoring| |Cyber| +--------+ +----------+ +-----+ | | | +-------------------------------+ | Cyber & Physical System | +-------------------------------+ Figure 1: IDMEF Use Architecture IDMEFv2 improves situational awareness by enabling correlation of multiple types of events using the same base format. This document defines a model serialization methods for the purpose of describing and sharing these events. 1.2. IDMEFv1 (Intrusion Detection Message Exchange Format) - RFC 4765 - Legacy IDMEFv2 (Incident Detection Message Exchange Format) is based on IDMEFv1 (Intrusion Detection Message Exchange Format) concepts. But IDMEFv1 was cyber intrusion focused as IDMEFv2 perimeter is much larger. Thus retro-compatibility although partly possible has not been a priority. 1.3. Relationship between IDMEFv2 and other event/incident formats IDMEFv2 focuses essentialy on high level event/incident correlation and detection.There are many standard and proprietary formats on the incident detection market and in particular on the cybersecurity market. IDMEFv2 is complementary to most of these formats. Lehmann & Andrejak Expires 27 April 2027 [Page 6] Internet-Draft IDMEFv2 October 2026 IDMEFv1 (Intrusion Detection Message Exchange Format - RFC 4765) : IDMEFv2 (Incident Detection) replaces and obsoletes IDMEFv1 (Intrusion Detection) by covering a wider spectrum. IODEFv2 (Incident Object Definition Exchange Format - RFC 5070) : IDMEFv2 helps detect incident. When an incident is detected it will be analysed and eventually fully described and shared with other security teams through IODEFv2. IDMEF is used upstream IODEFv2. IDMEFv2 alerts can be “attached” to IODEFv2 object to provide technical details about incidents. Syslog (System Logging) : Syslog is a lossy format with no formal structure. Syslog can be used by sensors to send information to analyzers. Out of those multi-format syslogs the analyzer might detect an incident or an event of interest. The analyzer will then use IDMEFv2 to notify the manager which might correlate this information with other data to confirm the incident. SNMP (Simple Network Management Protocol) : SNMP polls information from devices which is then compared to thresholds to detect incident. IDMEFv2 can be used when incident is detected downstream of SNMP to communicate the incident to the manager. IDMEFv2 can have a similar role as SNMP Traps. STIX (Structured Threat Information Expression) : is a language and serialization format used to exchange cyber threat intelligence (CTI). IDMEFv2 can help detect incidents which might lead to the creation and sharing of STIX information. Cyber analyzer can also rely on STIX information to detect incidents that will be notified in IDMEFv2 format. OCSF (The Open Cybersecurity Schema Framework) is an open-source, vendor-agnostic standard designed to normalize security telemetry from diverse tools. It provides a common language and consistent structure for security event data, simplifying data ingestion, correlation, and analysis. OCSF can be seen as a “super” syslog to describe events before IDMEFv2 extract “incidents”. OCSF is limited to cyber security. SIEM proprietory formats (CEF, LEEF, ECS, CIM, ...) : By covering cyber, physical and monitoring incidents type, IDMEFv2 offers a wider spectrum than those formats. Gateways between IDMEFv2 and those formats can be developped to connect legacy cyber detection systems to an IDMEFv2 architecture. Lehmann & Andrejak Expires 27 April 2027 [Page 7] Internet-Draft IDMEFv2 October 2026 1.4. Existing Deployments and Adoption IDMEFv2 is not a theoretical proposal. It has been developed, validated, and deployed within the framework of eight large-scale European research projects, funded by the Horizon 2020 and Digital Europe programmes. These projects — namely 7SHIELD, PRECINCT, CyberSEAS, ATLANTIS, ENDURANCE, KINAITICS, TESTUDO, and SAFE4SOC — address critical sectors such as space systems, energy grids, transportation, and government infrastructure. These implementations span multiple domains, including Security Operations Centers (SOCs), Physical Security Information Management (PSIM) systems, and critical infrastructure protection pilots. This document aims to formalize this existing practice as an IETF Experimental RFC, to ensure interoperability, gather broader community feedback, and provide a stable foundation for future developments. 2. Terminology 2.1. Keywords 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 [RFC2119]. 2.2. Normative sections Implementations of IDMEFv2 are REQUIRED to fully implement: * The data types defined in Section 3 * The data model defined in Section 5 * The JavaScript Object Notation (JSON) serialization method Section 5.8. 2.3. Concepts related to event processing 2.3.1. Event An event is something that triggered a notice. Any incident starts off as an event or a combination of events, but not all events result in an incident. An event does not need be an indication of wrongdoing. E.g. someone successfully logging in or entering a building is an event. Lehmann & Andrejak Expires 27 April 2027 [Page 8] Internet-Draft IDMEFv2 October 2026 2.3.2. Incident An incident is an event that compromises or has a significant probability of compromising at least one of the organization's security criteria such as Confidentiality, Integrity or Availability. An incident may affect a production tool, personnel, etc. It may be logical, physical or organizational in nature. Last but not least, an incident may be caused on purpose or by accident. 2.3.3. Alert An alert is a notification/message that a particular event/incident (or series of events/incidents) has occurred. 2.3.4. Manager The manager is the central console toward which all analyzers send their alerts. The manager collects, correlates, stores and displays the alerts to the operators. Example : - A SIEM (Security Information & Event Management) or a Log Manager) - A PSIM (Physical Security Information Management) - A NMS (Network Management System) - A CPSIEM (Cyber & Physical Security Information Management System) 2.3.5. Operator The level 1 operator is in charge of receiving manager notifications and identify or confirm when an event should be considered as an incident. The operator must also decide if there is a known resolution for this incident or if it needs a deeper analysys. 2.3.6. Analyst The analyst will be contacted by the operator to analyze complex incidents that can’t be easily resolved. The investigation starts with the IDMEFv2 information but the analyst might need more information like raw logs for a deeper forensics. 2.3.7. Attack An attack is an attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of a cyber or physical asset. An attack is one or many kinds of incidents. Lehmann & Andrejak Expires 27 April 2027 [Page 9] Internet-Draft IDMEFv2 October 2026 2.3.8. Correlation Correlation is the identification of relationships between two or more events. 2.3.9. Aggregation Aggregation is the consolidation of similar events into a single event. 3. The IDMEF Data Types Each object inside the IDMEF data model has an associated data type. This type may be used to validate the content of incoming IDMEF messages. 3.1. Classes The classes are meant to group related attributes together. Some of the classes may be instanciated multiple times (e.g. Source, Target, etc.) while others may only appear once in an IDMEF message (e.g. Analyzer). 3.2. Numbers 3.2.1. Integers Integers inside the IDMEF data model are expressed using the following ABNF [RFC5234] grammar: integer = *1minus int int = zero / ( digit1-9 *DIGIT ) minus = %x2D ; - zero = %0x30 ; 0 digit1-9 = %x31-39 ; 1-9 E.g. 123. Such values are indicated with the "INT" type annotation in the model. 3.2.2. Floating-point values Floating-point values inside the IDMEF data model are expressed using the following ABNF grammar: Lehmann & Andrejak Expires 27 April 2027 [Page 10] Internet-Draft IDMEFv2 October 2026 float = integer *1frac frac = decimal-point 1*DIGIT decimal-point = %x2E ; . This grammar reuses some of the production rules listed in Section 3.2.1. E.g. 12.34. Such values are indicated with the "FLOAT" type annotation in the model. 3.3. Strings Strings are series of characters from the [UNICODE] standard and are used to represent a text. For readability, this document uses quotes (") to delimit strings, but please note that these quotes are not syntactically part of the actual strings. E.g. "Hello world". Some of the strings used in the IDMEFv2 data model follow a stricter syntax. These are included below for completeness. Such values are indicated with the "STRING" type annotation in the model. 3.3.1. Enumerations Enumerations are special strings used when valid values for an IDMEF attribute are restricted to those present in a predefined list. Such values are indicated with the "ENUM" type annotation in the model. 3.3.2. Timestamps Timestamps are used to indicate a specific moment in time. The timestamps used in the IDMEF data model follow the syntax defined by the "date-time" production rule of the grammar in [RFC3339] ch 5.6. E.g. "1985-04-12T23:59:59.52Z" represents a moment just before April 5th, 1985 in Coordinated Universal Time (UTC). Such values are indicated with the "TIMESTAMP" type annotation in the model. Lehmann & Andrejak Expires 27 April 2027 [Page 11] Internet-Draft IDMEFv2 October 2026 3.3.3. Geographical Locations Some attributes inside the IDMEF data model may refer to geographical locations using a set of coordinates. The reference system for all geographical coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 [WGS84]. The reference system used is the same as for the Global Positioning System (GPS). The format for such values can be either "latitude,longitude" or "latitude,longitude,altitude". Each of these coordinates is represented as a floating-point value. The latitude and longitude are expressed in degrees while the altitude is expressed in meters. E.g. "48.8584,2.2945,276.13" matches the (3-dimensional) geographical location for the top floor or the Eiffel Tower located in Paris, France, while "48.8584,2.2945" matches the same location in two dimensions (with the altitude removed). Such values are indicated with the "GEOLOC" type annotation in the model. 3.3.4. UNECE Location Codes (UN/LOCODE) Some attributes inside the IDMEF data model may refer to geographical locations using Locations Codes. These codes can be assimilated to an enumeration, where the list of possible values is defined in the United Nations Economic Commission for Europe (UNECE) Codes for Trade [UN-LOCODE]. E.g. "FR PAR" is the Location Code for the city of Paris, France. Such values are indicated with the "UNLOCODE" type annotation in the model. 3.3.5. Uniform Resource Identifiers (URIs) The IDMEF data model uses Uniform Resource Identifiers (URIs), as defined in [RFC3986], when referring to external resources. Unless otherwise specified, either a Uniform Resource Location (URL) or a Uniform Resource Name (URN) may be used where a URI is expected. E.g. both "https://example.com/resource" and "urn:myapp:resource" are valid Uniform Resource Identifiers. Such values are indicated with the "URI" type annotation in the model. Lehmann & Andrejak Expires 27 April 2027 [Page 12] Internet-Draft IDMEFv2 October 2026 3.3.6. IP Addresses IP addresses inside the IDMEF data model are expressed as strings using the traditional dotted-decimal notation for IPv4 addresses (defined by the "dotnum" production rule in the grammar in [RFC5321]), while IPv6 addresses are expressed using the text representation defined in [RFC4291] ch 2.2. E.g. "192.0.2.1" represents a valid IPv4 address, while "::1/128" represents a valid IPv6 address. It is RECOMMENDED that implementations follow the recommendations for IPv6 text representation stated in [RFC5952]. Such values are indicated with the "IP" type annotation in the model. 3.3.7. E-mail addresses E-mail addresses inside the IDMEF data model are expressed as strings using the address specification syntax defined in [RFC5322] ch 3.4.1. E.g. "root@example.com". Such values are indicated with the "EMAIL" type annotation in the model. 3.3.8. Attachment names Attachments inside the IDMEF data model are identified using a unique name, composed of a string whose character set is limited to the ASCII letters (A-Z a-z) and digits (0-9). E.g. "state" is a valid name for an attachment. The constraint on name unicity is enforced per class. That is, but it is not possible for two attachments to share the same name inside the same alert. Such values are indicated with the "ID" type annotation in the model. 3.3.9. Media types Media types are used in the IDMEF data model to describe an attachment's content. The syntax for such values is defined in [RFC2046]. IANA keeps a list of all currently registered media types in the Media Types registry . Lehmann & Andrejak Expires 27 April 2027 [Page 13] Internet-Draft IDMEFv2 October 2026 E.g. "application/xml" or "text/plain; charset=utf-8". Such values are indicated with the "MEDIATYPE" type annotation in the model. 3.3.10. Universally Unique IDentifiers (UUIDs) Universally Unique Identifiers (UUIDs) are used to uniquely identify IDMEF messages. It is also possible for an IDMEF message to reference other IDMEF messages using their UUIDs. The syntax for UUIDs is defined in [RFC4122]. To limit the risk of UUID collisions, implementors SHOULD NOT generate version 4 UUIDs (randomly or pseudo-randomly generated UUIDs). E.g. "ba2e4ef4-8719-42bb-a712-d6e8871c5c5a". UUIDs are case-insensitive when used in comparisons. Such values are indicated with the "UUID" type annotation in the model. 3.3.11. Protocol Names Such values are indicated with the "PROTOCOL" type annotation in the model. 3.3.12. IDMEF Paths This document defines a way to represent the path to every possible attribute inside an IDMEF message. For conciseness, the top-level "Alert" class is omitted from the path. This representation can be used in contexts where the path to an IDMEF attribute is expected. An example of such usage can be seen in the definition of the "AggrCondition" attribute inside the Alert class (Section 5.2). The syntax for these IDMEF paths is expressed in the following ABNF grammar: Lehmann & Andrejak Expires 27 April 2027 [Page 14] Internet-Draft IDMEFv2 October 2026 class-name = "Analyzer" / "Sensor" / "Source" / "Target" / "Attachment" attribute-name = 1*ALPHA class-reference = class-name "." num = *1"-" 1*DIGIT list-index = "(" num ")" path = *1class-reference attribute-name *1list-index Valid attribute names are limited to those defined for the specified class-reference (or in the top-level "Alert" class if class-reference is omitted). For example, the following path refers to the "CeaseTime" attribute of the top-level "Alert" class: "CeaseTime". Likewise, the following path refers to the "Name" attribute of the "Analyzer" class: "Analyzer.Name". For attributes defined as lists (see Section 3.4), the path may include the (0-based) index for an entry inside the list. The index defaults to 0 if omitted. This means that several (valid) representations may be used to reference the same IDMEF attribute when list attributes are involved. For example, both of the following paths refer to the IP address of the first source associated with an IDMEF message: Source.IP Source(0).IP Compatible implementations MUST reject paths that reference an unknown class, an unknown attribute, or use a list-index for an IDMEF field which is not defined as a list. A compatible implementation MUST also normalize paths before comparing them (e.g. by stripping the text "(0)" from paths referring to list attributes). 3.3.13. Hashes Hashes are sometimes used inside the data model to protect the integrity (and optionally, authenticity) of attachments. The syntax for these values is "function:hash_result", where "function" refers to one of the hashing function names listed in and "hash_result" contains the hexadecimal notation for the hash result obtained by calling the specified hash function on the input value. Lehmann & Andrejak Expires 27 April 2027 [Page 15] Internet-Draft IDMEFv2 October 2026 In the context of IDMEF, either a keyless or keyed hash function may be used to process the raw input value. E.g. "sha256:a02735ed8b10ad432d557bd4849c0dac3b23d64706e0618716d6df2def338374" Hashes are case-insensitive when used in comparisons. Such values are indicated with the "HASH" type annotation in the model. 3.4. Lists Some attributes of the IDMEF data model accept ordered lists of values. Such ordered lists are indicated with the "X[]" type annotation in the model. where "X" refers to one of the data types defined in Section 3. For example, "ENUM[]" refers to an ordered list of enumeration values. 4. The IDMEF extension In order to support the dynamic nature of security operations and to adapt to specific needs, the IDMEFv2 data model will need to continue to evolve. This section discusses how new data elements can be incorporated into the IDMEFv2. There is support to add additional enumerated values and new attributes. These extension mechanisms are designed so that adding new data elements is possible without requiring modifications to this document. Extensions can be implemented publicly or privately. With proven value, well-documented extensions can be incorporated into future versions of the specification. 4.1. Extending the Enumerated Values of Attributes Additional enumerated values can be added to select attributes either through the use of specially marked attributes with the "ext-" prefix or through a set of corresponding IANA registries. The former approach allows for the extension to remain private. The latter approach is public. Lehmann & Andrejak Expires 27 April 2027 [Page 16] Internet-Draft IDMEFv2 October 2026 4.1.1. Private Extension of Enumerated Values The data model supports adding new enumerated values to an attribute without public registration. For each attribute that supports this extension technique, there is a corresponding attribute in the same element whose name is identical but with a prefix of "ext-". This special attribute is referred to as the extension attribute. The attribute being extended is referred to as an extensible attribute. For example, an extensible attribute named "foo" will have a corresponding extension attribute named "ext-foo". An element may have many extensible attributes. In addition to a corresponding extension attribute, each extensible attribute has "ext-value" as one its possible enumerated values. Selection of this particular value in an extensible attribute signals that the extension attribute contains data. Otherwise, this "ext- value" value has no meaning. In order to add a new enumerated value to an extensible attribute, the value of this attribute MUST be set to "ext-value", and the new desired value MUST be set in the corresponding extension attribute. For example, extending the Category attribute of the Analyzer class would look as follows: Analyzer: { ... "Category":["ext-value"], "ext-Category": "my-new-analyzer-category", .... } A given extension attribute MUST NOT be set unless the corresponding extensible attribute has been set to "ext-value". 4.1.2. Public Extension of Enumerated Values The data model also supports publicly extending select enumerated attributes. A new entry can be added by registering a new entry in the appropriate IANA registry. Section (Table 5) provides a mapping between the extensible attributes and their corresponding registry. Lehmann & Andrejak Expires 27 April 2027 [Page 17] Internet-Draft IDMEFv2 October 2026 4.2. Private Extension of Attributes Use of new attributes is possible through the use of the attachment class. New attributes and their corresponding values should be stored in the Content attribute of an Attachment and the ContentEncoding must be set to JSON. For example creating a new attribute to store the email of the operator (in charge of solving the incident) will look as follows: "Attachment" : [ { "Name": "Operator", "ContentEncoding": "JSON", "Content": "{\"OperatorMail\":\"John.Does@acme.com\"}", } [ 5. The IDMEF Data Model In this section, the individual components of the IDMEF data model will be discussed in detail. For each class, the semantics will be described. 5.1. Overview +--------+ +-----+ |Analyzer|---> |Alert| +--------+ +-----+ || +------+ |Sensor| +------+ /\ / \ / \ +------+ +------+ |Source| >------> |Target| +------+ +------+ Figure 2: IDMEFv2 Overview Classes An IDMEF message is composed of an instance of the Alert class (Section 5.2) representing the overall properties of the message. It also contains exactly one instance of the Analyzer class (Section 5.3) and zero or more instances of the Sensor class (Section 5.4). The message may also describe various aspects of an event using the Source (Section 5.5) and Target (Section 5.6) classes. Lehmann & Andrejak Expires 27 April 2027 [Page 18] Internet-Draft IDMEFv2 October 2026 Last but not least, it may also include zero or more instances of the Attachment class (Section 5.7), e.g. captured files or network packets related to the event for example. The relationship between the main Alert class and other classes of the data model is shown in Figure 3 (attributes are omitted for clarity). +-------+ +------------- | Alert |<>----------| Analyzer | +-------+ +------------+ | | 0..* +------------+ | |<>----------| Sensor | | | +------------+ | | 0..* +------------+ | |<>----------| Source | | | +------------+ | | 0..* +------------+ | |<>----------| Target | | | +------------+ | | 0..* +------------+ | |<>----------| Attachment | +-------+ +------------+ Figure 3: IDMEFv2 Classes It is important to note that the data model does not specify how an incident should be categorized or identified. For example, an attacker scanning a network for machines listening on a specific port may be identified by one analyzer as a single attack against multiple targets, while another analyzer may identify it as multiple attacks from a single source. However, once an analyzer has determined the type of alert it plans on sending, the data model dictates how that alert should be formatted. 5.2. The Alert Class The Alert class contains high level information about the event that triggered the alert. Lehmann & Andrejak Expires 27 April 2027 [Page 19] Internet-Draft IDMEFv2 October 2026 +------------------------------+ | Alert | +------------------------------+ | STRING Version | | UUID ID | | STRING OrganisationName | | STRING OrganisationId | | STRING EntityName | | STRING EntityId | | ENUM[] EntitySector | | ENUM[] Type | | ENUM[] Category | | STRING[] ext-Category | | ENUM Cause | | STRING Description | | ENUM[] Status | | ENUM Priority | | FLOAT Confidence | | STRING Note | | TIMESTAMP CreateTime | | TIMESTAMP StartTime | | TIMESTAMP EndTime | | TIMESTAMP ReportTime | | STRING[] AltNames | | STRING[] AltCategory | | URI[] Ref | | UUID[] CorrelID | | CONDITION[] AggrCondition | | UUID[] PredID | | UUID[] RelID | | STRING[] SignedAttributes | | STRING Signature | +------------------------------+ Figure 4: The Alert class The aggregate classes that make up Alert are: Analyzer Exactly one. An instance of the Analyzer class (Section 5.3) that describes the tool/device responsible for the analysis that resulted in the alert being created and sent. Sensor Zero or more. Instances of the Sensor class (Section 5.4) used to describe the sensor(s) that captured the information used during the analysis. Lehmann & Andrejak Expires 27 April 2027 [Page 20] Internet-Draft IDMEFv2 October 2026 Depending on the tools/devices used to detect incidents, an Analyzer may rely on the output from a single sensor or from multiple sensors to generate alerts. In addition, the Analyzer and Sensor may actually be part of the same physical device and may share some of their attributes (e.g. IP, Hostname, Model, etc.). Source Zero or more. Instances of the Source class (Section 5.5) used to describe the source(s) of the incident (e.g. attackers, faulty device, etc.). Target Zero or more. Instances of the Target class (Section 5.6) used to describe the target(s) of the incident, i.e. the impacted devices/users/services/locations. Attachment Zero or more. Instances of the Attachment class (Section 5.7) used to describe the electronic artifacts captured in relation with the event. The intent of the Attachment class is to keep track of the electronic files left as a trail during the event. This may include things like on-disk files (e.g. malware samples), network packet captures, videos or still images from a camera feed, voice recording, etc. The Alert class has the following attributes: Version Mandatory. The version of the IDMEF format in use by this alert. During the drafts tuning period the version is equal to the draft version. Therefore it is "2.D.V0X" for Draft V0X. ID Mandatory. Unique identifier for the alert. OrganisationName Optional. Corporate/Main Office Organisation Name Useful if alerts are sent to a multi-organisation central incident detection manager. Example: ACME Corporation OrganisationId Lehmann & Andrejak Expires 27 April 2027 [Page 21] Internet-Draft IDMEFv2 October 2026 Optional. Corporate/Main Office Organisation ID. Where possible official organisation ID manage by national authority. Useful if alerts are sent to a multi-organisation central incident detection manager. This ID has to be chosen depending on the overall detection perimeter and the nature of the monitored organisation (Private/ Public, Commercial, International, etc.) Examples: OrganisationId in France could be SIREN, in England could be CR, Germany could be Handelsregisternummer, Spain could be CIF, Italia could be Partita IVA, USA could be EIN, etc. Commercial OrganisationId in Europe could be V.A.T ID EntityName Optional. Entity Name, monitored by the organisation, where the incident occurred. Could be a town, region or country name or an internal name. Could also be the name of a customer for a MSSP centralizing it's customer incidents in a single system. Do not repeat the organisation name in the EntityName Example: - ACME HeadQuaters is located in Paris France and has a local office in India - If the incident occurred in the local office: "OrganisationName": "ACME" , "EntityName": "India" - If the incident occurred in the headquaters: "OrganisationName": "ACME", "EntityName": "Headquaters" (or "Paris") EntityId Optional. Entity ID, monitored by the organisation, where the incident occurred. Useful if organisation and entity are not directly linked, like a customer and a MSSP. EntitySector Optional. The economic sector(s) and sub-sector(s) in which the entity operates. Values follow the dot notation sector.subsector based on the critical infrastructure taxonomy defined in the NIS2 Directive and CER (Critical Entities Resilience) Directive. Lehmann & Andrejak Expires 27 April 2027 [Page 22] Internet-Draft IDMEFv2 October 2026 This attribute enables sector-based correlation, regulatory compliance reporting, and risk context for incident detection. Enumeration available here Table 9 Type Optional. Incident type. +======+==============+=========================================+ | Rank | Keyword | Description | +======+==============+=========================================+ | 0 | Cyber | Incident involving cyberspace, | | | | information systems, or digital assets. | +------+--------------+-----------------------------------------+ | 1 | Physical | Incident involving physical assets, | | | | facilities, or infrastructure. | +------+--------------+-----------------------------------------+ | 2 | Availability | Incident affecting the availability or | | | | performance of a service, system, asset | | | | or resource. | +------+--------------+-----------------------------------------+ | 3 | Hazards | Incident arising from natural, | | | | societal, technological, environmental, | | | | or other hazards. | +------+--------------+-----------------------------------------+ | 4 | Combined | Incident involving two or more incident | | | | types. | +------+--------------+-----------------------------------------+ Table 1: Incident types Category Optional. Incident category. Enumeration available here Table 10 ext-Category Optional. A means by which to extend the Category attribute. (see Section 4.1.1) Cause Optional. Incident cause. The cause can be modified by any analyzer on the way of the alert and later by the operator and/or the analyst if new investigation reveals and confirms a different cause of the event. Lehmann & Andrejak Expires 27 April 2027 [Page 23] Internet-Draft IDMEFv2 October 2026 +======+=============+=========================================+ | Rank | Keyword | Description | +======+=============+=========================================+ | 0 | Normal | The event is related to an expected | | | | phenomenon or to a phenomenon that does | | | | not qualify as out of the ordinary. | +------+-------------+-----------------------------------------+ | 1 | Error | The event is related to a human error. | +------+-------------+-----------------------------------------+ | 2 | Malicious | The event is related to malicious code | | | | or malicious actions. | +------+-------------+-----------------------------------------+ | 3 | Malfunction | The event is related to a device or | | | | service malfunction. | +------+-------------+-----------------------------------------+ | 4 | Hazard | The event is related to a hazard | | | | phenomenon. | +------+-------------+-----------------------------------------+ | 5 | Unknown | The cause of the event is unknown. | +------+-------------+-----------------------------------------+ Table 2: Incident causes Description Optional. Short free text human-readable description of the event. The description can add detail to the event category for easiest/faster comprehension by the operator. Example : * Cryptoware WannaCry blocked on pegasus server * Unknown person entering through east doorway Status Optional. Event state in the overall event lifecycle. Lehmann & Andrejak Expires 27 April 2027 [Page 24] Internet-Draft IDMEFv2 October 2026 +======+===============+===============================+ | Rank | Keyword | Description | +======+===============+===============================+ | 0 | Event | The event is still considered | | | | as an harmless event and | | | | should not be treated. | +------+---------------+-------------------------------+ | 1 | Incident | The event is considered as an | | | | incident and should be taken | | | | care of. | +------+---------------+-------------------------------+ | 2 | Open | The incident is confirmed and | | | | actively being investigated. | +------+---------------+-------------------------------+ | 3 | Closed | Investigation is finished and | | | | the issue is handled. | +------+---------------+-------------------------------+ | 4 | FalsePositive | Investigation is finished, | | | | incident was a false | | | | positive. | +------+---------------+-------------------------------+ | 5 | Obsolete | Incident is obsolete, usually | | | | by another incident. | +------+---------------+-------------------------------+ Table 3: Incident statuses Priority Optional. Priority of the alert. Priority is defined by combining impact and urgency. It indicates how fast the incident should be taken care of. Lehmann & Andrejak Expires 27 April 2027 [Page 25] Internet-Draft IDMEFv2 October 2026 +======+==========+=============================================+ | Rank | Keyword | Description | +======+==========+=============================================+ | 0 | Unknown | Priority unknown | +------+----------+---------------------------------------------+ | 1 | Info | Informational event with no current impact; | | | | no action or follow-up is required. | +------+----------+---------------------------------------------+ | 2 | Low | Minor incident with negligible impact; a | | | | workaround exists, and resolution can be | | | | scheduled. | +------+----------+---------------------------------------------+ | 3 | Medium | Moderate incident affecting a limited | | | | scope; requires timely attention but is not | | | | immediately business-threatening. | +------+----------+---------------------------------------------+ | 4 | High | Significant incident with major service | | | | degradation or impact on important assets; | | | | demands an urgent response. | +------+----------+---------------------------------------------+ | 5 | Critical | Severe incident with business-critical | | | | systems down or vital interests threatened; | | | | requires immediate action and escalation. | +------+----------+---------------------------------------------+ Table 4: Incident priorities Confidence Optional. A floating-point value between 0 and 1 indicating the analyzer's confidence in its own reliability of this particular detection, where 0 means that the detection is surely incorrect while 1 means there is no doubt about the detection made. Note Optional. Free text human-readable additional note, possibly a longer description of the incident if is not already obvious. The Note attribute can be used to store any additional information. It can be additional information about the event and/or about the incident resolution, although the incident resolution information should in principle be stored elsewhere (with a link with the external tool in AltNames) CreateTime Mandatory. Timestamp indicating when the alert was created. StartTime Optional. Timestamp indicating the deduced start of the event. Lehmann & Andrejak Expires 27 April 2027 [Page 26] Internet-Draft IDMEFv2 October 2026 StartTime can be later than CreateTime in case or Alerts created from forecast information (e.g. Snow Storm expected in two days staring at 10h00) EndTime Optional. Timestamp indicating the deduced end of the event. ReportTime Optional. Timestamp indicating the reporting time of the event, usually to an external CSIRT or a central SIEM. AltNames Optional. Alternative identifiers; strings which help pair the event to internal systems' information (for example ticket IDs inside a request tracking systems). AltCategory Optional. Alternate categories from a reference other than IDMEFv2 categories (e.g. MISP, MITRE ATT@CK or another proprietary/internal reference). Ref Optional. References to sources of information related to the incident and/or vulnerability, and specific to this incident. This MAY be a URL to additional info, or a URN in a registered or unregistered ad-hoc namespace bearing reasonable information value and uniqueness, such as "urn:cve:CVE-2013-2266". CorrelID Optional. Identifiers for the messages which were used as information sources to create this message, in case the message has been created based on correlation/analysis/deduction from other messages. AggrCondition Optional. A list of IDMEF fields used to aggregate events. The values for these fields will be the same in all aggregated events. This attribute should mostly be set by intermediary nodes, which detect duplicates, or aggregate events, spanning multiple detection windows, into a longer one. The "StartTime" and "EndTime" attributes are used in conjunction with this attribute to describe the aggregation window. PredID Lehmann & Andrejak Expires 27 April 2027 [Page 27] Internet-Draft IDMEFv2 October 2026 Optional. A list containing the identifiers of previous messages which are obsoleted by this message. The obsoleted alerts SHOULD NOT be used anymore. This field can be used to "update" an alert. RelID Optional. A list containing the identifiers of other messages related to this message. SignedAttributes Optional. List of IDMEFv2 paths of the attributes included in the signature. Signature Optional. JWS Compact Serialization string containing the signature. 5.3. The Analyzer Class The Analyzer class describes the module that has analyzed the data captured by the sensors, identified an event of interest and decided to create an alert. +-----------------------+ | Analyzer | +-----------------------+ | UUID ID | | IP IP | | STRING Name | | STRING Hostname | | STRING Model | | ENUM[] Category | | STRING[] ext-Category | | ENUM[] Data | | STRING[] ext-Data | | ENUM[] Method | | STRING[] ext-Method | | GEOLOC GeoLocation | | UNLOCODE UnLocation | | STRING Location | | STRING Locator | | STRING CaptureZone | +-----------------------+ Figure 5: The Analyzer class The Analyzer class has the following attributes: Lehmann & Andrejak Expires 27 April 2027 [Page 28] Internet-Draft IDMEFv2 October 2026 ID Optional. Unique identifier for the analyzer. IP Optional. Analyzer IP address. Name Recommended. Name of the analyzer, which must be reasonably unique, however still bear some meaningful sense. This attribute usually denotes the hierarchy of organizational units the detector belongs to and its own name. It MAY also be used to distinguish multiple analyzers running with the same IP address. Hostname Optional. Hostname of this analyzer. SHOULD be a fully-qualified domain name. Model Optional. Analyzer model description (usually its generic name, brand and version). Category Optional. Analyzer categories. Enumeration available here Table 11 ext-Category Optional. A means by which to extend the Category attribute. (see Section 4.1.1) Data Optional. Type of data analyzed during the detection. Enumeration available here Table 12 ext-Data Optional. A means by which to extend the Data attribute. (see Section 4.1.1) Method Optional. Detection method. Enumeration available here Table 13 ext-Method Lehmann & Andrejak Expires 27 April 2027 [Page 29] Internet-Draft IDMEFv2 October 2026 Optional. A means by which to extend the Method attribute. (see Section 4.1.1) GeoLocation Optional. GPS coordinates for the analyzer. UnLocation Optional. Standard UN/Locode for the analyzer. Location Optional. Internal name for the location of the analyzer. Locator Optional. Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path. CaptureZone Optional. A string that describes the "capture zone" of the analyzer (if the analyzer is also a sensor), as a JSON-serialized string. Depending on the type of sensor, the capture zone may for instance refer to: A JSON object describing a camera's settings (elevation, horizontal and vertical field of view, azimuth, etc.) A description of the IP network where packet capture is taking place. 5.4. The Sensor Class The Sensor class describes the module that captured the data before sending it to an analyzer. The Sensor may be a subpart of the Analyzer. Lehmann & Andrejak Expires 27 April 2027 [Page 30] Internet-Draft IDMEFv2 October 2026 +----------------------+ | Sensor | +----------------------+ | UUID ID | | IP IP | | STRING Name | | STRING Hostname | | STRING Model | | ENUM[] Data | | STRING[] ext-Data | | GEOLOC GeoLocation | | UNLOCODE UnLocation | | STRING Location | | STRING Locator | | STRING CaptureZone | +----------------------+ Figure 6: The Sensor class The Sensor class has the following attributes: ID Optional. Unique identifier for the sensor. IP Optional. The sensor's IP address. Name Recommended. Name of the sensor, which must be reasonably unique, however still bear some meaningful sense. This attribute usually denotes the hierarchy of organizational units the sensor belongs to and its own name. It MAY also be used to distinguish multiple sensors running with the same IP address. Hostname Optional. The sensor's hostname. This SHOULD be a fully qualified domain name, but may not conform exactly because values extracted from logs, messages, DNS, etc. may themselves be malformed. An empty string MAY be used to explicitly state that this value was inquired but not found (missing DNS entry). Model Optional. The sensor model's description (usually its generic name, brand and version). Lehmann & Andrejak Expires 27 April 2027 [Page 31] Internet-Draft IDMEFv2 October 2026 Data Optional. Type of data captured by the sensor. Enumeration available here Table 12 ext-Data Optional. A means by which to extend the Data attribute. (see Section 4.1.1) GeoLocation Optional. GPS coordinates for the analyzer. UnLocation Optional. Standard UN/Locode for the sensor. Location Optional. Internal name for the location of the sensor. Locator Optional. Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path. CaptureZone Optional. A string that describes the "capture zone" of the sensor, as a JSON-serialized string. Depending on the type of sensor, the capture zone may for instance refer to: * A JSON object describing a camera's settings (elevation, horizontal and vertical field of view, azimuth, etc.) * A description of the IP network where packet capture is taking place. 5.5. The Source Class The Source class describes the origin(s) of the event(s) leading up to the creation of this alert. Lehmann & Andrejak Expires 27 April 2027 [Page 32] Internet-Draft IDMEFv2 October 2026 +------------------------+ | Source | +------------------------+ | UUID ID | | IP IP | | STRING Hostname | | STRING Name | | ENUM[] Category | | STRING Note | | STRING[] TI | | STRING User | | EMAIL Email | | PROTOCOL[] Protocol | | INT[] Port | | GEOLOC GeoLocation | | UNLOCODE UnLocation | | STRING Location | | STRING Locator | | ID[] Attachment | +------------------------+ Figure 7: The Source class The Source class has the following attributes: ID Optional. Unique identifier for the source. IP Optional. Source IP address. Hostname Optional. Hostname of this source. This SHOULD be a fully qualified domain name, but may not conform exactly because values extracted from logs, messages, DNS, etc. may themselves be malformed. An empty string MAY be used to explicitly state that this value was inquired but not found (missing DNS entry). Name Optional. Name of this source. Naming the source might be necessary for non digital source like a human, a vehicle, a drone, etc. Category Lehmann & Andrejak Expires 27 April 2027 [Page 33] Internet-Draft IDMEFv2 October 2026 Optional. Source category Enumeration available here Table 14 Note Optional. Free text human-readable additional note for this source. TI Optional. Threat Intelligence data about the source. Values in this list MUST use the format "attribute:origin", where "attribute" refers to the attribute inside this source found inside a Threat Intelligence database, and "origin" contains a short identifier for the Threat Intelligence database. E.g. "IP:Dshield". Please note that the same attribute may appear multiple times inside the list (because a match was found in multiple Threat Intelligence databases). User Optional. User ID or login responsible for the incident. Email Optional. Email address responsible for the incident. E.g. the value of the "Reply-To" or "From" header inside a phishing e-mail. Protocol Optional. Protocols related to connections from/to this source. If several protocols are stacked, they MUST be ordered from the lowest (the closest to the medium) to the highest (the closest to the application) according to the ISO/OSI model. Port Optional. Source ports involved in the incident. Values in this list MUST be integers and MUST be in the range 1-65535. GeoLocation Optional. GPS coordinates for the source. UnLocation Optional. Standard UN/Locode for the source. Lehmann & Andrejak Expires 27 April 2027 [Page 34] Internet-Draft IDMEFv2 October 2026 Location Optional. Internal name for the location of the source. Locator Optional. Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path. Attachment Optional. Identifiers for attachments related to this source. Each identifier listed here MUST match the "Name" attribute for one of the attachments described using the Attachment class (Section 5.7). 5.6. The Target Class The Target class describes the target(s) impacted by the event(s) leading up to the creation of this alert. +------------------------+ | Target | +------------------------+ | UUID ID | | IP IP | | STRING Hostname | | STRING Name | | ENUM[] Category | | STRING Note | | STRING Service | | STRING User | | EMAIL Email | | INT[] Port | | STRING Polygon | | STRING Circle | | GEOLOC GeoLocation | | UNLOCODE UnLocation | | STRING Location | | STRING Locator | | ID[] Attachment | +------------------------+ Figure 8: The Target class The Target class has the following attributes: ID Optional.Unique identifier for the target. Lehmann & Andrejak Expires 27 April 2027 [Page 35] Internet-Draft IDMEFv2 October 2026 IP Optional. Target IP address. Hostname Optional. Hostname of this target. This SHOULD be a fully qualified domain name, but may not conform exactly because values extracted from logs, messages, DNS, etc. may themselves be malformed. An empty string MAY be used to explicitly state that this value was inquired but not found (missing DNS entry). Name Optional. Name of this target. Naming the target might be necessary for non digital targets like a human, a vehicle, a building, etc. Category Optional. Target category Enumeration available here Table 15 Note Optional. Free text human-readable additional note for this target. Service Optional. Should be High Level Service (messaging, internet, ...), if not defined can be process impacted by the incident. User Optional. User ID or login impacted by the incident. Email Optional. Email address impacted by the incident. E.g. the value of the "To" header inside a phishing e-mail. Port Optional. Target ports involved in the incident. Values in this list MUST be integers and MUST be in the range 1-65535. Polygon Lehmann & Andrejak Expires 27 April 2027 [Page 36] Internet-Draft IDMEFv2 October 2026 Optional. Pollygonal incident affected area. Whitespace- delimited list of WGS 84 'latitude,longitude' pairs. Minimum 4 pairs, first equals last Circle Optional. Circular incident infected area. WGS 84 center point 'latitude,longitude' followed by a space and radius in kilometers GeoLocation Optional. GPS coordinates for the target. UnLocation Optional. Standard UN/Locode for the target. Location Optional. Internal name for the location of the target. Locator Optional. Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path. Attachment Optional. Identifiers for attachments related to this target. Each identifier listed here MUST match the "Name" attribute for one of the attachments described using the Attachment class (Section 5.7). 5.7. The Attachment Class The Attachment class contains additional data which was captured in relation with the event. +----------------------------+ | Attachment | +----------------------------+ | ID Name | | STRING FileName | | HASH[] Hash | | INT Size | | URI[] Ref | | URI[] ExternalURI | | STRING Note | | MEDIATYPE ContentType | | STRING ContentEncoding | | STRING Content | +----------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 37] Internet-Draft IDMEFv2 October 2026 Figure 9: The Attachment class The Attachment class has the following attributes: Name Mandatory. A unique identifier among attachments that can be used to reference this attachment from other classes using the "Attachment" attribute. FileName Optional. Attachment filename. This will usually be the original name of the captured file or the name of the file containing the captured content (e.g. a packet capture file). Hash Optional. A list of hash results for the attachment's Content. The values in this list are computed by taking the raw value of the attachment's "Content" attribute. The hash result is computed before any other transformation (e.g. Base64 encoding) is applied to the content, so that a receiving IDMEF system may reverse the transformation, apply the same hashing function and obtain the same hash result. See also the definition for the "ContentEncoding" attribute below. It is RECOMMENDED that compatible implementations use one of the hashing functions from the SHA-2 [RFC6234] or SHA-3 [NIST.FIPS.202] families to compute the hash results in this list. Size Optional. Length of the content (in bytes). This value MUST be a non-negative integer. Ref Optional. References to sources of information related to the incident and/or vulnerability, and specific to this attachment. ExternalURI Optional. If the attachment's content is available and/or recognizable from an external resource, this is the URI (usually a URL) to that resource. Lehmann & Andrejak Expires 27 April 2027 [Page 38] Internet-Draft IDMEFv2 October 2026 This MAY also be a URN in a registered or unregistered ad-hoc namespace bearing reasonable information value and uniqueness, such as "urn:mhr:55eaf7effadc07f866d1eaed9c64e7ee49fe081a" or "magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C". Note Optional. Free text human-readable additional note for this attachment. ContentType Optional. Internet Media Type of the attachment. For compatibility reasons, implementations SHOULD prefer one of the well-known media types registered in IANA . ContentEncoding Optional. Content encoding. The following encodings are defined in this version of the specification: * "json": The content refers to a JSON object which has been serialized to a string using the serialization procedure defined in [RFC8259]. * "base64": The content has been serialized using the Base64 encoding defined in [RFC4648]. The "base64" encoding SHOULD be used when the content contains binary data. If omitted, the "json" encoding MUST be assumed. Content Optional. The attachment's content, in case it is directly embedded inside the message. For large attachments, it is RECOMMENDED that implementations make use of the "ExternalURI" attribute to refererence a copy of the content saved in an external storage mechanism. 5.8. The JavaScript Object Notation Serialization Method This serialization method aims to convert IDMEFv2 messages to a format that is easy to parse and process, both by software/hardware processors, as well as humans. It relies on the the JavaScript Object Notation (JSON) Data Interchange Format defined in [RFC8259]. Conforming implementations MUST implement all the requirements specified in [RFC8259]. Lehmann & Andrejak Expires 27 April 2027 [Page 39] Internet-Draft IDMEFv2 October 2026 In addition, the following rules MUST be observed when serializing an IDMEFv2 message: * The top-level Alert class (Section 5.2) is represented as a JSON object ([RFC8259]). This JSON object is returned to the calling process at the end of the serialization process. * Aggregate classes are represented as JSON objects and stored as members of the top-level JSON object, using the same name as in the IDMEF data model. E.g. the appears under the name "Analyzer" inside the top-level JSON object. * Attributes are stored as members of the JSON object representing the class they belong to, using the same name as in the IDMEF data model. E.g. the "Version" attribute from the is stored under the name "Version" inside the top-level JSON object. * Lists from the IDMEF data model are represented as JSON arrays ([RFC8259]). This also applies to aggregate classes where a list is expected. E.g. the "Sensor" member inside the top-level JSON object contains a list of objects, where each object represents an instance of the . * The various string-based data types listed in Section 3 are represented as JSON strings ([RFC8259]). Please note that the issues outlined in [RFC8259] regarding strings processing also apply here. * IDMEF attributes with the "NUMBER" data type are represented as JSON numbers ([RFC8259]). 6. Security Considerations This document describes a data representation for exchanging security-related information between incident detection system implementations. Although there are no security concerns directly applicable to the format of this data, the data itself may contain security-sensitive information whose confidentiality, integrity, and/ or availability may need to be protected. This suggests that the systems used to collect, transmit, process, and store this data should be protected against unauthorized use and that the data itself should be protected against unauthorized access. The underlying messaging format and protocol used to exchange instances of the IDMEF MUST provide appropriate guarantees of confidentiality, integrity, and authenticity. The use of a standardized security protocol is encouraged. Lehmann & Andrejak Expires 27 April 2027 [Page 40] Internet-Draft IDMEFv2 October 2026 The draft-lehmann-idmefv2-https-transport-01.txt document defines the transportation of IDMEF over HTTPs that provides such security. 7. IANA Considerations This document creates 10 identically structured registries to be managed by IANA: * Name of the registry group: "Incident Detection Message Exchange Format v2 (IDMEF)" * URL of the registry: http://www.iana.org/assignments/idmefv2 * Namespace format: A registry entry consists of: - Rank. A uniq integer for this namespace. Range starts at 0 and ends at the length of this list. The maximum length of this list is 255. - Keyword. A keyword for a given IDMEF attribute. It MUST conform to the formatting specified by the IDMEF "ENUM" data type (Section 3.3.1). - Description. A short description of the enumerated keyword. - Reference. An optional list of URIs to further describe the value. * Allocation policy: Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. The reviewer will also ensure that the entry is an appropriate value for the attribute per the information model (Section 5). The registries to be created are named in the "Registry Name" column of Table 5. Each registry is initially populated with ranks, keywords and descriptions that come from an attribute specified in the IDMEF model (Section 5). The initial Ranks, Keywords and Description fields of a given registry are listed in "Initial Values". The "Initial Values" column points to a table in this document that lists and describes each enumerated keyword. Each enumerated keyword in the table gets a corresponding entry in a given registry. The initial value of the Reference field of every registry entry described below should be this document. Lehmann & Andrejak Expires 27 April 2027 [Page 41] Internet-Draft IDMEFv2 October 2026 +===================+=====================================+ | Registry Name | Initial Values | +===================+=====================================+ | Alert-Type | Table 1 (Alert class (Section 5.2)) | +-------------------+-------------------------------------+ | Alert-Category | (Alert class (Section 5.2)) | +-------------------+-------------------------------------+ | Alert-Cause | Table 2 (Alert class (Section 5.2)) | +-------------------+-------------------------------------+ | Alert-Priority | Table 4 (Alert class (Section 5.2)) | +-------------------+-------------------------------------+ | Alert-Status | Table 3 (Alert class (Section 5.2)) | +-------------------+-------------------------------------+ | Analyzer-Category | (Alert class (Section 5.2)) | +-------------------+-------------------------------------+ | Analyzer-Data | (Analyzer class (Section 5.3)) | +-------------------+-------------------------------------+ | Analyzer-Method | (Analyzer class (Section 5.3)) | +-------------------+-------------------------------------+ Table 5: IANA Enumerated Value Registries 8. Acknowledgement The following groups and individuals contributed to the creation of this document and should be recognized for their efforts. * The former Prelude SIEM team : François Poirotte (Co-author of the first version of this document), Antoine Luong, Song Tran, Selim Menouar and Camille Gardet * The core members of the SECEF (SECurity Exchange Format) consortium : Herve Debar (Author of RFC 4765 - IDMEFv1), Guillaume Hiet and François Dechelle * The H2020 7SHIELD project (Safety and Security Standards of Space Systems, ground Segments and Satellite data assets , via prevention, detection, response and mitigation of physical and cyber threats) who implemented in real scale first versions of IDMEFv2 on five pilots around Europe helping greatly to improve it. * The Digital Europe Safe4Soc project (Standard Alert Exchange Format for SOC) who activaly contribute to draft evolution since V04. Lehmann & Andrejak Expires 27 April 2027 [Page 42] Internet-Draft IDMEFv2 October 2026 * All other european research project having deployed and tested IDMEFv2 on their pilots (PRECINCT, CyberNEMO, CyberSEAS, ATLANTIS, ENDURANCE, KINAITICS, TESTUDO) * The CESNET team for their work on the [IDEA0] format (based on IDMEFv1) which inspired multiples concepts to IDMEFv2. 9. References 9.1. Normative References [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . Lehmann & Andrejak Expires 27 April 2027 [Page 43] Internet-Draft IDMEFv2 October 2026 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [UNICODE] Unicode Consortium, "Unicode Standard", version 14.0.0, 14 September 2021, . [IANA_media_types] IANA, "Media Types", . [IANA_hash_function_text_names] IANA, "Hash Function Textual Names", . [UN-LOCODE] UNECE, "UN/LOCODE Code List by Country and Territory", 6 July 2021, . 9.2. Informative References [RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765, DOI 10.17487/RFC4765, March 2007, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Lehmann & Andrejak Expires 27 April 2027 [Page 44] Internet-Draft IDMEFv2 October 2026 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [NIST.FIPS.202] Dworkin, Morris J., "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", NIST NIST FIPS 202, DOI 10.6028/NIST.FIPS.202, July 2015, . [WGS84] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984: Its Definition and Relationships with Local Geodetic Systems", Third Edition, 1984, . [IDEA0] CESNET, "Intrusion Detection Extensible Alert version 0", 25 September 2015, . Appendix A. Using IDMEFv2 in Dynamic Environments 1.0 Proposal October 2026 A.1. The Dynamic Asset Problem Modern container orchestration platforms and cloud runtime environments create and terminate resources dynamically. IP addresses may change or be reassigned, resource names may be reused, and an entity involved in a security incident may no longer exist when an investigation takes place. Consequently, identifying a resource solely by its IP address or hostname is insufficient for reliable incident correlation and post- incident investigation. IDMEFv2 provides complementary attributes that can describe dynamic entities in the , , , and classes. The attribute identifies an entity in the IDMEFv2 data model, while , , and provide additional information about its network presence, operational hostname, and infrastructure context. Lehmann & Andrejak Expires 27 April 2027 [Page 45] Internet-Draft IDMEFv2 October 2026 These attributes serve different purposes and SHOULD be used together when the relevant information is available. They do not, by themselves, guarantee the long-term availability of historical records or the continued existence of the resource. A.2. Complementary Identification Attributes The following attributes have complementary roles when describing dynamic resources. A.2.1. ID The attribute identifies an entity in the IDMEFv2 data model. It MUST be populated in accordance with the applicable IDMEFv2 specification. An IDMEFv2 identifier and a platform-native identifier are different concepts. For example, a Kubernetes pod UID identifies a Kubernetes object instance; it is not a substitute for the IDMEFv2 attribute. Implementations that need to correlate multiple alerts concerning the same resource SHOULD define a consistent mapping between the resource identity and the IDMEFv2 entity identifier. They SHOULD also distinguish successive resource instances when a platform reuses an operational name. The identifier MUST NOT be assumed to provide access to a resource or to its historical metadata after termination. A.2.2. IP The attribute records the network address associated with the entity in the context of the event. It supports correlation with network telemetry, firewall logs, flow records, and other security monitoring data. However, an IP address is a time-dependent network attribute and MUST NOT be treated as a persistent identifier of an dynamic resource. When available, the event timestamp and relevant network context SHOULD be retained to support the interpretation of the address at the time of the incident. Implementations SHOULD distinguish addresses belonging to different infrastructure layers, such as a pod, container, node, NAT gateway, or proxy, when this distinction is relevant to the investigation. Lehmann & Andrejak Expires 27 April 2027 [Page 46] Internet-Draft IDMEFv2 October 2026 A.2.3. Hostname The attribute records the hostname observed or configured for the entity. It SHOULD contain an actual hostname, not an unrelated platform identifier. For a Kubernetes pod, the hostname can be configured through the pod's hostname settings or obtained from the runtime environment. A pod name and the hostname used inside the pod may happen to be the same, but they are not interchangeable by definition. Implementations SHOULD record the actual hostname observed or configured for the pod. Hostnames can facilitate operational identification and correlation during a resource's lifetime. However, hostnames may be reused, and their uniqueness may be limited to a particular namespace, cluster, runtime, or time interval. Consequently, SHOULD NOT be considered a globally unique or permanently stable identifier without additional context. A.2.4. Locator The attribute can carry a platform-specific resource reference that provides additional context for identifying an entity within its infrastructure. Depending on the environment, this reference MAY contain a cloud resource identifier, an orchestration resource path, a container identifier qualified by its runtime, or a combination of identifiers that uniquely identifies the relevant resource within its scope. Implementations SHOULD prefer references that identify the individual resource involved in the event rather than only its parent cluster, service, or workload definition. Where appropriate, a reference MAY include additional context, such as a cluster identifier, namespace, node identifier, container identifier, or resource UID. Implementations using platform-specific references SHOULD document their syntax, scope, uniqueness properties, and interpretation. A value does not, by itself, guarantee that a terminated resource can be retrieved or that its historical metadata remains available. Systems requiring post-incident traceability MUST retain the relevant historical metadata and security telemetry for the required investigation period. Lehmann & Andrejak Expires 27 April 2027 [Page 47] Internet-Draft IDMEFv2 October 2026 A.3. Platform-Specific Resource References The examples below illustrate how can be populated in different environments. The URI schemes used in these examples, including , , , , and , are illustrative implementation conventions. They are not defined or standardized by IDMEFv2. The values are illustrative and MUST be replaced with identifiers and hostnames obtained from the relevant platform in an actual deployment. UUID-shaped values shown in the examples are illustrative IDMEFv2 entity identifiers; they are not Kubernetes UIDs unless explicitly placed in a platform reference. A.3.1. Kubernetes In Kubernetes, a pod name alone may not be sufficient to distinguish successive instances that share the same name. The pod UID SHOULD be retained when available. A reference SHOULD include the cluster context, namespace, pod name, and pod UID. Container-specific information MAY be added when the investigation concerns an individual container. The values below identify IDMEFv2 entities. The values are illustrative actual hostnames configured or observed for the respective pods; they are not merely Kubernetes pod names. The pod names and UIDs are retained in . Example: Lehmann & Andrejak Expires 27 April 2027 [Page 48] Internet-Draft IDMEFv2 October 2026 { "CreateTime": "2026-10-19T10:15:30Z", "Analyzer": [ { "ID": "7d6a3c21-1b4e-4f80-9a12-6e5b2c8d901f", "IP": "10.10.0.11", "Hostname": "secops-collector-01.example.net", "Locator": "k8s://cluster-secops/namespace-monitoring/pod/idmefv2-analyzer?uid=11111111-1111-4111-8111-111111111111" } ], "Sensor": [ { "ID": "8e7b4d32-2c5f-4a91-8b23-7f6c3d9e012a", "IP": "10.10.0.12", "Hostname": "network-sensor-01.example.net", "Locator": "k8s://cluster-prod-eu/namespace-monitoring/pod/network-sensor?uid=22222222-2222-4222-8222-222222222222" } ], "Source": [ { "ID": "9f8c5e43-3d60-4ba2-9c34-8a7d4e0f123b", "IP": "10.244.2.15", "Hostname": "payment-worker-01.namespace-paiement.example.net", "Locator": "k8s://cluster-prod-eu/namespace-paiement/pod/payment-worker-5c8d9f-abc123?uid=6a1f8b42-3c9d-4e70-a521-8b7d9c2e104f&container=worker&node=node-worker-03" } ], "Target": [ { "ID": "a09d6f54-4e71-4cb3-8d45-9b8e5f10234c", "IP": "10.244.3.20", "Hostname": "payment-api-01.namespace-paiement.example.net", "Locator": "k8s://cluster-prod-eu/namespace-paiement/pod/payment-api-7b8c9d-xyz789?uid=33333333-3333-4333-8333-333333333333&container=api&node=node-worker-04", "Service": "finance" } ] } The reference is an illustrative convention. The pod UID identifies the Kubernetes object instance, while the cluster and namespace provide the context required to interpret the reference. Node-level information MAY be included when it helps correlate the event with network sensors or host-level telemetry. Lehmann & Andrejak Expires 27 April 2027 [Page 49] Internet-Draft IDMEFv2 October 2026 A.3.2. Docker and Podman For standalone container runtimes such as Docker and Podman, a container name alone may be insufficient because names can be reused after a container is removed. SHOULD identify the container instance and, where necessary, the runtime host or engine. The full container identifier SHOULD be preferred over the human-readable container name. Example: { "Target": [ { "ID": "b10e7a65-5f82-4dc4-9e56-0c9f6a21345d", "IP": "172.17.0.3", "Hostname": "web-app-01.example.net", "Locator": "docker://server-web-01/containers/a1b2c3d4e5f67890123456789012345678901234567890123456789012345678", "Service": "e-commerce" } ] } The scheme is an illustrative convention, not an official Docker URI scheme. A corresponding convention MAY be defined for Podman, for example using a scheme. Implementations SHOULD document whether the reference identifies the container, the runtime instance, the host, or a combination of these entities. Where multiple runtime hosts or engines are involved, the reference SHOULD include enough context to avoid ambiguity. A.3.3. Google Cloud GKE For Google Kubernetes Engine (GKE), a reference can combine the Google Cloud project and cluster context with the Kubernetes namespace, pod name, and pod UID. The cluster resource identifier alone identifies the cluster, not the individual pod involved in the incident. Example: Lehmann & Andrejak Expires 27 April 2027 [Page 50] Internet-Draft IDMEFv2 October 2026 { "Target": [ { "ID": "c21f8b76-6083-4ed5-af67-1d0a7b32456e", "IP": "10.244.2.15", "Hostname": "payment-worker-01.namespace-paiement.example.net", "Locator": "gke://projects/my-project-123/locations/us-west1/clusters/cluster-prod-eu/namespaces/namespace-paiement/pods/payment-worker-5c8d9f-abc123?uid=6a1f8b42-3c9d-4e70-a521-8b7d9c2e104f&container=worker", "Service": "finance" } ] } The scheme is an illustrative convention rather than an official Google Cloud resource URI format. Implementations MAY instead use a documented Google Cloud resource identifier together with the Kubernetes identifiers required to identify the individual pod. A.3.4. AWS ECS In Amazon Elastic Container Service (ECS), the task ARN identifies a task instance, whereas the task definition ARN identifies a versioned task definition. For incident investigation involving a particular running or terminated task, SHOULD identify the task instance rather than only its task definition. The task definition ARN MAY be retained separately as supplementary configuration context. Example: { "Target": [ { "ID": "d32f8a76-4b19-4c52-9d63-0a8e7f6b1234", "IP": "10.0.1.42", "Hostname": "payment-worker-01.example.net", "Locator": "arn:aws:ecs:us-west-1:123456789012:task/cluster-prod-eu/0123456789abcdef0123456789abcdef", "Service": "finance" } ] } The ARN is illustrative. Implementations MUST use the actual task ARN returned by ECS and SHOULD retain the cluster context when needed to interpret the reference. When the incident concerns an individual container within a task, the relevant container identifier SHOULD also be retained when available. Lehmann & Andrejak Expires 27 April 2027 [Page 51] Internet-Draft IDMEFv2 October 2026 The task definition ARN MAY be recorded as additional information to identify the configuration used by the task. It MUST NOT be substituted for the task instance identifier when the objective is to distinguish individual task executions. A.3.5. Microsoft Azure AKS In Azure Kubernetes Service (AKS), the Azure Resource Manager (ARM) resource ID of a managed cluster identifies the cluster, not an individual pod. A pod-level reference SHOULD therefore combine the Azure subscription, resource group, and cluster context with the Kubernetes namespace, pod name, and pod UID. Example: { "Target": [ { "ID": "e43f9b87-5c20-4d63-8e74-1b9f6a20345d", "IP": "10.240.0.15", "Hostname": "payment-worker-01.namespace-paiement.example.net", "Locator": "aks://subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/my-rg/managedClusters/cluster-prod-eu/namespaces/namespace-paiement/pods/payment-worker-5c8d9f-abc123?uid=6a1f8b42-3c9d-4e70-a521-8b7d9c2e104f", "Service": "finance" } ] } The scheme is an illustrative convention, not an official ARM resource identifier for a pod. Implementations MAY retain the cluster ARM resource ID as a separate reference or incorporate it into a documented platform-specific representation. The reference SHOULD distinguish the individual Kubernetes resource from its parent cluster. A.3.6. HashiCorp Nomad In HashiCorp Nomad, an allocation identifier can provide a reference to a particular workload allocation. The reference SHOULD include sufficient context to distinguish allocations across clusters, regions, namespaces, or jobs, as applicable. Example: Lehmann & Andrejak Expires 27 April 2027 [Page 52] Internet-Draft IDMEFv2 October 2026 { "Target": [ { "ID": "f54a0c98-6d31-4e75-9a82-2c7f1b60345e", "IP": "172.17.0.5", "Hostname": "payment-worker-01.example.net", "Locator": "nomad://region-eu/cluster-prod/job-payment/alloc-01234567-89ab-cdef-0123-456789abcdef?task=worker", "Service": "finance" } ] } The scheme is an illustrative convention. Implementations SHOULD use the actual allocation identifier provided by Nomad and document the context required to interpret it. Task-level or container-level information MAY be included when necessary to distinguish the specific runtime entity involved in the event. A.4. Scope of the Service Attribute The attribute in the class SHOULD describe the high-level service or process affected, consistently with the IDMEFv2 specification. For example, values such as , , and can identify business-level services associated with the target. Implementations SHOULD avoid using as an undocumented substitute for platform-specific resource identifiers, such as pod names, container IDs, allocation IDs, task ARNs, or cluster resource IDs. Where business services and technical runtime services must be distinguished, implementations SHOULD document the mapping between these concepts and the relevant IDMEFv2 attributes. The use of for a particular purpose MUST remain consistent with the attribute definition in the applicable version of the IDMEFv2 specification. A.5. Temporal Context and Historical Retention Reliable post-incident investigation requires more than a stable resource reference. Lehmann & Andrejak Expires 27 April 2027 [Page 53] Internet-Draft IDMEFv2 October 2026 Implementations SHOULD preserve the event timestamp and sufficient contextual information to determine which resource instance, network address, and runtime environment were involved at the time of the event. The IDMEFv2 time attributes SHOULD be used according to their defined semantics. In particular, indicates when the alert was created, whereas describes the start of the activity or situation being reported when that information is available. They are not interchangeable, and neither should be assumed to represent the exact measurement time of every individual attribute. Implementations SHOULD retain any additional timestamps required to interpret time- sensitive measurements accurately. Systems requiring long-term traceability MUST retain the historical metadata and security telemetry needed for the intended investigation period. Such information can include orchestration events, container lifecycle records, cloud audit logs, network flow records, and mappings between resource identifiers and network addresses. A value MAY be used as a lookup key into retained historical records. However, the availability and retention of those records are properties of the surrounding monitoring and logging infrastructure, not guarantees provided by the attribute itself. A.6. Summary Ephemeral environments require a distinction between entity identification, network correlation, and historical resource context. The attribute identifies the entity in the IDMEFv2 data model. records the network address observed in the context of the event, provides the actual configured or observed hostname, and can carry a platform-specific reference to the relevant resource. Implementations SHOULD use resource references that identify individual instances rather than only their parent clusters or configuration definitions. They SHOULD preserve sufficient temporal and infrastructure context to distinguish successive instances and correlate events across security telemetry sources. Long-term traceability additionally depends on the retention and availability of historical metadata and security records. Lehmann & Andrejak Expires 27 April 2027 [Page 54] Internet-Draft IDMEFv2 October 2026 This approach enables IDMEFv2 to represent dynamic resources across different orchestration platforms and container runtimes without requiring a separate IDMEFv2 extension for each environment. Platform-specific reference formats remain implementation conventions and SHOULD be documented to support interoperability. The JSON fragments are illustrative. Their exact structure MUST conform to the applicable IDMEFv2 serialization and schema. Appendix B. IDMEFv2 Alert Signature Specification 1.0 Proposal October 2026 This appendix defines a standardized mechanism for signing IDMEFv2 alerts. The signature ensures the integrity and authenticity of alert data while allowing certain attributes to remain modifiable without invalidating the signature (partial signing). The mechanism builds upon the following standards: * *JWS* (RFC 7515) — signature format; * *JCS* (RFC 8785) — JSON canonicalization; * *JWA* (RFC 7518) — cryptographic algorithms; * *JWK* (RFC 7517) — key representation; * *IDMEFv2 Paths* (Section 3.3.12 of the draft) — attribute selection. The key words *MUST*, *MUST NOT*, *SHOULD*, *SHOULD NOT*, *MAY* and *RECOMMENDED* are to be interpreted as described in RFC 2119. B.1. Overview The mechanism adds two optional attributes to the class: 1. *``SignedAttributes``*: a list of IDMEFv2 paths identifying the attributes to be signed; 2. *``Signature``*: a string containing the JWS Compact Serialization of the signature. Lehmann & Andrejak Expires 27 April 2027 [Page 55] Internet-Draft IDMEFv2 October 2026 The signing process follows these steps: 1. populate with the list of IDMEFv2 paths; 2. build the signed payload object as defined in Signed Attributes and Payload Construction (Appendix B.3); 3. canonicalize this object using JCS (RFC 8785); 4. build the protected JWS header (containing , and optionally ); 5. produce the JWS Compact Serialization as defined in Signature Format: JWS Compact Serialization; 6. store the result in the attribute. B.2. Signature Format: JWS Compact Serialization The attribute *MUST* use the JWS Compact Serialization format defined in RFC 7515. B.2.1. Structure BASE64URL(JWS Protected Header) "." BASE64URL(JWS Payload) "." BASE64URL(JWS Signature) The JWS payload *MUST* be *embedded* (not detached) in the Compact serialization. It corresponds to the canonicalized representation of the payload object defined in Signed Attributes and Payload Construction (Appendix B.3), encoded in base64url as specified by RFC 7515. | Note: The payload is derived from the alert itself; embedding it | guarantees that the verifier has access to the exact | representation that was signed, independently of any re- | serialization of the alert. The unencoded payload option of RFC | 7797 is *not* used. B.2.2. Protected Header The protected JWS header *MUST* contain the parameter. It *SHOULD* contain the parameter. It *MUST NOT* contain any parameter not specified by this annex. B.2.3. Example "Signature": "" Lehmann & Andrejak Expires 27 April 2027 [Page 56] Internet-Draft IDMEFv2 October 2026 B.3. Signed Attributes and Payload Construction B.3.1. Path Syntax Attributes to be signed are identified using the IDMEFv2 path syntax defined in Section 3.3.12 of the draft. +=================================+===================+ | Attribute type | Example | +=================================+===================+ | Top-level attribute | | +---------------------------------+-------------------+ | Nested class attribute | | +---------------------------------+-------------------+ | List attribute (first element) | (index 0 implied) | +---------------------------------+-------------------+ | List attribute (specific index) | | +---------------------------------+-------------------+ Table 6 B.3.2. Payload Structure (Normative) The signed payload *MUST* be a *JSON object* whose structure mirrors the nesting of the paths listed in . Specifically: * a top-level path produces a key at the root; * a nested path produces an object containing a key ; * a list path (or with an implied index 0) produces an *array* under the key , whose element at index 0 is an object containing the key ; * list indices *MUST* be contiguous starting from 0 in the payload; unreferenced positions *MUST NOT* be included; * *MUST* be included in the payload under the key , with the list of paths as provided (see Constraints on SignedAttributes (Appendix B.3.4)); * *MUST NOT* be included in the payload. *Example.* For , the payload is: Lehmann & Andrejak Expires 27 April 2027 [Page 57] Internet-Draft IDMEFv2 October 2026 { "Version": "2.D.V08", "ID": "123e4567-e89b-12d3-a456-426614174000", "Analyzer": { "Name": "Corporate EDR" }, "Source": [ { "IP": "198.51.100.20" } ], "SignedAttributes": ["Version", "ID", "Analyzer.Name", "Source(0).IP"] } B.3.3. Absent or Invalid Attributes If a path listed in does not correspond to any attribute present in the alert, the producer *MUST* reject the signing operation (validation error). A verifier that observes the absence of a referenced attribute *MUST* reject the signature. B.3.4. Constraints on SignedAttributes * *MUST NOT* contain or . * The order of paths in the list is *not significant* (see Attribute Order: Not Significant (Appendix B.5)). * The list *MUST* be included in the payload to bind the signature to the covered set of paths. B.4. Attributes Added to the Alert Class +===========+======+=======================================+ | Attribute | Type | Description | +===========+======+=======================================+ | | | List of IDMEFv2 paths of the | | | | attributes included in the signature. | +-----------+------+---------------------------------------+ | | | JWS Compact Serialization string | | | | containing the signature. | +-----------+------+---------------------------------------+ Table 7 B.4.1. SignedAttributes Optional. *MUST* be present when is present. *MUST* be included in the JWS payload (see Payload Structure (Normative) (Appendix B.3.2)). B.4.2. Signature Optional. Present only when the alert is signed. Contains the complete JWS Compact Serialization. Lehmann & Andrejak Expires 27 April 2027 [Page 58] Internet-Draft IDMEFv2 October 2026 B.4.3. Consistency An alert that contains without , or vice versa, *MUST* be considered invalid by a verifier. B.5. Attribute Order: Not Significant The order of attributes in does not affect the signature because: 1. the payload is canonicalized using JCS (RFC 8785); 2. JCS deterministically sorts all keys in lexicographic order; 3. the same logical object therefore always produces the same canonical representation. Note: The array in the payload preserves the order of the specified indices; JCS does not reorder array elements. B.6. Normalization: JSON Canonicalization Scheme (JCS) All JSON objects used as the JWS payload *MUST* be canonicalized using JCS (RFC 8785) before signing and before verification. B.6.1. JCS Rules * object keys are sorted lexicographically; * whitespace outside string literals is removed; * numbers are formatted according to I-JSON rules (RFC 7493); * , and are forbidden. B.6.2. Rationale Without canonicalization, the same logical JSON object could be represented differently (key ordering, whitespace), leading to signature verification failures. JCS ensures deterministic serialization. B.7. Signature Algorithms B.7.1. Supported Algorithms The following algorithms *MUST* be supported: Lehmann & Andrejak Expires 27 April 2027 [Page 59] Internet-Draft IDMEFv2 October 2026 +===========+===========================+==============+ | Algorithm | Type | Usage | +===========+===========================+==============+ | | ECDSA P-256 / SHA-256 | RECOMMENDED | +-----------+---------------------------+--------------+ | | RSASSA-PSS / SHA-256 | RECOMMENDED | +-----------+---------------------------+--------------+ | (Ed25519) | EdDSA curve 25519 | RECOMMENDED | +-----------+---------------------------+--------------+ | | RSA PKCS#1 v1.5 / SHA-256 | IF NECESSARY | +-----------+---------------------------+--------------+ Table 8 B.7.2. Excluded Algorithms The following algorithms *MUST NOT* be used: * (unsecured); * , , (HMAC — inappropriate for third-party verification); * any algorithm not listed in JWA (RFC 7518). B.7.3. Verification Policy A verifier *MUST* check that the value of the protected header corresponds to an algorithm allowed by its local policy, and *MUST* reject the signature otherwise (protection against algorithm confusion). B.8. Key Management B.8.1. Key Identification *``alg`` parameter.* *MUST* be included in the protected JWS header. It identifies the cryptographic algorithm used to secure the JWS. The signature is not valid if does not represent a supported algorithm, or if no key associated with the signing party is available for that algorithm. The value *MUST* be a case-sensitive string containing a registered algorithm name (from the IANA "JSON Web Signature and Encryption Algorithms" registry as defined in JWA) or a value that contains a Collision-Resistant Name. Lehmann & Andrejak Expires 27 April 2027 [Page 60] Internet-Draft IDMEFv2 October 2026 *``kid`` parameter.* *SHOULD* be included in the protected JWS header. It provides a hint indicating which key was used to secure the JWS, allowing the recipient to locate the verification key and facilitating key rotation. Other identification mechanisms (out-of- band agreement) *MAY* be used, which is why this parameter remains optional. Example header: { "alg": "ES256", "kid": "key-2025-01" } B.8.2. Key Representation Keys *SHOULD* be represented in JWK format (RFC 7517) when exchanged as part of the payload. Other mechanisms, such as referencing a key via a understood within a pre-existing PKI, *MAY* be used to maintain compatibility with existing infrastructures. B.8.3. Key Distribution The key distribution mechanism is outside the scope of this annex. The following methods *MAY* be used: pre-shared public keys, PKI / X.509 certificates, OAuth 2.0 or OpenID Connect metadata endpoints, manual exchange. B.9. Verification Procedure A verifier *MUST* apply the following steps: 1. check for the joint presence of and (Consistency (Appendix B.4.3)); reject otherwise; 2. decode the JWS Compact serialization and check that it has exactly three segments; 3. check that the protected header contains and that its value is allowed by the local policy (Verification Policy (Appendix B.7.3)); reject otherwise; 4. locate the verification key using or another mechanism (Key Management (Appendix B.8)); 5. rebuild the payload object from the alert and as defined in Payload Structure (Normative) (Appendix B.3.2); if a referenced attribute is absent, reject (Absent or Invalid Attributes (Appendix B.3.3)); Lehmann & Andrejak Expires 27 April 2027 [Page 61] Internet-Draft IDMEFv2 October 2026 6. canonicalize this object with JCS and compare the result with the decoded payload; reject on any difference; 7. verify the cryptographic signature using the identified key and algorithm; reject on failure; 8. on success, consider as intact and authentic only the attributes listed in . Note: An alert whose and have been removed becomes an unsigned alert. Recipients *SHOULD* apply an explicit policy (rejection or marking) to unsigned alerts when a signature is expected. B.10. Security Considerations B.10.1. Key Protection Private keys *MUST* be protected against unauthorized access. Implementations *SHOULD* use hardware security modules (HSM) or secure enclaves for key storage. B.10.2. Algorithm Agility To ensure the long-term security of IDMEFv2 alerts, implementations *SHOULD* support algorithm agility, allowing migration to newer algorithms as cryptographic best practices evolve. As post-quantum signature algorithms (for example ML-DSA, SLH-DSA) are standardized and become widely available, they *MAY* be used in place of, or in combination with, classical algorithms (for example via hybrid signatures). The parameter facilitates this transition by enabling different key types to be identified without changing the IDMEFv2 data model. B.10.3. Replay Attacks JWS does not inherently prevent replay attacks. Implementations *SHOULD* include time-based attributes among the signed attributes (for example ) and/or rely on transport-layer security. The use of JWT-like / claims is *outside the scope* of the IDMEFv2 model and *MUST NOT* be assumed by a generic verifier. B.10.4. Key Rotation Regular key rotation *SHOULD* be implemented. The parameter facilitates it by allowing the recipient to identify the key used. B.11. Complete Example Lehmann & Andrejak Expires 27 April 2027 [Page 62] Internet-Draft IDMEFv2 October 2026 { "Version": "2.D.V08", "ID": "123e4567-e89b-12d3-a456-426614174000", "CreateTime": "2024-05-21T14:30:00Z", "Type": "Cyber", "Category": "Access.Compromise", "Confidence": 0.95, "Analyzer": { "ID": "analyzer01", "Name": "Corporate EDR", "IP": "192.0.2.10" }, "Source": [ { "IP": "198.51.100.20" } ], "SignedAttributes": [ "Version", "ID", "CreateTime", "Type", "Category", "Analyzer.ID", "Analyzer.Name", "Source(0).IP" ], "Signature": "" } The corresponding canonicalized payload (before base64url encoding) is: {"Analyzer":{"ID":"analyzer01","Name":"Corporate EDR"},"Category":"Access.Compromise","CreateTime":"2024-05-21T14:30:00Z","ID":"123e4567-e89b-12d3-a456-426614174000","SignedAttributes":["Version","ID","CreateTime","Type","Category","Analyzer.ID","Analyzer.Name","Source(0).IP"],"Source":[{"IP":"198.51.100.20"}],"Type":"Cyber","Version":"2.D.V08"} Note: ``Confidence`` and ``Analyzer.IP`` do not appear in the payload because they are not listed in ``SignedAttributes``. Signed and verifiable test vectors **MUST** accompany the final version. B.12. Conformance and Test Vectors An implementation is conformant with this annex if it satisfies all the *MUST* and *MUST NOT* requirements above. The final version *MUST* provide: * at least one test vector per supported algorithm (Supported Algorithms (Appendix B.7.1)); * one negative test vector per rejection case (Absent or Invalid Attributes (Appendix B.3.3), Consistency (Appendix B.4.3), Verification Policy (Appendix B.7.3), Verification Procedure (Appendix B.9)); * the expected canonicalized payload and signature values. B.13. References Lehmann & Andrejak Expires 27 April 2027 [Page 63] Internet-Draft IDMEFv2 October 2026 B.13.1. Normative References * RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels * RFC 7515 — JSON Web Signature (JWS) * RFC 7517 — JSON Web Key (JWK) * RFC 7518 — JSON Web Algorithms (JWA) * RFC 7493 — The I-JSON Message Format * RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format * RFC 8785 — JSON Canonicalization Scheme (JCS) * IDMEFv2 Draft — draft-lehmann-idmefv2-08 (Section 3.3.12) B.13.2. Informative References * RFC 7519 — JSON Web Token (JWT) * RFC 7797 — JSON Web Signature (JWS) Unencoded Payload Option Appendix C. Enumerations C.1. Entity Sector +======+==================================+========================+ | Rank | Keyword | Definition | +======+==================================+========================+ | 0 | Undefined | Sector undefined | +------+----------------------------------+------------------------+ | 1 | Administration.CentralGovernment | Central government | | | | ministries and | | | | agencies | +------+----------------------------------+------------------------+ | 2 | Administration.Diplomatic | Embassies, consulates, | | | | and diplomatic | | | | missions | +------+----------------------------------+------------------------+ | 3 | Administration.EmergencyServices | Police, fire, rescue, | | | | and emergency medical | | | | services | +------+----------------------------------+------------------------+ | 4 | Administration.Judiciary | Courts, judicial | Lehmann & Andrejak Expires 27 April 2027 [Page 64] Internet-Draft IDMEFv2 October 2026 | | | systems, and | | | | correctional | | | | facilities | +------+----------------------------------+------------------------+ | 5 | Administration.Local | Regional and municipal | | | | public services | +------+----------------------------------+------------------------+ | 6 | Administration.Other | Other public | | | | administration | | | | entities critical for | | | | the continuity of | | | | public services | +------+----------------------------------+------------------------+ | 7 | Banking.Banking | Banking institutions | | | | and credit activities | +------+----------------------------------+------------------------+ | 8 | Banking.Other | Other banking and | | | | financial entities | | | | critical for the | | | | stability of the | | | | financial system | +------+----------------------------------+------------------------+ | 9 | Cemeteries.Crematoria | Crematoria operations | +------+----------------------------------+------------------------+ | 10 | Cemeteries.Public | Public cemetery and | | | | crematorium facilities | +------+----------------------------------+------------------------+ | 11 | Cemeteries.Other | Other cemetery and | | | | funeral service | | | | entities critical for | | | | public health and | | | | social continuity | +------+----------------------------------+------------------------+ | 12 | Chemical.Production | Production of | | | | hazardous and high- | | | | consequence chemicals | +------+----------------------------------+------------------------+ | 13 | Chemical.Storage | Chemical storage and | | | | distribution | | | | facilities | +------+----------------------------------+------------------------+ | 14 | Chemical.Other | Other chemical sector | | | | entities critical for | | | | safety and security | +------+----------------------------------+------------------------+ | 15 | Civil.ElectionMonitoring | Election observation | | | | and monitoring | | | | entities | Lehmann & Andrejak Expires 27 April 2027 [Page 65] Internet-Draft IDMEFv2 October 2026 +------+----------------------------------+------------------------+ | 16 | Civil.HumanitarianAid | Humanitarian aid | | | | organizations | +------+----------------------------------+------------------------+ | 17 | Civil.NGOs | Non-governmental | | | | organizations with | | | | critical functions | +------+----------------------------------+------------------------+ | 18 | Civil.Other | Other civil society | | | | entities critical for | | | | democratic processes | | | | and social stability | +------+----------------------------------+------------------------+ | 19 | Cultural.Archives | National and regional | | | | archives | +------+----------------------------------+------------------------+ | 20 | Cultural.HistoricalSites | Historical monuments | | | | and archaeological | | | | sites | +------+----------------------------------+------------------------+ | 21 | Cultural.Libraries | National and public | | | | libraries | +------+----------------------------------+------------------------+ | 22 | Cultural.Museums | Museums and exhibition | | | | spaces | +------+----------------------------------+------------------------+ | 23 | Cultural.Other | Other cultural | | | | heritage entities | | | | critical for national | | | | identity and | | | | continuity | +------+----------------------------------+------------------------+ | 24 | Defense.CommandControl | Military C4ISR systems | | | | (command, control, | | | | communications, | | | | computers, | | | | intelligence, | | | | surveillance, | | | | reconnaissance) | +------+----------------------------------+------------------------+ | 25 | Defense.Cyber | Military cyber defense | | | | and security | | | | operations centers | +------+----------------------------------+------------------------+ | 26 | Defense.IndustrialBase | Defense manufacturing, | | | | weapons systems, | | | | munitions production | +------+----------------------------------+------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 66] Internet-Draft IDMEFv2 October 2026 | 27 | Defense.Logistics | Military supply | | | | chains, fuel depots, | | | | ammunition storage | +------+----------------------------------+------------------------+ | 28 | Defense.Installations | Military bases, | | | | headquarters, and | | | | operational facilities | +------+----------------------------------+------------------------+ | 29 | Defense.Research | Defense laboratories | | | | and R&D facilities | +------+----------------------------------+------------------------+ | 30 | Defense.Other | Other defense and | | | | military entities | | | | critical for national | | | | security | +------+----------------------------------+------------------------+ | 31 | Digital.CloudServices | Cloud computing and | | | | critical digital | | | | services | +------+----------------------------------+------------------------+ | 32 | Digital.DataCenters | Data center hosting | | | | and infrastructure | | | | services | +------+----------------------------------+------------------------+ | 33 | Digital.DigitalProviders | Online marketplaces, | | | | search engines and | | | | social media platforms | +------+----------------------------------+------------------------+ | 34 | Digital.DomainNameSystems | DNS service providers | | | | and TLD registries | +------+----------------------------------+------------------------+ | 35 | Digital.ICTServiceManagement | ICT service management | | | | B2B services | +------+----------------------------------+------------------------+ | 36 | Digital.SatelliteCommunications | Satellite | | | | communication networks | | | | and ground stations | +------+----------------------------------+------------------------+ | 37 | Digital.TelecomNetworks | Fixed and mobile | | | | telecommunications | | | | networks | +------+----------------------------------+------------------------+ | 38 | Digital.UnderseaCables | Submarine | | | | communications cable | | | | infrastructure | +------+----------------------------------+------------------------+ | 39 | Digital.Other | Other digital and | | | | telecommunications | Lehmann & Andrejak Expires 27 April 2027 [Page 67] Internet-Draft IDMEFv2 October 2026 | | | entities critical for | | | | the continuity of | | | | digital services | +------+----------------------------------+------------------------+ | 40 | Education.PrimarySecondary | Primary and secondary | | | | schools | +------+----------------------------------+------------------------+ | 41 | Education.ResearchSchools | Research-focused | | | | educational | | | | institutions | +------+----------------------------------+------------------------+ | 42 | Education.Universities | Universities and | | | | higher education | | | | institutions | +------+----------------------------------+------------------------+ | 43 | Education.Other | Other educational | | | | entities critical for | | | | societal continuity | +------+----------------------------------+------------------------+ | 44 | Emergency.CivilProtection | Civil protection and | | | | disaster management | | | | agencies | +------+----------------------------------+------------------------+ | 45 | Emergency.Medical | Ambulance services and | | | | emergency medical | | | | response | +------+----------------------------------+------------------------+ | 46 | Emergency.FireAndRescue | Firefighting and | | | | rescue services | +------+----------------------------------+------------------------+ | 47 | Emergency.Police | Law enforcement | | | | agencies and | | | | operations | +------+----------------------------------+------------------------+ | 48 | Emergency.Other | Other emergency | | | | response entities | | | | critical for public | | | | safety | +------+----------------------------------+------------------------+ | 49 | Energy.DistrictHeating | Operation of district | | | | heating networks | +------+----------------------------------+------------------------+ | 50 | Energy.Electricity | Generation, | | | | transmission and | | | | distribution of | | | | electrical power | +------+----------------------------------+------------------------+ | 51 | Energy.Gas | Transport, storage and | Lehmann & Andrejak Expires 27 April 2027 [Page 68] Internet-Draft IDMEFv2 October 2026 | | | distribution of | | | | natural gas | +------+----------------------------------+------------------------+ | 52 | Energy.Hydrogen | Production, transport | | | | and storage of | | | | hydrogen | +------+----------------------------------+------------------------+ | 53 | Energy.Nuclear | Nuclear power | | | | generation and fuel | | | | cycle facilities | +------+----------------------------------+------------------------+ | 54 | Energy.Oil | Refining, transport | | | | and storage of | | | | petroleum products | +------+----------------------------------+------------------------+ | 55 | Energy.Other | Other energy entities | | | | critical for the | | | | continuity of energy | | | | supply | +------+----------------------------------+------------------------+ | 56 | Finance.MarketInfrastructures | Stock exchanges and | | | | clearing houses | +------+----------------------------------+------------------------+ | 57 | Finance.Insurance | Systemically important | | | | insurance entities | +------+----------------------------------+------------------------+ | 58 | Finance.PaymentSystems | Card schemes, | | | | transfers and instant | | | | payment systems | +------+----------------------------------+------------------------+ | 59 | Finance.Other | Other financial | | | | entities critical for | | | | the stability of the | | | | financial system | +------+----------------------------------+------------------------+ | 60 | Food.AgriculturalProduction | Strategic agricultural | | | | and livestock | | | | production | +------+----------------------------------+------------------------+ | 61 | Food.FoodDistribution | Retail and logistics | | | | for food supply chains | +------+----------------------------------+------------------------+ | 62 | Food.FoodProcessing | Industrial food | | | | processing and | | | | manufacturing | +------+----------------------------------+------------------------+ | 63 | Food.FoodSafety | Food safety inspection | | | | and control | Lehmann & Andrejak Expires 27 April 2027 [Page 69] Internet-Draft IDMEFv2 October 2026 | | | authorities | +------+----------------------------------+------------------------+ | 64 | Food.Other | Other food sector | | | | entities critical for | | | | the continuity of the | | | | food supply chain | +------+----------------------------------+------------------------+ | 65 | Health.BloodAndTissue | Blood banks, tissue | | | | banks, and | | | | transplantation | | | | services | +------+----------------------------------+------------------------+ | 66 | Health.HealthcareProviders | Hospitals and clinics | | | | providing essential | | | | care | +------+----------------------------------+------------------------+ | 67 | Health.Laboratories | Medical analysis and | | | | diagnostic | | | | laboratories | +------+----------------------------------+------------------------+ | 68 | Health.MedicalDevices | Manufacture and | | | | maintenance of | | | | critical medical | | | | devices | +------+----------------------------------+------------------------+ | 69 | Health.PharmaceuticalSupplyChain | Manufacturing, | | | | wholesale and | | | | distribution of | | | | pharmaceuticals | +------+----------------------------------+------------------------+ | 70 | Health.PublicHealth | Public health agencies | | | | and epidemiological | | | | surveillance | +------+----------------------------------+------------------------+ | 71 | Health.Other | Other health entities | | | | critical for the | | | | continuity of | | | | healthcare services | +------+----------------------------------+------------------------+ | 72 | Logistics.FreightForwarding | Freight forwarding and | | | | cargo management | +------+----------------------------------+------------------------+ | 73 | Logistics.LastMileDelivery | Last-mile delivery | | | | services | +------+----------------------------------+------------------------+ | 74 | Logistics.ThirdPartyLogistics | Third-party logistics | | | | providers | +------+----------------------------------+------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 70] Internet-Draft IDMEFv2 October 2026 | 75 | Logistics.Warehousing | Strategic warehousing | | | | and storage facilities | +------+----------------------------------+------------------------+ | 76 | Logistics.Other | Other logistics | | | | entities critical for | | | | supply chain | | | | continuity | +------+----------------------------------+------------------------+ | 77 | Manufacturing.Aerospace | Aerospace and aviation | | | | manufacturing | +------+----------------------------------+------------------------+ | 78 | Manufacturing.Batteries | Battery manufacturing | | | | and energy storage | | | | production | +------+----------------------------------+------------------------+ | 79 | Manufacturing.Chemical | Chemical manufacturing | | | | and industrial | | | | processes | +------+----------------------------------+------------------------+ | 80 | Manufacturing.Electronic | Manufacture of | | | | computer, electronic | | | | and optical products | +------+----------------------------------+------------------------+ | 81 | Manufacturing.Defense | Defense manufacturing | | | | and strategic military | | | | supply chains | +------+----------------------------------+------------------------+ | 82 | Manufacturing.MedicalDevices | Manufacture of medical | | | | devices and equipment | +------+----------------------------------+------------------------+ | 83 | Manufacturing.MotorVehicles | Manufacture of motor | | | | vehicles and transport | | | | equipment | +------+----------------------------------+------------------------+ | 84 | Manufacturing.Pharmaceutical | Pharmaceutical | | | | manufacturing and | | | | active pharmaceutical | | | | ingredients | +------+----------------------------------+------------------------+ | 85 | Manufacturing.Semiconductors | Semiconductor | | | | fabrication and | | | | microelectronics | | | | manufacturing | +------+----------------------------------+------------------------+ | 86 | Manufacturing.Strategic | Critical manufacturing | | | | such as metallurgy and | | | | components | +------+----------------------------------+------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 71] Internet-Draft IDMEFv2 October 2026 | 87 | Manufacturing.Other | Other manufacturing | | | | entities critical for | | | | industrial resilience | | | | and strategic supply | | | | chains | +------+----------------------------------+------------------------+ | 88 | Media.Infrastructure | Transmitters, towers, | | | | and broadcast | | | | distribution | | | | infrastructure | +------+----------------------------------+------------------------+ | 89 | Media.OnlineMedia | Digital news platforms | | | | and content providers | +------+----------------------------------+------------------------+ | 90 | Media.Press | Newspapers, publishing | | | | houses, and press | | | | agencies | +------+----------------------------------+------------------------+ | 91 | Media.Radio | Radio broadcasting | | | | networks and studios | +------+----------------------------------+------------------------+ | 92 | Media.Television | Television | | | | broadcasting networks | | | | and studios | +------+----------------------------------+------------------------+ | 93 | Media.Other | Other media entities | | | | critical for | | | | information integrity | | | | and public | | | | communication | +------+----------------------------------+------------------------+ | 94 | Mining.CriticalRawMaterials | Extraction and | | | | processing of critical | | | | raw materials | +------+----------------------------------+------------------------+ | 95 | Mining.EnergyMinerals | Coal, uranium, and | | | | other energy mineral | | | | mining | +------+----------------------------------+------------------------+ | 96 | Mining.Other | Other mining entities | | | | critical for resource | | | | security | +------+----------------------------------+------------------------+ | 97 | Nuclear.FuelCycle | Nuclear fuel | | | | production, | | | | enrichment, | | | | reprocessing, and | | | | waste management | Lehmann & Andrejak Expires 27 April 2027 [Page 72] Internet-Draft IDMEFv2 October 2026 +------+----------------------------------+------------------------+ | 98 | Nuclear.Medical | Nuclear medical | | | | facilities and | | | | radioisotope | | | | production | +------+----------------------------------+------------------------+ | 99 | Nuclear.PowerGeneration | Civil nuclear power | | | | plants and associated | | | | facilities | +------+----------------------------------+------------------------+ | 100 | Nuclear.Research | Nuclear research | | | | reactors and | | | | laboratories | +------+----------------------------------+------------------------+ | 101 | Nuclear.Other | Other nuclear entities | | | | critical for safety | | | | and security | +------+----------------------------------+------------------------+ | 102 | Postal.CourierServices | Postal and courier | | | | services | +------+----------------------------------+------------------------+ | 103 | Postal.Other | Other postal and | | | | courier entities | | | | critical for the | | | | continuity of mail and | | | | parcel services | +------+----------------------------------+------------------------+ | 104 | Religious.PilgrimageSites | Major pilgrimage | | | | destinations | +------+----------------------------------+------------------------+ | 105 | Religious.PlacesOfWorship | Churches, mosques, | | | | synagogues, temples, | | | | and other religious | | | | buildings | +------+----------------------------------+------------------------+ | 106 | Religious.Other | Other religious sites | | | | critical for community | | | | continuity | +------+----------------------------------+------------------------+ | 107 | Research.BiologicalSafety | BSL-3 and BSL-4 high- | | | | containment | | | | laboratories | +------+----------------------------------+------------------------+ | 108 | Research.ChemicalSafety | High-containment | | | | chemical research | | | | facilities | +------+----------------------------------+------------------------+ | 109 | Research.Research | Key research | Lehmann & Andrejak Expires 27 April 2027 [Page 73] Internet-Draft IDMEFv2 October 2026 | | | laboratories with | | | | strategic importance | +------+----------------------------------+------------------------+ | 110 | Research.Other | Other research | | | | entities critical for | | | | strategic research | | | | continuity and | | | | innovation | +------+----------------------------------+------------------------+ | 111 | Space.GroundStations | Satellite ground | | | | control and telemetry | | | | stations | +------+----------------------------------+------------------------+ | 112 | Space.LaunchFacilities | Space launch sites and | | | | associated | | | | infrastructure | +------+----------------------------------+------------------------+ | 113 | Space.SpaceActivities | Space industry and | | | | satellite operations | +------+----------------------------------+------------------------+ | 114 | Space.Other | Other space entities | | | | critical for the | | | | continuity of space- | | | | based services and | | | | infrastructure | +------+----------------------------------+------------------------+ | 115 | Transport.Aviation | Airports, air traffic | | | | control and airline | | | | operations | +------+----------------------------------+------------------------+ | 116 | Transport.Maritime | Ports, terminals and | | | | maritime traffic | | | | management | +------+----------------------------------+------------------------+ | 117 | Transport.Pipeline | Oil, gas, and hydrogen | | | | pipeline | | | | infrastructure | +------+----------------------------------+------------------------+ | 118 | Transport.PublicTransport | Urban and regional | | | | public transportation | | | | systems | +------+----------------------------------+------------------------+ | 119 | Transport.Rail | Railway infrastructure | | | | and train operations | +------+----------------------------------+------------------------+ | 120 | Transport.Road | Traffic management and | | | | strategic road | | | | logistics | Lehmann & Andrejak Expires 27 April 2027 [Page 74] Internet-Draft IDMEFv2 October 2026 +------+----------------------------------+------------------------+ | 121 | Transport.Other | Other transport | | | | entities critical for | | | | the continuity of | | | | passenger and freight | | | | mobility | +------+----------------------------------+------------------------+ | 122 | Waste.Hazardous | Collection, treatment | | | | and disposal of | | | | hazardous waste | +------+----------------------------------+------------------------+ | 123 | Waste.NonHazardous | Management of non- | | | | hazardous solid waste | +------+----------------------------------+------------------------+ | 124 | Waste.Nuclear | Nuclear waste | | | | management and storage | | | | facilities | +------+----------------------------------+------------------------+ | 125 | Waste.Recycling | Waste processing and | | | | recycling operations | +------+----------------------------------+------------------------+ | 126 | Waste.Other | Other waste management | | | | entities critical for | | | | the continuity of | | | | waste services | +------+----------------------------------+------------------------+ | 127 | Water.DamsAndReservoirs | Dam and reservoir | | | | infrastructure for | | | | water management | +------+----------------------------------+------------------------+ | 128 | Water.DrinkingWater | Capture, treatment and | | | | distribution of | | | | potable water | +------+----------------------------------+------------------------+ | 129 | Water.Irrigation | Large-scale | | | | agricultural | | | | irrigation systems | +------+----------------------------------+------------------------+ | 130 | Water.Wastewater | Collection and | | | | treatment of sewage | | | | and wastewater | +------+----------------------------------+------------------------+ | 131 | Water.Other | Other water entities | | | | critical for the | | | | continuity of water | | | | supply and sanitation | +------+----------------------------------+------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 75] Internet-Draft IDMEFv2 October 2026 Table 9: enum_alert_entitysector C.2. Alert Category +======+===============================+============================+ | Rank | Keyword | Description | +======+===============================+============================+ | 0 | Abuse.Coercion | The practice of | | | | compelling an individual | | | | to act against their | | | | will by using force, | | | | threats, intimidation, | | | | or extreme dependency, | | | | often for personal or | | | | financial gain. | | | | Examples: an insider | | | | forced by a third party | | | | to disclose credentials, | | | | a person pressured into | | | | handing over access | | | | badges. | +------+-------------------------------+----------------------------+ | 1 | Abuse.Extremism | The process of | | | | socializing an | | | | individual, often | | | | through psychological | | | | manipulation, to adopt | | | | the beliefs and goals of | | | | a violent extremist | | | | group and become willing | | | | to engage in activities | | | | that support the group. | | | | Examples: online | | | | radicalization through | | | | extremist forums, | | | | recruitment within a | | | | closed community. | +------+-------------------------------+----------------------------+ | 2 | Abuse.Grooming | The deliberate process | | | | of building an emotional | | | | connection and trust | | | | with a person to lower | | | | their inhibitions and | | | | defenses, in order to | | | | psychologically | | | | manipulate them for | | | | purposes such as sexual | | | | abuse, exploitation, | Lehmann & Andrejak Expires 27 April 2027 [Page 76] Internet-Draft IDMEFv2 October 2026 | | | trafficking, financial | | | | fraud, organizational | | | | coercion, or illicit | | | | insider activity. Ex: | | | | an adult building trust | | | | with a minor via a | | | | gaming platform, with | | | | repeated "friendly" | | | | contacts near a school; | | | | or a colleague | | | | cultivating a | | | | relationship of | | | | dependency to draw | | | | someone into fraud or | | | | insider dealing. | +------+-------------------------------+----------------------------+ | 3 | Abuse.Harassment | A pattern of unwanted, | | | | intrusive behaviour | | | | (physical, verbal, or | | | | online) directed at a | | | | specific person that | | | | causes fear, distress, | | | | or emotional harm, or | | | | any such | | | | behaviour—including a | | | | single severe | | | | incident—that creates a | | | | hostile or intimidating | | | | environment. Ex: | | | | sustained threatening | | | | messages on social | | | | media, repeated | | | | following of an | | | | employee, or a one-off | | | | serious act of | | | | intimidation. | +------+-------------------------------+----------------------------+ | 4 | Abuse.Trafficking | The act of recruiting, | | | | transporting, | | | | transferring, | | | | harbouring, or receiving | | | | a person through force, | | | | fraud, or coercion for | | | | the purpose of | | | | exploitation, such as | | | | forced labour or sexual | | | | servitude. Ex: | | | | recruitment via fake job | Lehmann & Andrejak Expires 27 April 2027 [Page 77] Internet-Draft IDMEFv2 October 2026 | | | ads for forced online | | | | scams, transport of | | | | victims across a border. | +------+-------------------------------+----------------------------+ | 5 | Abuse.Other | Any other incident | | | | involving manipulation | | | | or coercion of people | | | | for harmful purposes | | | | that does not fit into | | | | the specific abuse | | | | subcategories. | | | | Examples: psychological | | | | domination of a remote | | | | worker, confinement of a | | | | person. | +------+-------------------------------+----------------------------+ | 6 | Access.Authorized | An incident involving | | | | legitimate, approved | | | | physical or digital | | | | access to resources that | | | | may be relevant for | | | | auditing, monitoring, or | | | | establishing a baseline | | | | of normal activity. | | | | Examples: an admin login | | | | during a maintenance | | | | window, an employee | | | | entering a server room | | | | with a valid badge, a | | | | packet accepted through | | | | a firewall. | +------+-------------------------------+----------------------------+ | 7 | Access.Backdoor | The installation or | | | | discovery of a concealed | | | | method of bypassing | | | | normal authentication or | | | | encryption in a computer | | | | system, product, | | | | embedded device or a | | | | building. Examples: a | | | | hidden SSH key installed | | | | on a server, a concealed | | | | door in a facility. | +------+-------------------------------+----------------------------+ | 8 | Access.Cloned | The act of creating an | | | | unauthorized copy of a | | | | physical or digital | | | | security credential, | Lehmann & Andrejak Expires 27 April 2027 [Page 78] Internet-Draft IDMEFv2 October 2026 | | | such as an access card, | | | | to gain illicit entry to | | | | a facility or system. | | | | Examples: a duplicated | | | | RFID badge, a copied key | | | | to a locked cabinet. | +------+-------------------------------+----------------------------+ | 9 | Access.Compromise | An incident where a | | | | legitimate user's | | | | credentials (e.g., | | | | username/password, | | | | session tokens, API | | | | keys, SSH keys and | | | | biometric spoofing) are | | | | stolen or guessed and | | | | used by an unauthorized | | | | individual to gain | | | | access to systems or | | | | data. Examples: stolen | | | | VPN credentials reused | | | | by an attacker, a stolen | | | | badge used to enter a | | | | building. | +------+-------------------------------+----------------------------+ | 10 | Access.Escalation | An incident where a user | | | | or process gains access | | | | rights, permissions, or | | | | capabilities that exceed | | | | those normally assigned, | | | | often to bypass security | | | | restrictions. Examples: | | | | privilege escalation to | | | | domain admin, a visitor | | | | reaching a restricted | | | | floor. | +------+-------------------------------+----------------------------+ | 11 | Access.Expired | An event indicating that | | | | an access attempt was | | | | made using credentials, | | | | tokens, or a badge whose | | | | validity period has | | | | ended. The incident may | | | | be benign (an oversight) | | | | or malicious (deliberate | | | | reuse of expired | | | | credentials to bypass | | | | controls). Examples ): | | | | a session token past its | Lehmann & Andrejak Expires 27 April 2027 [Page 79] Internet-Draft IDMEFv2 October 2026 | | | expiration is accepted | | | | by an application due to | | | | a validation flaw, | | | | granting continued | | | | access , an individual | | | | enters a protected area | | | | using an access badge | | | | whose authorization | | | | expired after their | | | | training lapsed . | +------+-------------------------------+----------------------------+ | 12 | Access.Forced | An incident involving | | | | the use of physical | | | | force to breach a | | | | barrier (e.g., lock, | | | | door, window) or the | | | | repeated systematic | | | | guessing of passwords to | | | | gain unauthorized access | | | | (brute-force attack). | | | | Examples: a brute-force | | | | attack on an SSH | | | | service, forced entry | | | | through a window. | +------+-------------------------------+----------------------------+ | 13 | Access.Lost | An incident where | | | | physical or digital | | | | access credentials | | | | (e.g., keys, ID badges, | | | | login details) are | | | | misplaced, stolen, or | | | | used by an unauthorized | | | | person. Examples: a | | | | lost hardware token, a | | | | misplaced key ring. | +------+-------------------------------+----------------------------+ | 14 | Access.Tailgating | A security breach where | | | | an unauthorized person | | | | follows an authorized | | | | individual through a | | | | secured entry point, | | | | circumventing access | | | | control mechanisms. | | | | Examples: following an | | | | employee through a badge | | | | door, session hijacking | | | | after an authenticated | | | | user. | Lehmann & Andrejak Expires 27 April 2027 [Page 80] Internet-Draft IDMEFv2 October 2026 +------+-------------------------------+----------------------------+ | 15 | Access.Unauthorized | Incident involving | | | | unauthorized access to a | | | | restricted building, | | | | room, area, system, | | | | network, application, | | | | account, or data | | | | resource, whether actual | | | | or attempted. Examples: | | | | a connection to a | | | | database without rights, | | | | entry into a restricted | | | | area, packet denied by a | | | | firewall. | +------+-------------------------------+----------------------------+ | 16 | Access.Other | Any other incident | | | | related to physical or | | | | digital access that does | | | | not fit into the | | | | specific access | | | | subcategories. | | | | Examples: access via an | | | | undocumented API, entry | | | | through an unmonitored | | | | gate. | +------+-------------------------------+----------------------------+ | 17 | Anomaly.Burst | A sudden, abrupt, high- | | | | amplitude deviation over | | | | a short window, whether | | | | or not followed by a | | | | return to normal. | | | | Examples: a sudden spike | | | | in connections or | | | | requests, a panic | | | | movement in a crowd, a | | | | sudden gust or storm, a | | | | pollution peak. | +------+-------------------------------+----------------------------+ | 18 | Anomaly.Chaos | A disordered, | | | | unpredictable behavior | | | | with high entropy, | | | | showing no identifiable | | | | pattern or stable | | | | structure. Examples: | | | | erratic network traffic, | | | | chaotic crowd movement, | | | | atmospheric turbulence, | | | | uncontrolled spread of a | Lehmann & Andrejak Expires 27 April 2027 [Page 81] Internet-Draft IDMEFv2 October 2026 | | | wildfire. | +------+-------------------------------+----------------------------+ | 19 | Anomaly.Context | A behavior that is | | | | normal in absolute terms | | | | but abnormal in its | | | | context (location, role, | | | | time, system state, | | | | threat level). | | | | Examples: an admin | | | | logging in from an | | | | unusual country, a | | | | vehicle on a forbidden | | | | lane, ordinary activity | | | | during a crisis, a | | | | normal crowd in a place | | | | where it is not | | | | expected. | +------+-------------------------------+----------------------------+ | 20 | Anomaly.Correlation | An unusual covariation | | | | between several | | | | entities, signals, or | | | | domains that should not | | | | evolve together, or the | | | | breaking of a normally | | | | expected correlation. | | | | Examples: correlation | | | | between VPN access and | | | | physical access, between | | | | weather and incidents, | | | | between network flows | | | | and crowd behavior; or | | | | conversely, a sensor | | | | losing its expected | | | | correlation. | +------+-------------------------------+----------------------------+ | 21 | Anomaly.Deviation | Any measurable deviation | | | | from an established | | | | behavior, baseline, or | | | | norm, without | | | | presupposing its | | | | temporal shape or | | | | amplitude. This is the | | | | generic subcategory, to | | | | be used when no other | | | | applies. Examples: a | | | | user account logging in | | | | from an unusual | | | | location, a crowd whose | Lehmann & Andrejak Expires 27 April 2027 [Page 82] Internet-Draft IDMEFv2 October 2026 | | | density exceeds the | | | | normal range, an out-of- | | | | season temperature. | +------+-------------------------------+----------------------------+ | 22 | Anomaly.Drift | A slow, gradual, and | | | | almost imperceptible | | | | deviation that settles | | | | over time and only | | | | becomes visible when | | | | comparing distant time | | | | windows. Examples: slow | | | | drift of an account's | | | | privileges, gradual | | | | erosion of an | | | | infrastructure, | | | | progressive warming, | | | | slow change in crowd or | | | | traffic composition. | +------+-------------------------------+----------------------------+ | 23 | Anomaly.Oscillation | A repeated alternation | | | | between two or more | | | | states, without | | | | convergence or | | | | stabilisation, over a | | | | given window. Examples: | | | | flapping of a service, | | | | back-and-forth movement | | | | of a crowd, sensor | | | | oscillation, alternating | | | | weather conditions. | +------+-------------------------------+----------------------------+ | 24 | Anomaly.Relation | A deviation affecting | | | | the set, structure, or | | | | topology of relations | | | | between an asset and | | | | other assets, rather | | | | than the asset's own | | | | value, timing, or | | | | sequence. Examples: a | | | | workstation that | | | | normally connects to a | | | | stable set of servers | | | | suddenly connects to a | | | | new one; an asset whose | | | | movement pattern shifts | | | | to an entirely new set | | | | of locations. | +------+-------------------------------+----------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 83] Internet-Draft IDMEFv2 October 2026 | 25 | Anomaly.Sequence | An anomaly affecting the | | | | order, succession, or | | | | cadence of normally | | | | expected events, rather | | | | than their value. | | | | Examples: process steps | | | | reversed or skipped, | | | | unusual movement order | | | | in a crowd, atypical | | | | weather sequence (frost | | | | then out-of-season | | | | heatwave). | +------+-------------------------------+----------------------------+ | 26 | Anomaly.Threshold | Crossing a predefined | | | | threshold by a simple, | | | | non-statistical rule, | | | | without baseline | | | | analysis. Examples: a | | | | temperature threshold, a | | | | crowd density threshold, | | | | a connection attempt | | | | threshold, a network | | | | throughput threshold. | +------+-------------------------------+----------------------------+ | 27 | Anomaly.Timing | An anomaly affecting the | | | | moment when an event | | | | occurs, normal in itself | | | | but happening at an | | | | unusual time. Examples: | | | | a login at an atypical | | | | hour, a crowd arriving | | | | too early or too late, | | | | out-of-season rain, | | | | activity outside | | | | expected hours. | +------+-------------------------------+----------------------------+ | 28 | Anomaly.Unknown | An anomaly that has been | | | | detected but cannot be | | | | classified into the | | | | subcategories above, or | | | | whose nature remains | | | | undetermined after | | | | analysis. Examples: an | | | | unclassified deviation | | | | flagged by a detection | | | | system, an anomaly whose | | | | cause is still under | | | | investigation. | Lehmann & Andrejak Expires 27 April 2027 [Page 84] Internet-Draft IDMEFv2 October 2026 +------+-------------------------------+----------------------------+ | 29 | Anomaly.Other | Any other anomaly that | | | | does not fit into the | | | | specific subcategories. | | | | Examples: a deviation | | | | that combines several | | | | anomaly types without a | | | | dominant one. | +------+-------------------------------+----------------------------+ | 30 | Availability.DDoS | An incident where | | | | multiple compromised | | | | systems (botnet), assets | | | | or individuals are used | | | | to target a single | | | | system with a flood of | | | | traffic, causing a | | | | denial of service. | | | | Examples: a botnet | | | | flooding a web service, | | | | saturation of a phone | | | | exchange. | +------+-------------------------------+----------------------------+ | 31 | Availability.DoS | An incident where a | | | | single machine or | | | | network attempts to make | | | | a system, service, or | | | | network resource | | | | unavailable by | | | | overwhelming it with | | | | malicious requests or | | | | traffic. Examples: a | | | | single-host SYN flood, | | | | jamming of a radio | | | | channel. | +------+-------------------------------+----------------------------+ | 32 | Availability.Failure | An incident caused by | | | | the unintentional | | | | malfunction of hardware | | | | or software due to | | | | errors, bugs, wear and | | | | tear, or other faults, | | | | leading to service | | | | degradation or | | | | unavailability. | | | | Examples: a disk failure | | | | taking down a database, | | | | a pump failure stopping | | | | water supply, a car | Lehmann & Andrejak Expires 27 April 2027 [Page 85] Internet-Draft IDMEFv2 October 2026 | | | breakdown. | +------+-------------------------------+----------------------------+ | 33 | Availability.Flapping | A pattern of rapid, | | | | repeated transitions | | | | between operational | | | | states (such as up and | | | | down) of a system, | | | | service, process, or | | | | component within a short | | | | time window. Examples: | | | | a service alternating up | | | | and down, an | | | | intermittent power | | | | relay. | +------+-------------------------------+----------------------------+ | 34 | Availability.Heartbeat | A periodic signal | | | | generated by hardware, | | | | software or individual | | | | to indicate normal | | | | operation, often used | | | | for monitoring system | | | | health, connectivity, or | | | | location tracking. | | | | Examples: a keep-alive | | | | signal from an agent, a | | | | periodic beacon from a | | | | patrol device. | +------+-------------------------------+----------------------------+ | 35 | Availability.Misconfiguration | An incident where | | | | incorrect configuration | | | | of systems, software, or | | | | networks leads to | | | | service disruptions, | | | | outages, or security | | | | vulnerabilities. | | | | Examples: a wrong | | | | firewall rule blocking | | | | traffic, a mis-set HVAC | | | | control. | +------+-------------------------------+----------------------------+ | 36 | Availability.Outage | An incident where | | | | essential utilities or | | | | services (such as | | | | electricity, water, or | | | | network connectivity) | | | | become unavailable, | | | | disrupting normal | | | | operations. Examples: a | Lehmann & Andrejak Expires 27 April 2027 [Page 86] Internet-Draft IDMEFv2 October 2026 | | | cloud region outage, a | | | | power cut in a building, | | | | a widespread grid | | | | failure after a storm. | +------+-------------------------------+----------------------------+ | 37 | Availability.Overload | An incident where a | | | | system or component is | | | | subjected to a load | | | | beyond its designed | | | | capacity, leading to | | | | performance degradation | | | | or failure, even if the | | | | load is not malicious. | | | | Examples: CPU saturation | | | | on a server, | | | | overcapacity of a | | | | transport network. | +------+-------------------------------+----------------------------+ | 38 | Availability.Recovery | The return of a system, | | | | service, process, or | | | | component to normal | | | | operation following a | | | | failure, overload, | | | | outage, or other | | | | disruptive condition. | | | | Examples: a service back | | | | online after an | | | | incident, power restored | | | | after an outage, water | | | | supply restored after a | | | | flood. | +------+-------------------------------+----------------------------+ | 39 | Availability.Restart | The planned or unplanned | | | | reinitialisation of a | | | | system, service, | | | | process, or component, | | | | involving a stop | | | | followed by a start. | | | | Examples: a planned | | | | server reboot, a restart | | | | of a generator. | +------+-------------------------------+----------------------------+ | 40 | Availability.Start | The initialisation or | | | | startup of a system, | | | | service, process, or | | | | component, transitioning | | | | from an inactive to an | | | | active state. Examples: | Lehmann & Andrejak Expires 27 April 2027 [Page 87] Internet-Draft IDMEFv2 October 2026 | | | a service startup after | | | | deployment, the start of | | | | a pump. | +------+-------------------------------+----------------------------+ | 41 | Availability.Status | A point-in-time report | | | | describing the current | | | | state, health, or | | | | operational metrics of a | | | | system, service, or | | | | component, typically | | | | emitted on demand or at | | | | significant transitions. | | | | Examples: a health-check | | | | report from a node, a | | | | status board of a | | | | facility, the polling of | | | | a normal disk space. | +------+-------------------------------+----------------------------+ | 42 | Availability.Stop | The intentional or | | | | unintentional | | | | termination of a system, | | | | service, process, or | | | | component, transitioning | | | | from an active to an | | | | inactive state. | | | | Examples: a service | | | | shutdown, the stop of a | | | | production line. | +------+-------------------------------+----------------------------+ | 43 | Availability.Other | Any other incident that | | | | impacts the availability | | | | of resources or | | | | services, not covered by | | | | the specific | | | | subcategories. | | | | Examples: a DNS | | | | resolution failure, a | | | | lift out of service. | +------+-------------------------------+----------------------------+ | 44 | Biological.Animal | An incident where | | | | animals pose a direct | | | | threat to human safety, | | | | public health (e.g., | | | | zoonotic diseases), or | | | | economic stability | | | | (e.g., livestock | | | | diseases). Examples: an | | | | aggressive dog loose on | Lehmann & Andrejak Expires 27 April 2027 [Page 88] Internet-Draft IDMEFv2 October 2026 | | | a site, a zoonotic | | | | outbreak from livestock. | +------+-------------------------------+----------------------------+ | 45 | Biological.Epidemic | The rapid and widespread | | | | occurrence of an | | | | infectious disease in a | | | | specific population or | | | | region, exceeding what | | | | is normally expected. | | | | Examples: a regional flu | | | | epidemic, a measles | | | | outbreak in a community. | +------+-------------------------------+----------------------------+ | 46 | Biological.Insect | An incident involving a | | | | harmful outbreak or | | | | infestation of insects | | | | that threatens public | | | | health, agriculture, | | | | livestock, or property. | | | | Examples: a locust swarm | | | | threatening crops, an | | | | invasive mosquito | | | | infestation. | +------+-------------------------------+----------------------------+ | 47 | Biological.Zombies | A fictional or | | | | hypothetical scenario | | | | involving a pathogen | | | | that causes a pandemic | | | | of aggressive, | | | | infectious behavior, | | | | often used as a metaphor | | | | for worst-case outbreak | | | | scenarios in planning. | | | | Examples: a tabletop | | | | exercise simulating a | | | | zombie pandemic, a | | | | worst-case planning | | | | scenario for an | | | | uncontrolled outbreak. | +------+-------------------------------+----------------------------+ | 48 | Biological.Other | Any other incident | | | | caused by biological | | | | processes not covered by | | | | specific subcategories. | | | | Examples: a fungal | | | | contamination of a water | | | | source, an algal bloom | | | | affecting a reservoir. | Lehmann & Andrejak Expires 27 April 2027 [Page 89] Internet-Draft IDMEFv2 October 2026 +------+-------------------------------+----------------------------+ | 49 | Climate.Drought | A prolonged period of | | | | below-average | | | | precipitation leading to | | | | a water shortage, which | | | | can impact agriculture, | | | | ecosystems, and water | | | | supplies. Examples: a | | | | multi-year drought | | | | affecting a region, a | | | | dry spell causing crop | | | | failure. | +------+-------------------------------+----------------------------+ | 50 | Climate.LakeOutburst | An incident where a | | | | glacial lake dam (often | | | | moraine or ice) fails, | | | | rapidly releasing a | | | | large volume of water | | | | and causing devastating | | | | floods downstream. | | | | Examples: a glacial lake | | | | outburst flood in the | | | | Alps, a moraine dam | | | | breach in the Himalayas. | +------+-------------------------------+----------------------------+ | 51 | Climate.Wildfire | An unplanned and | | | | uncontrolled fire | | | | burning in natural or | | | | rural areas, often | | | | exacerbated by climatic | | | | conditions like drought, | | | | wind, and heat. | | | | Examples: a wildfire | | | | spreading under heat and | | | | wind, a forest fire | | | | threatening a | | | | settlement. | +------+-------------------------------+----------------------------+ | 52 | Climate.Other | Any other incident | | | | caused by long-lived | | | | atmospheric processes | | | | (climatological) not | | | | covered by specific | | | | subcategories. | | | | Examples: a prolonged | | | | heat dome, a large-scale | | | | shift in monsoon | | | | patterns. | Lehmann & Andrejak Expires 27 April 2027 [Page 90] Internet-Draft IDMEFv2 October 2026 +------+-------------------------------+----------------------------+ | 53 | Extraterrestrial.Aliens | A hypothetical incident | | | | involving the discovery | | | | of or interaction with | | | | extraterrestrial | | | | intelligent life, a | | | | theoretical scenario in | | | | scientific and security | | | | planning. Examples: a | | | | hypothetical first- | | | | contact scenario, a | | | | tabletop exercise on | | | | extraterrestrial | | | | contact. | +------+-------------------------------+----------------------------+ | 54 | Extraterrestrial.Impact | An incident involving a | | | | celestial object | | | | (asteroid, meteoroid, | | | | comet) colliding with | | | | Earth, potentially | | | | causing localized or | | | | global damage. | | | | Examples: a meteor | | | | airburst over a | | | | populated area, an | | | | asteroid impact warning. | +------+-------------------------------+----------------------------+ | 55 | Extraterrestrial.SpaceWeather | An event caused by solar | | | | or cosmic activity, such | | | | as solar flares or | | | | geomagnetic storms, that | | | | can disrupt Earth's | | | | technological | | | | infrastructure. | | | | Examples: a geomagnetic | | | | storm disrupting power | | | | grids, satellite link | | | | degradation during a | | | | solar flare. | +------+-------------------------------+----------------------------+ | 56 | Extraterrestrial.Other | Any other incident | | | | caused by | | | | extraterrestrial | | | | processes not covered by | | | | specific subcategories. | | | | Examples: a cosmic ray | | | | burst affecting | | | | electronics, an unusual | Lehmann & Andrejak Expires 27 April 2027 [Page 91] Internet-Draft IDMEFv2 October 2026 | | | solar particle event. | +------+-------------------------------+----------------------------+ | 57 | Fraud.Copyright | The act of reproducing, | | | | distributing, or | | | | installing software, | | | | media, or other | | | | materials in violation | | | | of their copyright, | | | | often for personal gain | | | | or distribution | | | | (piracy). Examples: | | | | illegal distribution of | | | | licensed software, the | | | | sale of pirated media. | +------+-------------------------------+----------------------------+ | 58 | Fraud.Corruption | A fraudulent scheme that | | | | is made possible by the | | | | abuse of power or | | | | position by a trusted | | | | individual (e.g., | | | | employee, official) who | | | | acts for personal gain. | | | | Examples: an admin | | | | granting rights for a | | | | bribe, an official | | | | approving a fraudulent | | | | permit. | +------+-------------------------------+----------------------------+ | 59 | Fraud.Espionage | The use of illegal or | | | | unethical means, such as | | | | hacking, bribery, or | | | | theft, to acquire a | | | | competitor's trade | | | | secrets, intellectual | | | | property, or other | | | | confidential business | | | | information. Examples: | | | | exfiltration of trade | | | | secrets, photographing a | | | | prototype. | +------+-------------------------------+----------------------------+ | 60 | Fraud.Masquerade | A type of attack where | | | | an attacker | | | | illegitimately assumes | | | | the identity of another | | | | user, process, or system | | | | to gain unauthorized | | | | access, privileges, or | Lehmann & Andrejak Expires 27 April 2027 [Page 92] Internet-Draft IDMEFv2 October 2026 | | | benefits. Examples: an | | | | attacker impersonating a | | | | service account, a | | | | person using someone | | | | else's badge. | +------+-------------------------------+----------------------------+ | 61 | Fraud.Usage | The use of an | | | | organization's assets | | | | (e.g., computing power, | | | | network, email) for non- | | | | work-related, often | | | | illegal, activities | | | | without authorization. | | | | Examples: mining crypto | | | | on corporate servers, | | | | personal use of a | | | | company vehicle. | +------+-------------------------------+----------------------------+ | 62 | Fraud.Other | Any other incident | | | | involving deception for | | | | financial or | | | | reputational gain that | | | | does not fit into the | | | | specific fraud | | | | subcategories. | | | | Examples: a fake refund | | | | scheme, a forged | | | | signature on a contract. | +------+-------------------------------+----------------------------+ | 63 | Geophysical.Earthquake | An incident caused by a | | | | sudden, rapid shaking of | | | | the earth resulting from | | | | the movement of tectonic | | | | plates, which can cause | | | | ground shaking, surface | | | | rupture, and tsunamis. | | | | Examples: a magnitude | | | | 6.0 earthquake, an | | | | aftershock swarm | | | | following a main shock. | +------+-------------------------------+----------------------------+ | 64 | Geophysical.MassMovement | An incident involving | | | | the downslope movement | | | | of rock, soil, or snow | | | | under the force of | | | | gravity, such as | | | | landslides, avalanches, | | | | or rockfalls. Examples: | Lehmann & Andrejak Expires 27 April 2027 [Page 93] Internet-Draft IDMEFv2 October 2026 | | | a landslide after | | | | saturation, an avalanche | | | | blocking a mountain | | | | road. | +------+-------------------------------+----------------------------+ | 65 | Geophysical.Other | Any other incident | | | | caused by solid-earth | | | | processes not covered by | | | | specific geophysical | | | | subcategories. | | | | Examples: a volcanic | | | | tremor, ground | | | | deformation detected by | | | | sensors. | +------+-------------------------------+----------------------------+ | 66 | Geophysical.Volcanic | An incident caused by | | | | the eruption of magma | | | | and volcanic gases from | | | | a volcano, which can | | | | produce lava flows, | | | | pyroclastic flows, | | | | ashfall, and lahars. | | | | Examples: ashfall from | | | | an eruption, a | | | | pyroclastic flow | | | | descending a slope. | +------+-------------------------------+----------------------------+ | 67 | Hydro.Flood | An incident where water | | | | submerges land that is | | | | normally dry, often | | | | caused by heavy rain, | | | | storm surge, or dam | | | | failure, leading to | | | | property damage and risk | | | | to life. Examples: a | | | | river flood after heavy | | | | rain, a flash flood in | | | | an urban area. | +------+-------------------------------+----------------------------+ | 68 | Hydro.Landslide | An incident involving | | | | the downward movement of | | | | slope materials (soil, | | | | rock) triggered by water | | | | saturation from heavy | | | | rain or snowmelt. | | | | Examples: a rain- | | | | triggered slope failure, | | | | a mudslide after | Lehmann & Andrejak Expires 27 April 2027 [Page 94] Internet-Draft IDMEFv2 October 2026 | | | snowmelt. | +------+-------------------------------+----------------------------+ | 69 | Hydro.Wave | An incident involving | | | | destructive waves, such | | | | as tsunamis or storm | | | | surges, that can cause | | | | coastal flooding, | | | | erosion, and damage. | | | | Examples: a tsunami | | | | hitting a coast, a storm | | | | surge flooding a | | | | seafront. | +------+-------------------------------+----------------------------+ | 70 | Hydro.Other | Any other incident | | | | caused by the movement, | | | | distribution, and | | | | quality of water, not | | | | covered by specific | | | | hydrological | | | | subcategories. | | | | Examples: a dam overflow | | | | warning, a sudden drop | | | | in river water quality. | +------+-------------------------------+----------------------------+ | 71 | Insider.Malicious | A security incident | | | | caused by a current or | | | | former employee, | | | | contractor, or other | | | | trusted insider who | | | | intentionally acts to | | | | harm the organization, | | | | its data, or its people. | | | | Examples: an employee | | | | exfiltrating data, an | | | | insider disabling a | | | | camera. | +------+-------------------------------+----------------------------+ | 72 | Insider.Negligent | A security incident | | | | caused unintentionally | | | | by an insider, such as | | | | through carelessness, | | | | lack of awareness, or | | | | simple human error, | | | | leading to data exposure | | | | or system compromise. | | | | Examples: a mis-sent | | | | email with PII, leaving | | | | a door unlocked. | Lehmann & Andrejak Expires 27 April 2027 [Page 95] Internet-Draft IDMEFv2 October 2026 +------+-------------------------------+----------------------------+ | 73 | Insider.Other | Any other security | | | | incident involving an | | | | insider (trusted | | | | individual) that does | | | | not fit into the | | | | specific insider threat | | | | subcategories. | | | | Examples: a contractor | | | | using shadow IT, a | | | | visitor wandering off | | | | from an escorted area. | +------+-------------------------------+----------------------------+ | 74 | Malware.Adware | A type of software that | | | | automatically displays | | | | or downloads unwanted | | | | advertisements, often in | | | | a disruptive manner, and | | | | may track user behavior. | | | | Examples: a browser | | | | hijacker showing ads, | | | | unwanted pop-ups | | | | appearing on a | | | | workstation. | +------+-------------------------------+----------------------------+ | 75 | Malware.Backdoor | A type of malware that | | | | bypasses normal | | | | authentication to give | | | | an attacker persistent | | | | remote access to a | | | | compromised system, | | | | often enabling data | | | | theft or installation of | | | | additional malware. | | | | Examples: a RAT | | | | installed on a | | | | workstation, a hidden | | | | remote shell on a | | | | server. | +------+-------------------------------+----------------------------+ | 76 | Malware.ResourceHijacking | A type of malware or | | | | malicious behavior that | | | | abuses the resources of | | | | a compromised system | | | | (CPU, GPU, network | | | | bandwidth, cloud | | | | services, etc.) for the | | | | attacker's benefit | Lehmann & Andrejak Expires 27 April 2027 [Page 96] Internet-Draft IDMEFv2 October 2026 | | | without the owner's | | | | consent. This includes, | | | | but is not limited to, | | | | cryptocurrency mining | | | | (cryptojacking), proxy | | | | bandwidth resale, SMS | | | | traffic generation, and | | | | email spam abuse. The | | | | main impact is degraded | | | | performance, reduced | | | | availability, and | | | | increased operational | | | | costs (electricity, | | | | cloud billing). | | | | Examples: XMRig running | | | | on a server, a browser- | | | | based miner slowing a | | | | workstation. | +------+-------------------------------+----------------------------+ | 77 | Malware.Downloader | A type of malware | | | | designed to download and | | | | install other malicious | | | | software from a remote | | | | server, typically acting | | | | as the first stage in a | | | | multi-step attack. | | | | Examples: a dropper | | | | fetching a payload, a | | | | script downloading a | | | | second-stage binary. | +------+-------------------------------+----------------------------+ | 78 | Malware.Ransomware | A type of malware that | | | | encrypts a victim's | | | | files or systems, | | | | rendering them | | | | inaccessible, and | | | | demands a ransom | | | | payment, often in | | | | cryptocurrency, for the | | | | decryption key. | | | | Examples: file- | | | | encrypting malware on a | | | | file server, a ransom | | | | note left on a | | | | workstation. | +------+-------------------------------+----------------------------+ | 79 | Malware.Rootkit | A type of malware | | | | designed to hide its | Lehmann & Andrejak Expires 27 April 2027 [Page 97] Internet-Draft IDMEFv2 October 2026 | | | presence and grant an | | | | attacker persistent, | | | | privileged access to a | | | | compromised system while | | | | evading detection. | | | | Examples: a kernel-level | | | | rootkit, a bootkit | | | | persisting across | | | | reboots. | +------+-------------------------------+----------------------------+ | 80 | Malware.Spyware | A type of software that | | | | secretly monitors and | | | | collects information | | | | about a user's | | | | activities, such as | | | | keystrokes, browsing | | | | habits, and personal | | | | data, without their | | | | consent. Examples: a | | | | keylogger on a laptop, a | | | | hidden camera implant. | +------+-------------------------------+----------------------------+ | 81 | Malware.Trojan | A type of malware that | | | | disguises itself as | | | | legitimate or desirable | | | | software to trick users | | | | into installing it, | | | | after which it can | | | | perform malicious | | | | actions. Examples: a | | | | fake installer, a | | | | trojanised game | | | | download. | +------+-------------------------------+----------------------------+ | 82 | Malware.Virus | A type of malicious | | | | software that attaches | | | | itself to a legitimate | | | | program or file and | | | | replicates itself to | | | | spread to other | | | | programs, often | | | | requiring human action | | | | to propagate. Examples: | | | | a macro virus in a | | | | document, an infected | | | | executable on a USB | | | | stick. | +------+-------------------------------+----------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 98] Internet-Draft IDMEFv2 October 2026 | 83 | Malware.Worm | A type of standalone | | | | malicious software that | | | | replicates itself to | | | | spread across networks, | | | | often exploiting | | | | vulnerabilities without | | | | requiring human | | | | interaction. Examples: | | | | a self-spreading worm on | | | | a network, a mass- | | | | mailing worm. | +------+-------------------------------+----------------------------+ | 84 | Malware.Other | Any other incident | | | | involving malicious | | | | software that does not | | | | fit into the specific | | | | malware subcategories. | | | | Examples: fileless | | | | malware, a malicious | | | | browser extension. | +------+-------------------------------+----------------------------+ | 85 | Meteo.Cold | A meteorological | | | | incident involving a | | | | rapid fall in | | | | temperature over a short | | | | period, or a prolonged | | | | period of extreme cold, | | | | posing risks to health | | | | and infrastructure. | | | | Examples: a cold wave, a | | | | sudden frost damaging | | | | crops. | +------+-------------------------------+----------------------------+ | 86 | Meteo.Fog | A meteorological | | | | incident where dense fog | | | | reduces visibility, | | | | potentially disrupting | | | | transportation and | | | | causing accidents. | | | | Examples: dense fog on a | | | | motorway, fog grounding | | | | flights at an airport. | +------+-------------------------------+----------------------------+ | 87 | Meteo.Heat | A meteorological | | | | incident involving a | | | | prolonged period of | | | | excessively hot weather, | | | | which can cause health | Lehmann & Andrejak Expires 27 April 2027 [Page 99] Internet-Draft IDMEFv2 October 2026 | | | impacts, infrastructure | | | | stress, and | | | | environmental damage. | | | | Examples: a heatwave, a | | | | prolonged period of high | | | | night-time temperatures. | +------+-------------------------------+----------------------------+ | 88 | Meteo.Rain | A meteorological | | | | incident involving | | | | excessive or prolonged | | | | rainfall that can lead | | | | to flooding, landslides, | | | | and transportation | | | | disruptions. Examples: | | | | prolonged rainfall over | | | | a catchment, intense | | | | rainfall causing urban | | | | flooding. | +------+-------------------------------+----------------------------+ | 89 | Meteo.Snow | A meteorological | | | | incident involving heavy | | | | snowfall and blizzard | | | | conditions, which can | | | | disrupt transportation, | | | | damage infrastructure, | | | | and pose risks to | | | | safety. Examples: a | | | | blizzard, heavy snow | | | | closing a mountain pass. | +------+-------------------------------+----------------------------+ | 90 | Meteo.Wind | A meteorological | | | | incident involving | | | | damaging or dangerous | | | | winds, such as from | | | | storms, tornadoes, or | | | | hurricanes, that can | | | | cause structural damage | | | | and power outages. | | | | Examples: storm-force | | | | winds, a tornado | | | | touching down. | +------+-------------------------------+----------------------------+ | 91 | Meteo.Other | Any other incident | | | | caused by atmospheric | | | | processes not covered by | | | | specific meteorological | | | | subcategories. | | | | Examples: a hail storm, | Lehmann & Andrejak Expires 27 April 2027 [Page 100] Internet-Draft IDMEFv2 October 2026 | | | a dust storm reducing | | | | visibility. | +------+-------------------------------+----------------------------+ | 92 | National.Conflict | A state of armed | | | | conflict between two or | | | | more nations, involving | | | | organized military | | | | forces and impacting | | | | national security. | | | | Examples: an armed | | | | border clash, a state- | | | | backed cyber campaign | | | | during a war. | +------+-------------------------------+----------------------------+ | 93 | National.Crime | Large-scale illegal | | | | activities, such as | | | | trafficking in drugs, | | | | weapons, or people, | | | | conducted by | | | | sophisticated criminal | | | | networks that pose a | | | | threat to national and | | | | international security. | | | | Examples: a ransomware | | | | cartel, drug trafficking | | | | across a border. | +------+-------------------------------+----------------------------+ | 94 | National.Cyber | Large-scale cyber | | | | operations, including | | | | attacks, espionage, and | | | | disinformation | | | | campaigns, conducted by | | | | state-sponsored or | | | | state-affiliated groups | | | | against national | | | | interests. Examples: a | | | | state-sponsored APT | | | | campaign, a coordinated | | | | disinformation | | | | operation. | +------+-------------------------------+----------------------------+ | 95 | National.Economic | An incident involving | | | | significant disruption | | | | to a nation's economy, | | | | such as market crashes, | | | | hyperinflation, or trade | | | | wars, affecting national | | | | stability. Examples: a | Lehmann & Andrejak Expires 27 April 2027 [Page 101] Internet-Draft IDMEFv2 October 2026 | | | market crash, a sudden | | | | currency devaluation. | +------+-------------------------------+----------------------------+ | 96 | National.Environmental | Incidents related to | | | | large-scale | | | | environmental shifts, | | | | such as climate change, | | | | resource scarcity, or | | | | global pandemics, that | | | | have significant | | | | national security | | | | implications. Examples: | | | | climate-driven | | | | migration, a resource | | | | scarcity crisis. | +------+-------------------------------+----------------------------+ | 97 | National.Societal | An incident involving | | | | large-scale public | | | | disorder, such as | | | | strikes, riots, or civil | | | | unrest, that challenges | | | | social order and may | | | | require national-level | | | | response. Examples: a | | | | general strike, | | | | widespread riots in a | | | | city. | +------+-------------------------------+----------------------------+ | 98 | National.Terrorism | An incident involving | | | | the use of violence, | | | | intimidation, or threats | | | | by non-state actors | | | | against civilians or | | | | property to achieve | | | | political, religious, or | | | | ideological objectives. | | | | Examples: a bombing in a | | | | public place, online | | | | radicalization leading | | | | to a plot. | +------+-------------------------------+----------------------------+ | 99 | National.Other | Any other incident that | | | | has a significant impact | | | | at the national scale, | | | | not covered by specific | | | | national security | | | | subcategories. | | | | Examples: a national | Lehmann & Andrejak Expires 27 April 2027 [Page 102] Internet-Draft IDMEFv2 October 2026 | | | emergency declaration, a | | | | large-scale border | | | | incident. | +------+-------------------------------+----------------------------+ | 100 | Operational.Configuration | A change, whether | | | | intentional or | | | | accidental, to the | | | | parameters, settings, or | | | | behavior of a system, | | | | service, or component. | | | | Examples: a firewall | | | | rule change, switching a | | | | valve in a pipeline. | +------+-------------------------------+----------------------------+ | 101 | Operational.Misuse | The use of an | | | | organization's assets | | | | (e.g., computers, | | | | network, time) for | | | | purposes that are not | | | | officially authorized, | | | | which may violate policy | | | | but not be malicious. | | | | Examples: personal use | | | | of a corporate account, | | | | personal use of a | | | | company vehicle. | +------+-------------------------------+----------------------------+ | 102 | Operational.PolicyViolation | An incident where an | | | | individual fails to | | | | comply with established | | | | organizational policies, | | | | procedures, or security | | | | rules, whether | | | | intentionally or | | | | accidentally. Examples: | | | | bypassing a security | | | | policy, ignoring a | | | | safety rule. | +------+-------------------------------+----------------------------+ | 103 | Operational.ProcessFailure | An incident where a | | | | designed process, | | | | procedure, or workflow | | | | fails to achieve its | | | | intended outcome, | | | | leading to operational | | | | or security gaps. | | | | Examples: a failed patch | | | | rollout, a broken | Lehmann & Andrejak Expires 27 April 2027 [Page 103] Internet-Draft IDMEFv2 October 2026 | | | maintenance procedure. | +------+-------------------------------+----------------------------+ | 104 | Operational.Update | The installation, | | | | upgrade, or refresh of | | | | software, firmware, | | | | signatures, definitions, | | | | or other content that | | | | modifies the functional | | | | behavior of a system, | | | | service, or component. | | | | Examples: a software | | | | upgrade, a firmware | | | | update on a device. | +------+-------------------------------+----------------------------+ | 105 | Operational.Other | Any other operational | | | | issue that does not fit | | | | into the specific | | | | operational incident | | | | subcategories. | | | | Examples: a license | | | | expiry, a spare part | | | | shortage. | +------+-------------------------------+----------------------------+ | 106 | Recon.Aerial | The act of using aerial | | | | platforms, such as | | | | drones or satellites, to | | | | conduct surveillance or | | | | gather intelligence | | | | about a target area. | | | | Examples: a drone | | | | overflight, satellite | | | | imagery collection over | | | | a site. | +------+-------------------------------+----------------------------+ | 107 | Recon.Landscape | The act of physically | | | | observing a location to | | | | gather information about | | | | security measures, | | | | layouts, or potential | | | | vulnerabilities. | | | | Examples: casing a | | | | building, observing a | | | | facility's entry points. | +------+-------------------------------+----------------------------+ | 108 | Recon.Network | The practice of probing | | | | a network to discover | | | | active hosts, open | | | | ports, and services, | Lehmann & Andrejak Expires 27 April 2027 [Page 104] Internet-Draft IDMEFv2 October 2026 | | | often as a precursor to | | | | an attack or | | | | unauthorized monitoring. | | | | Examples: a port scan, a | | | | host discovery sweep. | +------+-------------------------------+----------------------------+ | 109 | Recon.OSINT | The practice of | | | | collecting and analyzing | | | | information from | | | | publicly available | | | | sources (e.g., social | | | | media, public records) | | | | for intelligence | | | | purposes. Examples: | | | | scraping social media, | | | | gathering information | | | | from public records. | +------+-------------------------------+----------------------------+ | 110 | Recon.Other | Any other incident | | | | involving scanning, | | | | spying, or monitoring to | | | | identify resources that | | | | does not fit into | | | | specific recon | | | | subcategories. | | | | Examples: DNS | | | | enumeration, monitoring | | | | of a target's | | | | communications. | +------+-------------------------------+----------------------------+ | 111 | Sabotage.Data | The intentional act of | | | | deleting, altering, or | | | | corrupting digital or | | | | physical data to cause | | | | harm, disrupt | | | | operations, or cover | | | | tracks. Examples: a | | | | database wiped, shredded | | | | documents. | +------+-------------------------------+----------------------------+ | 112 | Sabotage.Destruction | The intentional and | | | | malicious act of | | | | destroying or severely | | | | damaging physical | | | | assets, such as windows, | | | | equipment, or buildings. | | | | Examples: smashed | | | | equipment, a | Lehmann & Andrejak Expires 27 April 2027 [Page 105] Internet-Draft IDMEFv2 October 2026 | | | deliberately damaged | | | | vehicle. | +------+-------------------------------+----------------------------+ | 113 | Sabotage.Disruption | The intentional | | | | disruption of essential | | | | services or utilities, | | | | such as electricity, | | | | water, or network | | | | connectivity, to cause | | | | operational downtime. | | | | Examples: a cut fibre | | | | link, a cut power line. | +------+-------------------------------+----------------------------+ | 114 | Sabotage.Equipment | The intentional act of | | | | causing damage to | | | | operational equipment, | | | | machinery, or vehicles, | | | | often to disrupt | | | | production or | | | | operations. Examples: a | | | | damaged machine on a | | | | production line, a | | | | sabotaged vehicle. | +------+-------------------------------+----------------------------+ | 115 | Sabotage.Graffiti | The act of willfully | | | | defacing, damaging, or | | | | marking public or | | | | private property with | | | | inscriptions, drawings, | | | | or tags without | | | | permission. Examples: | | | | tags on a wall, graffiti | | | | on a train. | +------+-------------------------------+----------------------------+ | 116 | Sabotage.Tampering | The act of deliberately | | | | meddling with or | | | | disabling security | | | | controls (e.g., locks, | | | | alarms, cameras) to | | | | compromise their | | | | effectiveness. | | | | Examples: a disabled EDR | | | | agent, a disabled | | | | camera. | +------+-------------------------------+----------------------------+ | 117 | Sabotage.Vandalism | The deliberate and | | | | malicious act of | | | | damaging, destroying, or | Lehmann & Andrejak Expires 27 April 2027 [Page 106] Internet-Draft IDMEFv2 October 2026 | | | obstructing an | | | | organization's physical | | | | assets, operations, or | | | | systems. Examples: | | | | broken windows, damaged | | | | signage. | +------+-------------------------------+----------------------------+ | 118 | Sabotage.Other | Any other incident | | | | involving the | | | | intentional damage to | | | | property or assets not | | | | covered by the specific | | | | sabotage subcategories. | | | | Examples: glue in a | | | | lock, a blocked | | | | ventilation shaft. | +------+-------------------------------+----------------------------+ | 119 | Safety.Accident | An unplanned, unforeseen | | | | event (e.g., vehicle | | | | crash, industrial | | | | mishap, chemical spill) | | | | that results in injury, | | | | loss of life, or damage | | | | to health. Examples: a | | | | vehicle crash, a fall | | | | from height. | +------+-------------------------------+----------------------------+ | 120 | Safety.Aggression | An incident where an | | | | individual uses physical | | | | force against another | | | | person, causing bodily | | | | harm, pain, or the fear | | | | of immediate harm. | | | | Examples: a physical | | | | assault, a violent | | | | altercation. | +------+-------------------------------+----------------------------+ | 121 | Safety.Explosion | A sudden, violent | | | | release of energy (e.g., | | | | from gas, chemicals, or | | | | explosives) that causes | | | | a blast, fire, and | | | | potential structural | | | | damage, injury, or loss | | | | of life. Examples: a | | | | gas explosion, a | | | | chemical blast. | +------+-------------------------------+----------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 107] Internet-Draft IDMEFv2 October 2026 | 122 | Safety.Fire | An incident involving | | | | uncontrolled burning | | | | (e.g., structural, | | | | wildland, or chemical | | | | fire) that threatens | | | | human safety, property, | | | | or the environment. | | | | Examples: a data-center | | | | fire, a building fire, a | | | | wildfire. | +------+-------------------------------+----------------------------+ | 123 | Safety.Hostage | An incident where a | | | | person or group is held | | | | against their will by a | | | | captor, often to compel | | | | a third party to meet | | | | certain demands. | | | | Examples: a hostage- | | | | taking in a building, a | | | | person held in a | | | | vehicle. | +------+-------------------------------+----------------------------+ | 124 | Safety.Pollution | The introduction or | | | | abnormal presence of a | | | | contaminant (chemical, | | | | biological, radioactive, | | | | or otherwise hazardous) | | | | in the environment — | | | | air, water, soil, or | | | | built infrastructure — | | | | that causes or may cause | | | | harm to human health, | | | | ecosystems, property, or | | | | the operation of | | | | facilities and services. | | | | The pollution may be | | | | acute or chronic, | | | | accidental or | | | | deliberate, and of local | | | | or transboundary extent. | | | | Examples: a radioactive | | | | release from a nuclear | | | | facility, a chemical | | | | discharge into a river, | | | | an atmospheric pollution | | | | peak, soil contamination | | | | from an industrial site, | | | | a deliberate dumping of | Lehmann & Andrejak Expires 27 April 2027 [Page 108] Internet-Draft IDMEFv2 October 2026 | | | hazardous waste. | +------+-------------------------------+----------------------------+ | 125 | Safety.Sexual | An incident involving | | | | any unwanted sexual act, | | | | contact, or behavior | | | | directed against an | | | | individual without their | | | | consent. Examples: a | | | | sexual assault, unwanted | | | | sexual contact. | +------+-------------------------------+----------------------------+ | 126 | Safety.Other | Any other incident that | | | | causes or has the | | | | potential to cause | | | | injury, loss of life, or | | | | endanger citizens, not | | | | covered by specific | | | | safety subcategories. | | | | Examples: a fall from | | | | height, a hazardous | | | | material spill. | +------+-------------------------------+----------------------------+ | 127 | SocialEng.Baiting | A social engineering | | | | attack that lures | | | | victims by offering | | | | something desirable | | | | (e.g., free music, a | | | | prize) in exchange for | | | | information or by | | | | tricking them into | | | | downloading malware. | | | | Examples: a USB drop in | | | | a car park, a left USB | | | | in a lobby. | +------+-------------------------------+----------------------------+ | 128 | SocialEng.Phishing | A social engineering | | | | attack where the | | | | attacker impersonates a | | | | trustworthy entity to | | | | trick a victim into | | | | revealing sensitive | | | | information or | | | | performing an action. | | | | Examples: a credential- | | | | harvesting email, a fake | | | | invoice sent by post, a | | | | fake login page. | +------+-------------------------------+----------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 109] Internet-Draft IDMEFv2 October 2026 | 129 | SocialEng.Pretexting | A social engineering | | | | tactic where the | | | | attacker creates a | | | | fabricated scenario or | | | | pretends to be someone | | | | they are not to engage a | | | | victim and extract | | | | information or access. | | | | Examples: a fake IT | | | | support call, a fake | | | | inspector visit. | +------+-------------------------------+----------------------------+ | 130 | SocialEng.QuidProQuo | A social engineering | | | | tactic where the | | | | attacker offers a | | | | service or benefit | | | | (e.g., technical | | | | support) in exchange for | | | | information or access, | | | | often expecting | | | | something in return | | | | later. Examples: a fake | | | | software update, a bogus | | | | tech support offer. | +------+-------------------------------+----------------------------+ | 131 | SocialEng.Other | Any other incident | | | | involving psychological | | | | manipulation of people | | | | to divulge information | | | | or perform actions, not | | | | covered by specific | | | | social engineering | | | | subcategories. | | | | Examples: a deepfake | | | | voice call, a fake job | | | | interview used to | | | | extract information. | +------+-------------------------------+----------------------------+ | 132 | SupplyChain.Compromise | A security incident | | | | where an attacker | | | | exploits a vulnerability | | | | in a third-party | | | | vendor's system to gain | | | | access to or compromise | | | | the primary target's | | | | network or data. | | | | Examples: a compromised | | | | software update, a | Lehmann & Andrejak Expires 27 April 2027 [Page 110] Internet-Draft IDMEFv2 October 2026 | | | tampered shipment. | +------+-------------------------------+----------------------------+ | 133 | SupplyChain.Disruption | An event that disrupts | | | | the normal flow of | | | | products, services, or | | | | information within a | | | | supply chain, often | | | | impacting operations and | | | | delivery. Examples: a | | | | cloud provider outage, a | | | | blocked port. | +------+-------------------------------+----------------------------+ | 134 | SupplyChain.Other | Any other incident | | | | affecting the supply | | | | chain that does not fit | | | | into the specific supply | | | | chain subcategories. | | | | Examples: an expired | | | | certificate from a | | | | vendor, delayed spare | | | | parts. | +------+-------------------------------+----------------------------+ | 135 | Theft.Data | The unauthorized taking | | | | or copying of sensitive | | | | or confidential | | | | documents, whether in | | | | physical or digital | | | | form. Examples: copied | | | | files from a shared | | | | drive, stolen paper | | | | records. | +------+-------------------------------+----------------------------+ | 136 | Theft.Equipment | The unlawful taking of | | | | physical hardware, such | | | | as computers, mobile | | | | phones, or servers, | | | | resulting in loss of | | | | assets and potentially | | | | the data they contain. | | | | Examples: a stolen | | | | server, a stolen laptop. | +------+-------------------------------+----------------------------+ | 137 | Theft.FinInfo | The theft of financial | | | | information, such as | | | | credit card numbers or | | | | bank account details, | | | | often for the purpose of | | | | fraudulent transactions. | Lehmann & Andrejak Expires 27 April 2027 [Page 111] Internet-Draft IDMEFv2 October 2026 | | | Examples: card skimming | | | | data, a stolen wallet. | +------+-------------------------------+----------------------------+ | 138 | Theft.IP | The unlawful acquisition | | | | of a company's | | | | intellectual property, | | | | including trade secrets, | | | | patents, formulas, or | | | | proprietary processes. | | | | Examples: stolen source | | | | code, a stolen | | | | blueprint. | +------+-------------------------------+----------------------------+ | 139 | Theft.Machinery | The unlawful taking of | | | | heavy equipment, | | | | vehicles, or specialized | | | | machinery, often | | | | resulting in significant | | | | operational and | | | | financial loss. | | | | Examples: a stolen | | | | excavator, a stolen | | | | delivery truck. | +------+-------------------------------+----------------------------+ | 140 | Theft.PII | The unauthorized | | | | acquisition of | | | | Personally Identifiable | | | | Information (PII) that | | | | can be used to identify, | | | | contact, or impersonate | | | | an individual. | | | | Examples: a leaked | | | | customer database, | | | | stolen HR files. | +------+-------------------------------+----------------------------+ | 141 | Theft.Other | Any other incident | | | | involving the | | | | intentional stealing of | | | | physical property or | | | | digital data not covered | | | | by specific theft | | | | subcategories. | | | | Examples: a stolen | | | | license key, stolen | | | | tools. | +------+-------------------------------+----------------------------+ | 142 | Other.Uncategorized | Any incident that does | | | | not fit into one of the | Lehmann & Andrejak Expires 27 April 2027 [Page 112] Internet-Draft IDMEFv2 October 2026 | | | predefined categories in | | | | this taxonomy. | | | | Examples: an | | | | unclassifiable alert, an | | | | incident whose type does | | | | not match any existing | | | | category. | +------+-------------------------------+----------------------------+ | 143 | Other.Undetermined | An incident whose | | | | category is currently | | | | unknown, under | | | | investigation, or cannot | | | | be determined. | | | | Examples: an alert under | | | | investigation, a signal | | | | whose cause remains | | | | unidentified. | +------+-------------------------------+----------------------------+ | 144 | Other.Test | An incident generated | | | | solely for the purpose | | | | of testing systems, | | | | processes, or training | | | | personnel. Examples: a | | | | synthetic test alert, a | | | | fire drill. | +------+-------------------------------+----------------------------+ | 145 | Other.ext-value | A value used to indicate | | | | that this attribute is | | | | extended and the actual | | | | value is provided using | | | | the corresponding ext-* | | | | attribute. (see | | | | Section 4.1.1) Examples: | | | | an extension placeholder | | | | used when no standard | | | | category applies. | +------+-------------------------------+----------------------------+ Table 10: enum_alert_category C.3. Analyzer Category +======+===================+======================================+ | uank | Keyword | Description | +======+===================+======================================+ | 0 | Undetermined | The analyzer category has not been | | | | determined, or cannot be established | | | | from available information. Ex: an | Lehmann & Andrejak Expires 27 April 2027 [Page 113] Internet-Draft IDMEFv2 October 2026 | | | analyzer whose type is unknown at | | | | ingestion time. | +------+-------------------+--------------------------------------+ | 1 | APP.BAST | Bastion Host — A hardened, | | | | intermediary server that provides | | | | secure remote access to a protected | | | | network, acting as a single | | | | controlled entry point. Ex: an SSH | | | | jump host, a RDP gateway. | +------+-------------------+--------------------------------------+ | 2 | APP.DAST | Dynamic Application Security Testing | | | | — Testing a running application from | | | | the outside to find security | | | | weaknesses in its runtime behaviour, | | | | without access to source code. Ex: | | | | a scanner probing a live web app for | | | | injection flaws. | +------+-------------------+--------------------------------------+ | 3 | APP.IAST | Interactive Application Security | | | | Testing — Hybrid testing that | | | | instruments a running application | | | | from within (agent-based) while it | | | | is exercised, combining runtime and | | | | code-level visibility. Ex: an agent | | | | inside a Java app reporting tainted | | | | data flows. | +------+-------------------+--------------------------------------+ | 4 | APP.RASP | Runtime Application Self-Protection | | | | — Security embedded inside a running | | | | application that detects and blocks | | | | attacks in real time from within the | | | | runtime, independently of the | | | | surrounding infrastructure. Ex: an | | | | in-app module blocking a SQL | | | | injection attempt. | +------+-------------------+--------------------------------------+ | 5 | APP.SANDBOX | Sandbox / File Detonation — Isolated | | | | execution environment that analyses | | | | the behaviour of suspicious files or | | | | URLs and decides whether to raise an | | | | alert. Ex: a suspicious attachment | | | | detonated in a VM to observe its | | | | behaviour. | +------+-------------------+--------------------------------------+ | 6 | APP.SAST | Static Application Security Testing | | | | — Analysis of application source | | | | code or binaries without executing | | | | them, to find vulnerabilities early | Lehmann & Andrejak Expires 27 April 2027 [Page 114] Internet-Draft IDMEFv2 October 2026 | | | in development. Ex: a linter | | | | flagging unsanitised input in | | | | source. | +------+-------------------+--------------------------------------+ | 7 | APP.SCA | Software Composition Analysis — | | | | Analysis of third-party dependencies | | | | and libraries for known | | | | vulnerabilities, licence issues, and | | | | supply-chain risk. Ex: detecting a | | | | vulnerable open-source component in | | | | a build. | +------+-------------------+--------------------------------------+ | 8 | CLD.CASB | Cloud Access Security Broker — A | | | | control point between users and | | | | cloud services that enforces | | | | security policy, visibility, and | | | | compliance for cloud usage. Ex: | | | | blocking unsanctioned SaaS uploads. | +------+-------------------+--------------------------------------+ | 9 | CLD.CIEM | Cloud Infrastructure Entitlement | | | | Management — Management and least- | | | | privilege enforcement of identities, | | | | roles, and permissions across cloud | | | | environments. Ex: detecting over- | | | | permissive IAM roles. | +------+-------------------+--------------------------------------+ | 10 | CLD.CSPM | Cloud Security Posture Management — | | | | Continuous monitoring of cloud | | | | configurations for | | | | misconfigurations, drift, and | | | | compliance violations. Ex: flagging | | | | a publicly exposed storage bucket. | +------+-------------------+--------------------------------------+ | 11 | CLD.CWPP | Cloud Workload Protection Platform — | | | | Security for cloud workloads (VMs, | | | | containers, serverless) covering | | | | runtime, vulnerability, and threat | | | | detection. Ex: detecting a | | | | cryptominer in a container. | +------+-------------------+--------------------------------------+ | 12 | DDoS.ANTI-DDOS | Distributed Denial of Service | | | | Protection — Systems and techniques | | | | that detect and mitigate volumetric | | | | or application-layer DDoS attacks. | | | | Ex: rate-limiting and scrubbing | | | | malicious floods. | +------+-------------------+--------------------------------------+ | 13 | DDoS.SCRUB | Scrubber / Scrubbing Center — A | Lehmann & Andrejak Expires 27 April 2027 [Page 115] Internet-Draft IDMEFv2 October 2026 | | | dedicated traffic-cleaning facility | | | | that diverts and filters attack | | | | traffic before forwarding clean | | | | traffic to the target. Ex: a | | | | carrier scrubbing centre absorbing a | | | | 1 Tbps flood. | +------+-------------------+--------------------------------------+ | 14 | DDoS.WAF-DDOS | Web Application Firewall with DDoS | | | | Protection — A WAF that also | | | | provides DDoS mitigation for HTTP/ | | | | HTTPS traffic. Ex: blocking a Layer | | | | 7 HTTP flood against a web service. | +------+-------------------+--------------------------------------+ | 15 | EMAIL.ANTI-PHISH | Anti-Phishing — Detection and | | | | blocking of phishing attempts in | | | | email, including malicious links, | | | | spoofed senders, and deceptive | | | | content. Ex: quarantining a | | | | credential-harvesting email. | +------+-------------------+--------------------------------------+ | 16 | EMAIL.DMARC | Domain-based Message Authentication, | | | | Reporting and Conformance — Email | | | | authentication (SPF/DKIM/DMARC) | | | | monitoring and enforcement to | | | | prevent sender spoofing. Ex: | | | | rejecting mail failing DMARC | | | | alignment. | +------+-------------------+--------------------------------------+ | 17 | EMAIL.SEG | Secure Email Gateway — A | | | | comprehensive email security | | | | appliance/service filtering inbound | | | | and outbound mail for spam, malware, | | | | phishing, and policy violations. | | | | Ex: a gateway scanning attachments | | | | before delivery. | +------+-------------------+--------------------------------------+ | 18 | EMAIL.SPAM-FILTER | Spam Filter — Detection and | | | | filtering of unsolicited bulk email | | | | based on content, reputation, and | | | | heuristics. Ex: moving a bulk | | | | advertisement to the junk folder. | +------+-------------------+--------------------------------------+ | 19 | END.AM | Application Allowlisting — Execution | | | | control that permits only explicitly | | | | approved applications to run, | | | | blocking all others by default. Ex: | | | | a workstation that only runs signed | | | | corporate apps. | Lehmann & Andrejak Expires 27 April 2027 [Page 116] Internet-Draft IDMEFv2 October 2026 +------+-------------------+--------------------------------------+ | 20 | END.AV | Antivirus — Signature- and | | | | heuristic-based detection and | | | | removal of known malware on | | | | endpoints. Ex: quarantining a file | | | | matching a known virus signature. | +------+-------------------+--------------------------------------+ | 21 | END.DLP-EP | Endpoint Data Loss Prevention — | | | | Prevention of sensitive data leakage | | | | from endpoint devices via channels | | | | such as USB, clipboard, print, or | | | | email. Ex: blocking a copy of | | | | customer data to a USB stick. | +------+-------------------+--------------------------------------+ | 22 | END.EDR | Endpoint Detection and Response — | | | | Continuous endpoint monitoring, | | | | behavioural detection, and response | | | | capabilities for advanced threats. | | | | Ex: isolating a host showing | | | | lateral-movement behaviour. | +------+-------------------+--------------------------------------+ | 23 | END.EPP | Endpoint Protection Platform — A | | | | consolidated endpoint security suite | | | | combining antivirus, firewall, EDR, | | | | and other protections in a single | | | | agent. Ex: a single agent providing | | | | AV, host firewall, and threat | | | | hunting. | +------+-------------------+--------------------------------------+ | 24 | END.HIDS | Host Intrusion Detection System — | | | | Detection of malicious or anomalous | | | | activity on a host by monitoring | | | | system calls, files, and logs. Ex: | | | | alerting on a suspicious process | | | | spawning from a web server. | +------+-------------------+--------------------------------------+ | 25 | END.HIPS | Host Intrusion Prevention System — | | | | Active prevention of host-level | | | | intrusions by blocking malicious | | | | system activity in real time. Ex: | | | | blocking an unauthorised process | | | | from modifying system files. | +------+-------------------+--------------------------------------+ | 26 | END.HPT | Honeypot — A decoy system or service | | | | designed to attract and detect | | | | attackers, providing early warning | | | | and intelligence. Ex: a fake SSH | | | | server logging brute-force attempts. | Lehmann & Andrejak Expires 27 April 2027 [Page 117] Internet-Draft IDMEFv2 October 2026 +------+-------------------+--------------------------------------+ | 27 | HUM.REPORT | Human Report — A human observer who | | | | analyses a situation and decides to | | | | raise an alert, acting as the | | | | analyzer in the IDMEFv2 sense. Ex: | | | | a guard reporting a suspicious crowd | | | | approaching a building, an operator | | | | qualifying an incident in a control | | | | room, a patrol officer signalling an | | | | anomaly. | +------+-------------------+--------------------------------------+ | 28 | ID.DCAP | Data-Centric Audit and Protection — | | | | Monitoring and auditing of data | | | | access and usage, focused on the | | | | data itself rather than the | | | | infrastructure. Ex: alerting on | | | | unusual access to a sensitive | | | | database. | +------+-------------------+--------------------------------------+ | 29 | ID.DLP | Data Loss Prevention — Detection and | | | | prevention of sensitive data | | | | exfiltration across all channels | | | | (network, endpoint, cloud). Ex: | | | | blocking an outbound email | | | | containing PII. | +------+-------------------+--------------------------------------+ | 30 | ID.IAM | Identity and Access Management — | | | | Governance of identities and | | | | enforcement of access control across | | | | systems and applications. Ex: | | | | provisioning, authenticating, and | | | | authorising user accounts. | +------+-------------------+--------------------------------------+ | 31 | ID.IRM | Identity Risk Management — | | | | Assessment and scoring of identity- | | | | related risk, such as dormant | | | | accounts, excessive privileges, or | | | | compromised credentials. Ex: | | | | flagging a service account with no | | | | owner. | +------+-------------------+--------------------------------------+ | 32 | ID.MFA | Multi-Factor Authentication Analyzer | | | | — Analysis of multi-factor | | | | authentication events to detect | | | | bypass attempts, repeated failures, | | | | or anomalous challenges. Ex: | | | | alerting on repeated MFA push | | | | notifications ignored by a user. | Lehmann & Andrejak Expires 27 April 2027 [Page 118] Internet-Draft IDMEFv2 October 2026 +------+-------------------+--------------------------------------+ | 33 | ID.PAM | Privileged Access Management — | | | | Control, vaulting, and monitoring of | | | | privileged accounts and sessions. | | | | Ex: a vault checking out an admin | | | | password for a session. | +------+-------------------+--------------------------------------+ | 34 | ID.PIM | Privileged Identity Management — | | | | Just-in-time and lifecycle | | | | management of privileged identities | | | | and roles. Ex: granting temporary | | | | admin rights for a maintenance | | | | window. | +------+-------------------+--------------------------------------+ | 35 | ID.SECRETS | Secrets Detection — Analysis of code | | | | repositories, configurations, and | | | | logs to detect exposed secrets such | | | | as API keys, tokens, or | | | | certificates. Ex: detecting an API | | | | key committed to a public | | | | repository. | +------+-------------------+--------------------------------------+ | 36 | ID.UEBA | User and Entity Behaviour Analytics | | | | — Behavioural analytics over users | | | | and entities to detect anomalies and | | | | insider threats. Ex: alerting on a | | | | user downloading an unusual volume | | | | of files. | +------+-------------------+--------------------------------------+ | 37 | NAT.AIR | Air Quality Sensor — Analysis of | | | | airborne particles and gases to | | | | detect pollution, smoke, or | | | | hazardous releases. Ex: detecting a | | | | pollution peak or a smoke plume from | | | | a fire. | +------+-------------------+--------------------------------------+ | 38 | NAT.FIRE | Wildfire Detection — Detection of | | | | uncontrolled fires in natural or | | | | rural areas, typically via thermal | | | | or infrared sensing. Ex: a thermal | | | | sensor detecting a wildfire starting | | | | in a forest. | +------+-------------------+--------------------------------------+ | 39 | NAT.HYDRO | Hydrological Sensor — Analysis of | | | | water levels, flow, and quality to | | | | detect floods, droughts, or | | | | contamination. Ex: a river gauge | | | | alerting on a rising water level. | Lehmann & Andrejak Expires 27 April 2027 [Page 119] Internet-Draft IDMEFv2 October 2026 +------+-------------------+--------------------------------------+ | 40 | NAT.METEO | Meteorological Sensor — Analysis of | | | | atmospheric conditions (temperature, | | | | wind, precipitation, pressure) to | | | | detect weather events. Ex: a | | | | weather station alerting on a | | | | heatwave or storm. | +------+-------------------+--------------------------------------+ | 41 | NAT.RADIO | Radiation Sensor — Analysis of | | | | ionizing radiation levels to detect | | | | nuclear incidents or radioactive | | | | releases. Ex: a radiation monitor | | | | alerting on abnormal levels near a | | | | facility. | +------+-------------------+--------------------------------------+ | 42 | NAT.SAT | Earth Observation Satellite — | | | | Analysis of satellite imagery to | | | | detect large-scale natural events, | | | | environmental changes, or disasters. | | | | Ex: satellite imagery detecting a | | | | cyclone, a wildfire, or a flood. | +------+-------------------+--------------------------------------+ | 43 | NAT.SEISMO | Seismic Sensor — Analysis of ground | | | | motion to detect earthquakes, | | | | volcanic activity, or subsurface | | | | events. Ex: a seismograph alerting | | | | on a magnitude 6.0 earthquake. | +------+-------------------+--------------------------------------+ | 44 | NET.DNS-FW | DNS Firewall — Filtering of DNS | | | | queries to block resolution of | | | | malicious or unwanted domains. Ex: | | | | blocking resolution of a known C2 | | | | domain. | +------+-------------------+--------------------------------------+ | 45 | NET.DPI | Deep Packet Inspection — Inspection | | | | of packet payloads beyond headers to | | | | identify protocols, applications, or | | | | malicious content. Ex: detecting | | | | malware signatures inside HTTPS | | | | traffic. | +------+-------------------+--------------------------------------+ | 46 | NET.FW | Firewall — Filtering and policy | | | | enforcement of network traffic based | | | | on addresses, ports, and protocols. | | | | Ex: blocking inbound traffic to a | | | | database port from the internet. | +------+-------------------+--------------------------------------+ | 47 | NET.NAC | Network Access Control — Enforcement | Lehmann & Andrejak Expires 27 April 2027 [Page 120] Internet-Draft IDMEFv2 October 2026 | | | of endpoint compliance and identity | | | | before granting network access. Ex: | | | | quarantining a non-patched laptop | | | | until it is remediated. | +------+-------------------+--------------------------------------+ | 48 | NET.NBAD | Network Behaviour Anomaly Detection | | | | — Detection of deviations from | | | | normal network behaviour patterns, | | | | typically via baselining and | | | | statistics. Ex: alerting on an | | | | unusual spike in DNS queries from | | | | one host. | +------+-------------------+--------------------------------------+ | 49 | NET.NDR | Network Detection and Response — | | | | Continuous network monitoring, | | | | behavioural detection, and response | | | | for advanced threats. Ex: | | | | correlating east-west traffic to | | | | identify lateral movement. | +------+-------------------+--------------------------------------+ | 50 | NET.NGFW | Next-Generation Firewall — A | | | | firewall with application awareness, | | | | user identity, and integrated threat | | | | prevention (IPS, AV, URL filtering). | | | | Ex: allowing only sanctioned apps | | | | regardless of port. | +------+-------------------+--------------------------------------+ | 51 | NET.NIDS | Network Intrusion Detection System — | | | | Passive monitoring of network | | | | traffic to detect known attack | | | | patterns and anomalies. Ex: | | | | alerting on a signature matching an | | | | exploit attempt. | +------+-------------------+--------------------------------------+ | 52 | NET.NIPS | Network Intrusion Prevention System | | | | — Inline inspection of network | | | | traffic that can actively block | | | | detected attacks. Ex: dropping | | | | packets matching an exploit | | | | signature. | +------+-------------------+--------------------------------------+ | 53 | NET.PROXY | Proxy Server — An intermediary for | | | | client requests that enforces ACLs | | | | and can inspect TLS sessions. Ex: a | | | | forward proxy logging and filtering | | | | outbound web traffic. | +------+-------------------+--------------------------------------+ | 54 | NET.WAF | Web Application Firewall — Filtering | Lehmann & Andrejak Expires 27 April 2027 [Page 121] Internet-Draft IDMEFv2 October 2026 | | | of HTTP/HTTPS traffic to protect web | | | | applications from common attacks | | | | (OWASP Top 10, etc.). Ex: blocking | | | | a SQL injection attempt against a | | | | web app. | +------+-------------------+--------------------------------------+ | 55 | NET.WIDS | Wireless Intrusion Detection System | | | | — Passive monitoring of wireless | | | | networks to detect rogue APs, evil | | | | twins, and wireless attacks. Ex: | | | | alerting on an unauthorised AP in | | | | the building. | +------+-------------------+--------------------------------------+ | 56 | NET.WIPS | Wireless Intrusion Prevention System | | | | — Active prevention of wireless | | | | threats, including containment of | | | | rogue devices. Ex: deauthenticating | | | | clients from a rogue AP. | +------+-------------------+--------------------------------------+ | 57 | OT.IOT-IDS | IoT Intrusion Detection System — | | | | Detection of threats targeting IoT | | | | devices, whose constraints (power, | | | | compute, protocols) differ from | | | | general IT. Ex: alerting on | | | | anomalous MQTT traffic from a | | | | sensor. | +------+-------------------+--------------------------------------+ | 58 | OT.OT-IDS | Operational Technology IDS — | | | | Detection of threats in industrial | | | | control systems (SCADA, DCS), where | | | | availability and safety dominate. | | | | Ex: alerting on unauthorised Modbus | | | | writes to a PLC. | +------+-------------------+--------------------------------------+ | 59 | OT.PLC-SCAN | PLC Scanner — Discovery and | | | | vulnerability assessment of PLC/ | | | | SCADA devices in operational | | | | environments. Ex: enumerating PLCs | | | | on a plant network and checking | | | | firmware versions. | +------+-------------------+--------------------------------------+ | 60 | OT.SCADA | SCADA Monitor — Analysis of | | | | supervisory control and data | | | | acquisition systems to detect | | | | abnormal process states or | | | | operational anomalies. Ex: alerting | | | | on an abnormal pressure reading in | | | | an industrial process. | Lehmann & Andrejak Expires 27 April 2027 [Page 122] Internet-Draft IDMEFv2 October 2026 +------+-------------------+--------------------------------------+ | 61 | OT.SENSOR | Industrial Sensor — Analysis of | | | | industrial measurements (pressure, | | | | temperature, flow) to detect | | | | abnormal process conditions. Ex: a | | | | flow sensor alerting on a sudden | | | | drop in a pipeline. | +------+-------------------+--------------------------------------+ | 62 | PHY.1D-LAS | Laser Sensor 1D — Measures distance | | | | or presence along a single axis | | | | using a laser beam. Ex: a laser | | | | rangefinder, a beam-break tripwire. | +------+-------------------+--------------------------------------+ | 63 | PHY.2D-LAS | Laser Sensor 2D — Scans a plane with | | | | a laser to detect presence, | | | | contours, or movement in two | | | | dimensions. Ex: a planar laser | | | | scanner guarding an entrance. | +------+-------------------+--------------------------------------+ | 64 | PHY.3D-LAS | Laser Sensor 3D — Scans a volume | | | | with a laser to produce a three- | | | | dimensional representation of a | | | | scene. Ex: a 3D scanner producing a | | | | point cloud of a room. | +------+-------------------+--------------------------------------+ | 65 | PHY.ACCESS-CTRL | Access Control System — Physical | | | | entry/exit control using credentials | | | | (badge, PIN, biometric) and | | | | monitoring of door state. Ex: a | | | | badge reader logging who enters a | | | | server room. | +------+-------------------+--------------------------------------+ | 66 | PHY.ADS | Anti-Drone System — Detection (and | | | | sometimes neutralisation) of | | | | unauthorised drones via RF, radar, | | | | or acoustic sensing. Ex: detecting | | | | a drone approaching a restricted | | | | site. | +------+-------------------+--------------------------------------+ | 67 | PHY.CBRN | CBRN Detector — Detection of | | | | chemical, biological, radiological, | | | | or nuclear agents in the | | | | environment. Ex: a detector | | | | alerting on a chemical agent | | | | release. | +------+-------------------+--------------------------------------+ | 68 | PHY.FIRE | Fire Detector — Detection of heat, | | | | flame, or combustion products | Lehmann & Andrejak Expires 27 April 2027 [Page 123] Internet-Draft IDMEFv2 October 2026 | | | indicating a fire. Ex: a flame | | | | detector triggering an alarm in a | | | | warehouse. | +------+-------------------+--------------------------------------+ | 69 | PHY.FR-CAM | Face Recognition Camera — A camera | | | | coupled with biometric software that | | | | identifies or verifies individuals | | | | from facial features. Ex: matching | | | | a person against an authorised list | | | | at a gate. | +------+-------------------+--------------------------------------+ | 70 | PHY.GAS | Gas Detector — Detection of | | | | hazardous or combustible gases in | | | | the environment. Ex: a methane | | | | detector alerting in a confined | | | | space. | +------+-------------------+--------------------------------------+ | 71 | PHY.GLASS-BRK | Glass Break Detector — An acoustic | | | | sensor detecting the specific sound | | | | signature of breaking glass. Ex: | | | | triggering an alarm when a window is | | | | smashed. | +------+-------------------+--------------------------------------+ | 72 | PHY.HAR | Human Activity Recognition — AI- | | | | based analysis of video or sensor | | | | data to recognise human activities | | | | and behaviours. Ex: detecting a | | | | person falling, running, or | | | | loitering. | +------+-------------------+--------------------------------------+ | 73 | PHY.LWIR | Long-Wave Infrared — Thermal imaging | | | | in the long-wave IR band (roughly | | | | 8–14 µm), suited to ambient- | | | | temperature detection. Ex: a | | | | thermal camera detecting body heat | | | | at night. | +------+-------------------+--------------------------------------+ | 74 | PHY.MOT-SEN | Motion Sensor — A sensor (PIR, | | | | microwave, ultrasonic) detecting | | | | movement in its field of view. Ex: | | | | a PIR sensor turning on a light and | | | | logging presence. | +------+-------------------+--------------------------------------+ | 75 | PHY.MWIR | Mid-Wave Infrared — Thermal imaging | | | | in the mid-wave IR band (roughly 3–5 | | | | µm), used for higher-temperature | | | | targets and some gas detection. Ex: | | | | a MWIR camera monitoring an | Lehmann & Andrejak Expires 27 April 2027 [Page 124] Internet-Draft IDMEFv2 October 2026 | | | industrial furnace. | +------+-------------------+--------------------------------------+ | 76 | PHY.OBJ-DET | Object Detection Camera — A camera | | | | with AI models that detect and | | | | classify objects in the scene. Ex: | | | | detecting a left bag or a vehicle in | | | | a restricted zone. | +------+-------------------+--------------------------------------+ | 77 | PHY.PERIMETER | Perimeter Detection — Detection of | | | | intrusion across a perimeter using | | | | barriers, fibre optics, or microwave | | | | sensing. Ex: a fence-mounted fibre | | | | sensor alerting on an attempted | | | | climb. | +------+-------------------+--------------------------------------+ | 78 | PHY.RADAR | Radar Sensor — Detection of | | | | movement, presence, or objects using | | | | radio waves. Ex: a ground radar | | | | detecting an intrusion across a | | | | perimeter. | +------+-------------------+--------------------------------------+ | 79 | PHY.SMOKE | Smoke Detector — Detection of smoke | | | | particles indicating a fire. Ex: a | | | | smoke detector triggering an alarm | | | | in a server room. | +------+-------------------+--------------------------------------+ | 80 | PHY.SWIR | Short-Wave Infrared — Imaging in the | | | | short-wave IR band (roughly 0.9–1.7 | | | | µm), useful for seeing through haze | | | | and some materials. Ex: a SWIR | | | | camera inspecting contents through a | | | | container. | +------+-------------------+--------------------------------------+ | 81 | PHY.VAD | Voice Activity Detection — Audio | | | | analysis that detects the presence | | | | of human speech in a signal. Ex: | | | | triggering recording only when | | | | speech is present. | +------+-------------------+--------------------------------------+ | 82 | PHY.VNIR | Visible and Near-Infrared — Multi- | | | | spectral imaging covering the | | | | visible and near-IR bands. Ex: a | | | | VNIR camera used in low-light | | | | surveillance. | +------+-------------------+--------------------------------------+ | 83 | PHY.WATER | Water Leak Detector — Detection of | | | | water presence or leakage in a | | | | monitored area. Ex: a leak sensor | Lehmann & Andrejak Expires 27 April 2027 [Page 125] Internet-Draft IDMEFv2 October 2026 | | | alerting in a data centre. | +------+-------------------+--------------------------------------+ | 84 | SIEM.APM | Application Performance Monitoring — | | | | Analysis of application performance | | | | and availability to detect | | | | degradations, errors, or outages. | | | | Ex: alerting on a spike in response | | | | time for a critical service. | +------+-------------------+--------------------------------------+ | 85 | SIEM.ETL | Extract, Transform, Load — Data | | | | pipeline tooling that collects, | | | | normalises, and routes data to | | | | downstream stores. Ex: Logstash, | | | | Fluentd, Vector. | +------+-------------------+--------------------------------------+ | 86 | SIEM.LOG | Log Analyzer — Aggregation, | | | | indexing, and search of log data for | | | | troubleshooting and security | | | | analysis. Ex: an ELK stack or | | | | Splunk index. | +------+-------------------+--------------------------------------+ | 87 | SIEM.NMS | Network Management System — | | | | Monitoring and management of network | | | | devices, links, and performance. | | | | Ex: a NMS alerting on a down | | | | interface. | +------+-------------------+--------------------------------------+ | 88 | SIEM.SIEM | Security Information and Event | | | | Management — Centralised collection, | | | | correlation, and alerting across | | | | security-relevant data sources. Ex: | | | | correlating firewall and endpoint | | | | events into one alert. | +------+-------------------+--------------------------------------+ | 89 | SIEM.SOAR | Security Orchestration, Automation | | | | and Response — Automation of | | | | security workflows and incident | | | | response playbooks. Ex: auto- | | | | enriching an alert and opening a | | | | ticket. | +------+-------------------+--------------------------------------+ | 90 | SIEM.UPTIME | Uptime Monitoring — Analysis of | | | | service and infrastructure | | | | availability to detect outages and | | | | recoveries. Ex: alerting when a | | | | critical service becomes | | | | unreachable. | +------+-------------------+--------------------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 126] Internet-Draft IDMEFv2 October 2026 | 91 | TI.CTI | Cyber Threat Intelligence — | | | | Strategic and operational | | | | intelligence about threats, actors, | | | | and campaigns, produced for | | | | decision-making. Ex: a report on an | | | | APT targeting your sector. | +------+-------------------+--------------------------------------+ | 92 | TI.TI-FEED | Threat Intelligence Feed — A stream | | | | of structured threat data (IOCs, | | | | TTPs) consumed for detection and | | | | enrichment. Ex: a STIX/TAXII feed | | | | of malicious IPs. | +------+-------------------+--------------------------------------+ | 93 | TI.TIP | Threat Intelligence Platform — | | | | Aggregation, correlation, and | | | | management of threat intelligence | | | | from multiple sources. Ex: a | | | | platform correlating IOCs from | | | | several feeds. | +------+-------------------+--------------------------------------+ | 94 | VM.ASM | Attack Surface Management — | | | | Discovery and continuous monitoring | | | | of an organisation's externally | | | | exposed assets. Ex: finding an | | | | unknown public subdomain. | +------+-------------------+--------------------------------------+ | 95 | VM.PENTEST | Penetration Testing Tools — Tools | | | | supporting manual or automated | | | | offensive testing of systems and | | | | applications. Ex: exploitation | | | | frameworks and scanners used by | | | | testers. | +------+-------------------+--------------------------------------+ | 96 | VM.VULN-SCANNER | Vulnerability Scanner — Automated | | | | assessment of systems and | | | | applications for known | | | | vulnerabilities. Ex: a scanner | | | | reporting missing patches and CVEs. | +------+-------------------+--------------------------------------+ | 97 | ext-value | A value used to indicate that this | | | | attribute is extended and the actual | | | | value is provided using the | | | | corresponding ext-* attribute. (see | | | | Section 4.1.1) Ex: a vendor-specific | | | | analyzer type declared through the | | | | extension mechanism. | +------+-------------------+--------------------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 127] Internet-Draft IDMEFv2 October 2026 Table 11: enum_analyzer_category C.4. Analyzer Data +======+==============+============================================+ | Rank | Keyword | Description | +======+==============+============================================+ | 0 | Undetermined | The analyzed data type is unknown or not | | | | yet classified. Used as a placeholder | | | | when no other value applies. Example: a | | | | generic analyzer whose input could not be | | | | identified. | +------+--------------+--------------------------------------------+ | 1 | Acoustics | Sound pressure or specific frequency | | | | measurements captured by a microphone or | | | | acoustic sensor. Example: gunshot | | | | detection, glass break detection, machine | | | | noise spectrum. | +------+--------------+--------------------------------------------+ | 2 | Alert | IDMEFv2 or equivalent alert produced by an | | | | upstream analyzer and consumed as input by | | | | a correlator, aggregator or hypervisor. | | | | Example: IDMEFv2 JSON alert from a local | | | | SOC processed by a central SOC correlator. | +------+--------------+--------------------------------------------+ | 3 | Contact | Physical interaction or binary state | | | | change detected by a contact sensor. | | | | Example: door contact switch, cabinet open | | | | detection, tamper switch. | +------+--------------+--------------------------------------------+ | 4 | Content | Payload or body of a communication | | | | inspected at the application layer. | | | | Example: HTTP body, email message, SMTP | | | | DATA section, file transfer payload, DPI- | | | | matched bytes. | +------+--------------+--------------------------------------------+ | 5 | Data | Generic or opaque data stream whose | | | | structure is not further specified. | | | | Example: raw sensor telemetry, vendor- | | | | specific binary stream, serial output. | +------+--------------+--------------------------------------------+ | 6 | Datagram | Raw packet-level data captured at the | | | | network layer. Example: Ethernet frame, | | | | IPv4/IPv6 packet, TCP segment, UDP | | | | datagram, ICMP message. | +------+--------------+--------------------------------------------+ | 7 | External | Data originating from a third party such | | | | as a threat intelligence feed or an | Lehmann & Andrejak Expires 27 April 2027 [Page 128] Internet-Draft IDMEFv2 October 2026 | | | external CERT. Example: STIX/TAXII feed, | | | | IOC list, external CERT notification, | | | | vendor advisory. | +------+--------------+--------------------------------------------+ | 8 | File | Content or metadata of a file read by the | | | | analyzer for inspection, integrity or | | | | change detection. Example: file hash, PE | | | | header, document content, file | | | | permissions, modification timestamp. | +------+--------------+--------------------------------------------+ | 9 | Flow | Network flow records aggregating packets | | | | by 5-tuple or similar criteria. Example: | | | | NetFlow, IPFIX, sFlow records exported by | | | | routers or probes. | +------+--------------+--------------------------------------------+ | 10 | Fog | Visibility reduction or optical density | | | | measured by a fog sensor. Example: fog | | | | detection on a perimeter road, visibility | | | | monitoring for cameras. | +------+--------------+--------------------------------------------+ | 11 | Humidity | Relative humidity or moisture content in | | | | the air measured by a hygrometer. | | | | Example: datacenter humidity level, | | | | warehouse moisture monitoring. | +------+--------------+--------------------------------------------+ | 12 | Images | Visible-spectrum image or video frames | | | | captured by a camera. Example: CCTV | | | | frame, IP camera stream, facial | | | | recognition input. | +------+--------------+--------------------------------------------+ | 13 | Lidar | Point cloud or distance measurements | | | | produced by a laser-based sensor. | | | | Example: 3D point cloud from a rotating | | | | lidar, perimeter scanning lidar. | +------+--------------+--------------------------------------------+ | 14 | Light | Ambient light level or flicker detected by | | | | a photodetector. Example: lux | | | | measurement, room lighting state, strobe | | | | or flicker detection. | +------+--------------+--------------------------------------------+ | 15 | Log | Structured or unstructured event records | | | | produced by systems, applications or | | | | security devices. Example: syslog | | | | messages, Windows EventLog entries, | | | | journald records, firewall logs, | | | | application traces. | +------+--------------+--------------------------------------------+ | 16 | Magnetic | Magnetic field strength or anomaly | Lehmann & Andrejak Expires 27 April 2027 [Page 129] Internet-Draft IDMEFv2 October 2026 | | | detected by a magnetometer. Example: door | | | | open/close magnetic contact, vehicle | | | | detection, magnetic anomaly near | | | | equipment. | +------+--------------+--------------------------------------------+ | 17 | Particles | Concentration of dust, smoke or airborne | | | | contaminants measured by a particle | | | | sensor. Example: smoke detector, PM2.5 | | | | sensor, dust monitoring in a facility. | +------+--------------+--------------------------------------------+ | 18 | PCAP | Packet capture files stored on disk and | | | | analyzed offline. Example: .pcap and | | | | .pcapng files produced by tcpdump, dumpcap | | | | or Wireshark. | +------+--------------+--------------------------------------------+ | 19 | Rain | Precipitation detected or measured by a | | | | rain sensor. Example: rainfall detection | | | | on an outdoor site, rain gauge. | +------+--------------+--------------------------------------------+ | 20 | Seismic | Ground motion or earthquake-related | | | | signals captured by a seismograph. | | | | Example: earthquake detection, ground | | | | vibration near a datacenter. | +------+--------------+--------------------------------------------+ | 21 | SNMP | Data retrieved via the Simple Network | | | | Management Protocol from managed devices. | | | | Example: SNMP GET/WALK results, MIB object | | | | values, traps and informs. | +------+--------------+--------------------------------------------+ | 22 | Temperature | Ambient, device or surface temperature | | | | measured by a thermometer or thermal | | | | probe. Example: server room temperature, | | | | device CPU temperature, cold-chain | | | | monitoring. | +------+--------------+--------------------------------------------+ | 23 | Thermal | Infrared image or heat signature data | | | | captured by a thermal sensor. Example: | | | | thermal camera frame, heat map of a room | | | | or equipment. | +------+--------------+--------------------------------------------+ | 24 | Vibration | Mechanical oscillation or structural | | | | movement measured by an accelerometer or | | | | vibration sensor. Example: seismic-grade | | | | vibration of a server rack, structural | | | | health monitoring of a bridge. | +------+--------------+--------------------------------------------+ | 25 | Water | Presence, flow or level of water detected | | | | by a sensor. Example: leak detection | Lehmann & Andrejak Expires 27 April 2027 [Page 130] Internet-Draft IDMEFv2 October 2026 | | | under a raised floor, flood sensor, water | | | | flow meter. | +------+--------------+--------------------------------------------+ | 26 | ext-value | A value used to indicate that this | | | | attribute is extended and the actual value | | | | is provided using the corresponding ext-* | | | | attribute. (see Section 4.1.1) | +------+--------------+--------------------------------------------+ Table 12: enum_analyzer_data C.5. Analyzer Method +======+================+===========================================+ | Rank | Keyword | Description | +======+================+===========================================+ | 0 | Undetermined | Analyser method is undetermed | +------+----------------+-------------------------------------------+ | 1 | AI | An analyzer that uses machine | | | | learning, deep learning, or other | | | | artificial intelligence techniques to | | | | learn normal behavior and detect | | | | sophisticated or novel threats. | +------+----------------+-------------------------------------------+ | 2 | Anomaly | An analyzer that identifies | | | | deviations from established norms or | | | | baselines without relying on | | | | predefined signatures, often flagging | | | | unusual patterns in traffic, | | | | behavior, or system activity. | +------+----------------+-------------------------------------------+ | 3 | Behavioral | An analyzer that monitors and | | | | analyzes the actions of users, | | | | entities, or processes over time to | | | | detect malicious or suspicious | | | | activities that deviate from expected | | | | behavior patterns. | +------+----------------+-------------------------------------------+ | 4 | Biometric | An analyzer that uses electronic | | | | devices to capture and measure unique | | | | physical or behavioral | | | | characteristics (e.g., fingerprint, | | | | iris, voice) for identification or | | | | authentication purposes. | +------+----------------+-------------------------------------------+ | 5 | Blackhole | A method that analyses traffic | | | | destined for a non-existent or | | | | sinkhole route to identify malicious | Lehmann & Andrejak Expires 27 April 2027 [Page 131] Internet-Draft IDMEFv2 October 2026 | | | activity, such as connections to | | | | known command-and-control servers or | | | | scanning from infected hosts. | +------+----------------+-------------------------------------------+ | 6 | Contextual | An analyzer that enriches raw events | | | | with additional context (e.g., asset | | | | value, user role, time of day, | | | | business criticality) to prioritize | | | | alerts and assess true impact. | +------+----------------+-------------------------------------------+ | 7 | Correlation | An analyzer that aggregates and | | | | examines multiple, disparate data | | | | streams or events to identify complex | | | | relationships, patterns, sequences, | | | | or dependencies that indicate a | | | | security incident. | +------+----------------+-------------------------------------------+ | 8 | Ensemble | An analyzer that combines multiple | | | | detection methods (e.g., signature, | | | | anomaly, behavioral) to improve | | | | accuracy, reduce false positives, and | | | | detect threats that single methods | | | | might miss. | +------+----------------+-------------------------------------------+ | 9 | Fingerprinting | An analyzer that creates unique | | | | identifiers or "fingerprints" for | | | | devices, applications, or network | | | | stacks to detect spoofing, | | | | unauthorized devices, or | | | | configuration changes. | +------+----------------+-------------------------------------------+ | 10 | Frequency | An analyzer that detects incidents | | | | based on the rate or regularity of | | | | events (e.g., repeated failed logins, | | | | rapid-fire requests) exceeding or | | | | falling below expected frequencies. | +------+----------------+-------------------------------------------+ | 11 | Fusion | An analyzer that combines data from | | | | multiple heterogeneous sensors and | | | | sources to create a comprehensive, | | | | high-confidence view of an incident, | | | | reducing ambiguity and false alerts. | +------+----------------+-------------------------------------------+ | 12 | Geolocation | An analyzer that determines the | | | | physical location of an asset or | | | | event (e.g., login attempt, IP | | | | address, device) and flags activities | | | | occurring from unexpected or high- | Lehmann & Andrejak Expires 27 April 2027 [Page 132] Internet-Draft IDMEFv2 October 2026 | | | risk locations. | +------+----------------+-------------------------------------------+ | 13 | Graph-based | An analyzer that models relationships | | | | between entities (users, devices, | | | | processes) as graphs and detects | | | | anomalies or attack paths by | | | | analyzing connections, dependencies, | | | | and traversals. | +------+----------------+-------------------------------------------+ | 14 | Heat | An analyzer (sensor or device) that | | | | detects, measures, and monitors | | | | thermal energy (infrared radiation) | | | | to identify anomalies like fires, | | | | overheating equipment, or human | | | | presence. | +------+----------------+-------------------------------------------+ | 15 | Heuristic | An analyzer that detects potentially | | | | unknown threats by using algorithmic | | | | logic, rules of thumb, or suspicious | | | | characteristics rather than relying | | | | on specific signature matches. | +------+----------------+-------------------------------------------+ | 16 | Honeypot | A decoy system or resource designed | | | | to lure, detect, and analyze | | | | malicious activity by mimicking a | | | | legitimate target, diverting | | | | attackers away from real assets. | +------+----------------+-------------------------------------------+ | 17 | Hygiene | An analyzer that continuously checks | | | | systems and configurations against | | | | security best practices, compliance | | | | standards, or hardening guidelines to | | | | identify weaknesses or drift. | +------+----------------+-------------------------------------------+ | 18 | Integrity | An analyzer that monitors critical | | | | system components (files, | | | | configurations, registry keys) for | | | | unauthorized changes, verifying their | | | | integrity against a known good | | | | baseline. | +------+----------------+-------------------------------------------+ | 19 | Metadata | An analyzer that examines the data | | | | about data (e.g., file creation | | | | timestamps, email headers, connection | | | | logs) to uncover hidden relationships | | | | or suspicious attributes. | +------+----------------+-------------------------------------------+ | 20 | Monitor | An analyzer that continuously | Lehmann & Andrejak Expires 27 April 2027 [Page 133] Internet-Draft IDMEFv2 October 2026 | | | observes a system, network, or | | | | environment to track its state, | | | | health, or activity, often providing | | | | real-time alerts on specific | | | | conditions. | +------+----------------+-------------------------------------------+ | 21 | Movement | An analyzer (sensor or system) that | | | | detects, tracks, and quantifies | | | | physical motion using technologies | | | | like radar, lidar, or video | | | | analytics. | +------+----------------+-------------------------------------------+ | 22 | Orchestration | An analyzer that coordinates and | | | | triggers automated response actions | | | | based on detected incidents, often | | | | integrated with SOAR (Security | | | | Orchestration, Automation, and | | | | Response) platforms. | +------+----------------+-------------------------------------------+ | 23 | Pattern | An analyzer that identifies specific | | | | sequences, combinations, or recurring | | | | arrangements of events or data that | | | | indicate malicious activity, even if | | | | individual elements appear benign. | +------+----------------+-------------------------------------------+ | 24 | Policy | An analyzer that evaluates events, | | | | configurations, or behaviors against | | | | a set of predefined rules, | | | | configurations, or compliance | | | | requirements to detect violations or | | | | misconfigurations. | +------+----------------+-------------------------------------------+ | 25 | Predictive | An analyzer that uses historical data | | | | and modeling to forecast potential | | | | future incidents, vulnerabilities, or | | | | attack vectors before they occur. | +------+----------------+-------------------------------------------+ | 26 | Protocol | An analyzer that validates network | | | | traffic or communications against | | | | expected protocol specifications, RFC | | | | compliance, or standard behavior to | | | | detect anomalies or malicious | | | | variations. | +------+----------------+-------------------------------------------+ | 27 | Recon | An analyzer that actively or | | | | passively probes or monitors an | | | | environment to discover assets, | | | | services, or vulnerabilities, often | Lehmann & Andrejak Expires 27 April 2027 [Page 134] Internet-Draft IDMEFv2 October 2026 | | | as part of a defensive assessment or | | | | adversary simulation. | +------+----------------+-------------------------------------------+ | 28 | Reputation | An analyzer that evaluates the | | | | trustworthiness of an entity (e.g., | | | | IP address, domain, file hash) by | | | | checking it against known threat | | | | intelligence lists, blocklists, or | | | | reputation scores. | +------+----------------+-------------------------------------------+ | 29 | Rule-based | An analyzer that applies conditional | | | | logic (if-then-else statements) | | | | defined by experts to correlate | | | | events and generate alerts based on | | | | specific combinations of conditions. | +------+----------------+-------------------------------------------+ | 30 | Sequence | An analyzer that detects threats by | | | | examining the order and timing of | | | | events, identifying attack chains or | | | | kill chain progressions (e.g., scan → | | | | exploit → installation → C2). | +------+----------------+-------------------------------------------+ | 31 | Signature | An analyzer that detects known | | | | threats by matching events or | | | | patterns against a database of | | | | specific signatures, hashes, or | | | | Indicators of Compromise (IoCs). | +------+----------------+-------------------------------------------+ | 32 | Statistical | An analyzer that detects anomalies by | | | | establishing a baseline of normal | | | | behavior and identifying events that | | | | deviate significantly from expected | | | | statistical parameters. | +------+----------------+-------------------------------------------+ | 33 | Tarpit | A mechanism that intentionally slows | | | | down or delays suspicious connections | | | | (e.g., network connections or login | | | | attempts) to hinder automated attacks | | | | and scanning. | +------+----------------+-------------------------------------------+ | 34 | Threat | An analyzer that ingests and matches | | | Intelligence | internal events against external | | | | threat feeds, IoC lists, and | | | | adversary TTPs (Tactics, Techniques, | | | | and Procedures) to identify known | | | | threats. | +------+----------------+-------------------------------------------+ | 35 | Threshold | An analyzer that detects incidents by | Lehmann & Andrejak Expires 27 April 2027 [Page 135] Internet-Draft IDMEFv2 October 2026 | | | comparing a metric or count (e.g., | | | | number of failed logins, traffic | | | | volume) against a predefined limit or | | | | threshold. | +------+----------------+-------------------------------------------+ | 36 | Trend | An analyzer that monitors data over | | | | extended periods to identify gradual | | | | changes, emerging patterns, or long- | | | | term shifts that may indicate | | | | evolving threats or security | | | | degradation. | +------+----------------+-------------------------------------------+ | 37 | ext-value | A value used to indicate that this | | | | attribute is extended and the actual | | | | value is provided using the | | | | corresponding ext-* attribute. (see | | | | Section 4.1.1) | +------+----------------+-------------------------------------------+ Table 13: Analyzer Methods C.6. Source Category +====+=========================================+===================+ |Rank| Keyword |Description | +====+=========================================+===================+ |0 | Undetermined |Source Category is | | | |undetermined. | +----+-----------------------------------------+-------------------+ |1 | Acoustic.Sound.GlassBreak |Specific | | | |frequencies (glass | | | |breaking, gunshots)| +----+-----------------------------------------+-------------------+ |2 | Acoustic.Sound.Infrasound |Infrasound (nuclear| | | |explosions, | | | |volcanic activity) | +----+-----------------------------------------+-------------------+ |3 | Acoustic.Sound.PressurizedLeak |Leaks in | | | |pressurized pipes | | | |(high-frequency | | | |hiss) | +----+-----------------------------------------+-------------------+ |4 | Acoustic.Sound.SonarEcho |Sonar echoes | | | |(submarines, fish, | | | |seafloor mapping) | +----+-----------------------------------------+-------------------+ |5 | Acoustic.Sound.UltrasonicNoise |Ultrasonic noise | | | |(for pest detection| Lehmann & Andrejak Expires 27 April 2027 [Page 136] Internet-Draft IDMEFv2 October 2026 | | |or leak detection) | +----+-----------------------------------------+-------------------+ |6 | Acoustic.Vibration.Footstep |Footsteps | | | |(geophones or | | | |seismic sensors) | +----+-----------------------------------------+-------------------+ |7 | Acoustic.Vibration.Seismic |Seismic activity | | | |(earthquakes, | | | |tremors) | +----+-----------------------------------------+-------------------+ |8 | Acoustic.Vibration.StructuralCrack |Structural | | | |integrity (cracks | | | |via acoustic | | | |emission) | +----+-----------------------------------------+-------------------+ |9 | Acoustic.Vibration.VehicleVibe |Vehicle movement | | | |(magnetic or | | | |seismic) | +----+-----------------------------------------+-------------------+ |10 | Acoustic.Vibration.VibAnalysis |Machinery imbalance| | | |(vibration | | | |analysis) | +----+-----------------------------------------+-------------------+ |11 | ChemBio.Gases.CO |Carbon Monoxide | | | |(CO) | +----+-----------------------------------------+-------------------+ |12 | ChemBio.Gases.CWA |CWA (Chemical | | | |Warfare Agents - | | | |Nerve gas, Blister | | | |agents) | +----+-----------------------------------------+-------------------+ |13 | ChemBio.Gases.Freon |Refrigerant leaks | | | |(Freon) | +----+-----------------------------------------+-------------------+ |14 | ChemBio.Gases.Hydrogen |Hydrogen | +----+-----------------------------------------+-------------------+ |15 | ChemBio.Gases.Methane |Natural Gas / | | | |Methane | +----+-----------------------------------------+-------------------+ |16 | ChemBio.Gases.O2Level |Oxygen levels | | | |(deficiency or | | | |enrichment) | +----+-----------------------------------------+-------------------+ |17 | ChemBio.Gases.Propane |Propane / LPG | +----+-----------------------------------------+-------------------+ |18 | ChemBio.Gases.Radon |Radon | +----+-----------------------------------------+-------------------+ |19 | ChemBio.Gases.VOC |Volatile Organic | Lehmann & Andrejak Expires 27 April 2027 [Page 137] Internet-Draft IDMEFv2 October 2026 | | |Compounds (VOCs) - | | | |paint fumes, off- | | | |gassing | +----+-----------------------------------------+-------------------+ |20 | ChemBio.Properties.ORP |Oxidation-Reduction| | | |Potential (ORP) | +----+-----------------------------------------+-------------------+ |21 | ChemBio.Properties.pHLevel |pH levels (acidity/| | | |alkalinity) | +----+-----------------------------------------+-------------------+ |22 | ChemBio.Properties.Salinity |Salinity | +----+-----------------------------------------+-------------------+ |23 | ChemBio.Threats.Anthrax |Anthrax spores | +----+-----------------------------------------+-------------------+ |24 | ChemBio.Threats.Botulinum |Botulinum toxin | +----+-----------------------------------------+-------------------+ |25 | ChemBio.Threats.Pathogen |Pathogens in water | | | |(E. coli, Cholera) | +----+-----------------------------------------+-------------------+ |26 | ChemBio.Threats.Ricin |Ricin | +----+-----------------------------------------+-------------------+ |27 | Cyber.Application.SQLQuery |Malicious code | | | |injected into a | | | |database query (SQL| | | |Injection). | +----+-----------------------------------------+-------------------+ |28 | Cyber.Application.XSSPayload |The script injected| | | |into a webpage to | | | |steal data or | | | |redirect users. | +----+-----------------------------------------+-------------------+ |29 | Cyber.Cloud.APIToken |A compromised key | | | |used to access | | | |cloud resources | | | |(AWS, Azure) or | | | |SaaS platforms. | +----+-----------------------------------------+-------------------+ |30 | Cyber.Cloud.BucketName |The specific cloud | | | |storage location | | | |where data was | | | |stored or | | | |exfiltrated from. | +----+-----------------------------------------+-------------------+ |31 | Cyber.Cloud.CloudResourceID |The unique ID of | | | |the compromised | | | |virtual machine or | | | |database. | +----+-----------------------------------------+-------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 138] Internet-Draft IDMEFv2 October 2026 |32 | Cyber.Cloud.OAuthApp |A malicious third- | | | |party app granted | | | |permissions to a | | | |user's data. | +----+-----------------------------------------+-------------------+ |33 | Cyber.Email.EmailAuthResult |The authentication | | | |result showing if | | | |the email passed | | | |security checks. | +----+-----------------------------------------+-------------------+ |34 | Cyber.Email.MessageID |A unique identifier| | | |for the email used | | | |to track it across | | | |mail servers. | +----+-----------------------------------------+-------------------+ |35 | Cyber.Email.RecipientEmail |The target email | | | |address of the | | | |attack. | +----+-----------------------------------------+-------------------+ |36 | Cyber.Email.ReplyToEmail |The address where | | | |replies go; often | | | |different from the | | | |sender for | | | |tracking. | +----+-----------------------------------------+-------------------+ |37 | Cyber.Email.ReturnPath |The address where | | | |non-delivery | | | |receipts go; used | | | |in spoofing | | | |analysis. | +----+-----------------------------------------+-------------------+ |38 | Cyber.Email.SenderEmail |The "From" address | | | |used in a phishing | | | |campaign. | +----+-----------------------------------------+-------------------+ |39 | Cyber.Email.XOrigIP |The original IP | | | |address of the | | | |sender (if recorded| | | |by the mail | | | |server). | +----+-----------------------------------------+-------------------+ |40 | Cyber.Endpoint.CmdLine |The exact command | | | |line used to | | | |execute the | | | |malware; often | | | |reveals attacker | | | |intent. | +----+-----------------------------------------+-------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 139] Internet-Draft IDMEFv2 October 2026 |41 | Cyber.Endpoint.DLL |The name of a | | | |malicious library | | | |loaded into a | | | |legitimate process | | | |(DLL Sideloading). | +----+-----------------------------------------+-------------------+ |42 | Cyber.Endpoint.FileHash |The cryptographic | | | |fingerprint of the | | | |malicious file | | | |(SHA256, MD5). | +----+-----------------------------------------+-------------------+ |43 | Cyber.Endpoint.FilePath |The location on the| | | |file system where | | | |the malware | | | |resides. | +----+-----------------------------------------+-------------------+ |44 | Cyber.Endpoint.MemoryArtifact |Code or processes | | | |that exist only in | | | |RAM (volatile | | | |memory) and not on | | | |disk. | +----+-----------------------------------------+-------------------+ |45 | Cyber.Endpoint.PID |The unique | | | |identifier of the | | | |malicious process | | | |at the time of | | | |analysis. | +----+-----------------------------------------+-------------------+ |46 | Cyber.Endpoint.ProcessName |The name of the | | | |malicious | | | |executable file | | | |running on the | | | |endpoint. | +----+-----------------------------------------+-------------------+ |47 | Cyber.Endpoint.RegistryKey |The Windows | | | |Registry path used | | | |for persistence or | | | |configuration | | | |changes. | +----+-----------------------------------------+-------------------+ |48 | Cyber.Endpoint.ScheduledTask |The name of a task | | | |created by the | | | |attacker for | | | |persistence or | | | |execution. | +----+-----------------------------------------+-------------------+ |49 | Cyber.Endpoint.ServiceName |The name of a | | | |malicious service | Lehmann & Andrejak Expires 27 April 2027 [Page 140] Internet-Draft IDMEFv2 October 2026 | | |installed to run | | | |the malware. | +----+-----------------------------------------+-------------------+ |50 | Cyber.Forensics.NetFlow |Metadata about the | | | |connection (who | | | |talked to whom, | | | |when, and data | | | |volume). | +----+-----------------------------------------+-------------------+ |51 | Cyber.Forensics.PacketPayload |The raw data being | | | |transmitted | | | |containing | | | |passwords or | | | |exfiltrated data. | +----+-----------------------------------------+-------------------+ |52 | Cyber.Hardware.DeviceSerial |The unique | | | |identifier of a | | | |specific | | | |compromised laptop | | | |or mobile device. | +----+-----------------------------------------+-------------------+ |53 | Cyber.Hardware.USBDeviceID |The specific | | | |make/model/serial | | | |of a USB drive used| | | |to introduce | | | |malware. | +----+-----------------------------------------+-------------------+ |54 | Cyber.Identity.LoginTimestamp |The specific time | | | |of an unusual login| | | |(e.g., 3:00 AM from| | | |a foreign | | | |location). | +----+-----------------------------------------+-------------------+ |55 | Cyber.Identity.Username |The specific user | | | |account that was | | | |compromised or used| | | |for lateral | | | |movement. | +----+-----------------------------------------+-------------------+ |56 | Cyber.Network.IPv4 |The source IP of an| | | |attacker, a Command| | | |& Control (C2) | | | |server, or a | | | |malicious scan. | +----+-----------------------------------------+-------------------+ |57 | Cyber.Network.IPv6 |The source IP in | | | |IPv6 format; | | | |increasingly used | Lehmann & Andrejak Expires 27 April 2027 [Page 141] Internet-Draft IDMEFv2 October 2026 | | |to bypass | | | |IPv4-based | | | |allowlists. | +----+-----------------------------------------+-------------------+ |58 | Cyber.Network.MAC |The physical device| | | |identifier on a | | | |local network; | | | |useful if the | | | |attacker is on- | | | |site. | +----+-----------------------------------------+-------------------+ |59 | Cyber.Network.Port |The specific source| | | |or destination port| | | |used (e.g., 445 for| | | |ransomware | | | |spreading). | +----+-----------------------------------------+-------------------+ |60 | Cyber.Network.Protocol |The network | | | |protocol used; | | | |anomalous use may | | | |indicate tunneling | | | |(e.g., DNS | | | |tunneling). | +----+-----------------------------------------+-------------------+ |61 | Cyber.Web.Domain |The domain hosting | | | |malware or Command | | | |& Control | | | |infrastructure | | | |(e.g., evil.com). | +----+-----------------------------------------+-------------------+ |62 | Cyber.Web.HTTPMethod |Unusual HTTP | | | |methods like PUT or| | | |DELETE used to | | | |manipulate data. | +----+-----------------------------------------+-------------------+ |63 | Cyber.Web.ReferrerHeader |The page the user | | | |was on before | | | |clicking the | | | |malicious link. | +----+-----------------------------------------+-------------------+ |64 | Cyber.Web.SessionID |A hijacked session | | | |token used to | | | |impersonate a user | | | |without a password.| +----+-----------------------------------------+-------------------+ |65 | Cyber.Web.URIPath |The specific | | | |directory or file | | | |requested on the | Lehmann & Andrejak Expires 27 April 2027 [Page 142] Internet-Draft IDMEFv2 October 2026 | | |web server. | +----+-----------------------------------------+-------------------+ |66 | Cyber.Web.URL |The full malicious | | | |link pointing to a | | | |payload or phishing| | | |page. | +----+-----------------------------------------+-------------------+ |67 | Cyber.Web.UserAgent |The browser or | | | |application | | | |signature used by | | | |the attacker when | | | |connecting. | +----+-----------------------------------------+-------------------+ |68 | ElectroMag.Infrared.GasLeakIR |Gas leaks (specific| | | |gases absorb | | | |specific IR | | | |wavelengths) | +----+-----------------------------------------+-------------------+ |69 | ElectroMag.Infrared.HeatTemp |Heat (temperature | | | |of objects) | +----+-----------------------------------------+-------------------+ |70 | ElectroMag.Infrared.MoistureContent |Moisture content | | | |(in materials) | +----+-----------------------------------------+-------------------+ |71 | ElectroMag.Infrared.ThermalGradient |Thermal gradients | | | |(heat loss in | | | |buildings) | +----+-----------------------------------------+-------------------+ |72 | ElectroMag.Infrared.WarmBody |Warm bodies | | | |(humans, animals) | | | |via Passive | | | |Infrared (PIR) | +----+-----------------------------------------+-------------------+ |73 | ElectroMag.Ultraviolet.BioContamUV |Biological | | | |contamination | +----+-----------------------------------------+-------------------+ |74 | ElectroMag.Ultraviolet.CoronaArc |Corona discharge | | | |(electrical arcing)| +----+-----------------------------------------+-------------------+ |75 | ElectroMag.Ultraviolet.FlameUV |Flames (fire | | | |detection) | +----+-----------------------------------------+-------------------+ |76 | ElectroMag.Ultraviolet.ForgeryUV |Forgery (detecting | | | |UV security | | | |features on | | | |documents) | +----+-----------------------------------------+-------------------+ |77 | ElectroMag.Light.BiometricEye |Biological | Lehmann & Andrejak Expires 27 April 2027 [Page 143] Internet-Draft IDMEFv2 October 2026 | | |signatures | | | |(retinas, irises) -| | | |Failed recognition | | | |indicates intrusion| | | |attempt | +----+-----------------------------------------+-------------------+ |78 | ElectroMag.Light.EdgesShapes |Edges and shapes | | | |(for machine | | | |vision) | +----+-----------------------------------------+-------------------+ |79 | ElectroMag.Light.Flicker |Flicker (from | | | |faulty lighting or | | | |machinery) | +----+-----------------------------------------+-------------------+ |80 | ElectroMag.Light.LightColor |Color and | | | |wavelength | | | |(spectral content) | +----+-----------------------------------------+-------------------+ |81 | ElectroMag.Light.LightPresence |Presence of light | | | |(ambient | | | |brightness) | +----+-----------------------------------------+-------------------+ |82 | ElectroMag.Light.MotionOptical |Motion (optical | | | |flow, changes in | | | |pixel arrays) | +----+-----------------------------------------+-------------------+ |83 | ElectroMag.Light.ObjectsGeneric |Specific objects | | | |(via computer | | | |vision: faces, | | | |vehicles, text, | | | |barcodes) | +----+-----------------------------------------+-------------------+ |84 | Force.Atmospheric.Altitude |Altitude (in | | | |aircraft) | +----+-----------------------------------------+-------------------+ |85 | Force.Atmospheric.BaroPress |Barometric pressure| | | |(weather changes) | +----+-----------------------------------------+-------------------+ |86 | Force.Atmospheric.VacuumLevel |Vacuum levels (in | | | |manufacturing) | +----+-----------------------------------------+-------------------+ |87 | Force.Fluid.Airflow |Airflow | | | |(differential | | | |pressure) | +----+-----------------------------------------+-------------------+ |88 | Force.Fluid.WaterPressure |Water pressure (for| | | |leak detection via | | | |pressure drop) | Lehmann & Andrejak Expires 27 April 2027 [Page 144] Internet-Draft IDMEFv2 October 2026 +----+-----------------------------------------+-------------------+ |89 | Force.Touch.GripStrength |Grip strength | +----+-----------------------------------------+-------------------+ |90 | Force.Touch.PhysicalContact |Physical contact | | | |(bumpers on robots,| | | |touch screens) | +----+-----------------------------------------+-------------------+ |91 | Force.Touch.TirePressure |Tire pressure | +----+-----------------------------------------+-------------------+ |92 | Force.Touch.Weight |Weight (scales, | | | |load cells) | +----+-----------------------------------------+-------------------+ |93 | Radiation.General.Alpha |Alpha particles | +----+-----------------------------------------+-------------------+ |94 | Radiation.General.Beta |Beta particles | +----+-----------------------------------------+-------------------+ |95 | Radiation.General.Cosmic |Cosmic rays | +----+-----------------------------------------+-------------------+ |96 | Radiation.General.Gamma |Gamma rays | +----+-----------------------------------------+-------------------+ |97 | Radiation.General.Neutron |Neutron radiation | +----+-----------------------------------------+-------------------+ |98 | Radiation.General.RadonDecay |Radon gas (decay | | | |products) | +----+-----------------------------------------+-------------------+ |99 | Radiation.General.Xray |X-rays | +----+-----------------------------------------+-------------------+ |100 | Magnetic.General.CurrentFlow |Current flow (Hall | | | |effect sensors, | | | |clamp meters) | +----+-----------------------------------------+-------------------+ |101 | Magnetic.General.ESD |Electrostatic | | | |discharge | +----+-----------------------------------------+-------------------+ |102 | Magnetic.General.Ferrous |Ferrous metals (via| | | |magnetic | | | |disturbance) | +----+-----------------------------------------+-------------------+ |103 | Magnetic.General.MagneticAnomaly |Magnetic anomalies | | | |(submarines, buried| | | |structures) | +----+-----------------------------------------+-------------------+ |104 | Magnetic.General.Orientation |Orientation | | | |(Compass / | | | |Magnetometer - | | | |detecting Earth's | | | |magnetic field) | +----+-----------------------------------------+-------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 145] Internet-Draft IDMEFv2 October 2026 |105 | Magnetic.General.Powerline |Power lines (AC | | | |magnetic fields) | +----+-----------------------------------------+-------------------+ |106 | Magnetic.General.Voltage |Voltage (non- | | | |contact voltage | | | |testers) | +----+-----------------------------------------+-------------------+ |107 | Object.Indoor.Container |Bottles / Cups / | | | |Cutlery | +----+-----------------------------------------+-------------------+ |108 | Object.Indoor.Document |Books / Papers / | | | |Documents | +----+-----------------------------------------+-------------------+ |109 | Object.Indoor.Electronics |Electronics | | | |(laptops / phones /| | | |TVs) | +----+-----------------------------------------+-------------------+ |110 | Object.Indoor.Furniture |Furniture (chairs /| | | |tables / sofas) | +----+-----------------------------------------+-------------------+ |111 | Object.Indoor.Weapon |Weapons (guns / | | | |knives) | +----+-----------------------------------------+-------------------+ |112 | Object.LivingBeings.Animal |Animals (general | | | |wildlife/livestock/| | | |pets) | +----+-----------------------------------------+-------------------+ |113 | Object.LivingBeings.BodyPose |Pose (skeleton | | | |keypoints / body | | | |position) | +----+-----------------------------------------+-------------------+ |114 | Object.LivingBeings.EyeGaze |Eyes (gaze tracking| | | |/ eye blink) | +----+-----------------------------------------+-------------------+ |115 | Object.LivingBeings.Face |Faces (facial | | | |recognition) | +----+-----------------------------------------+-------------------+ |116 | Object.LivingBeings.HandGesture |Hands (hand | | | |gestures / raising | | | |hand) | +----+-----------------------------------------+-------------------+ |117 | Object.LivingBeings.Human |Humans (person/ | | | |people detection) | +----+-----------------------------------------+-------------------+ |118 | Object.Outdoor.Building |Buildings / Houses | +----+-----------------------------------------+-------------------+ |119 | Object.Outdoor.Pothole |Potholes / Road | | | |cracks | Lehmann & Andrejak Expires 27 April 2027 [Page 146] Internet-Draft IDMEFv2 October 2026 +----+-----------------------------------------+-------------------+ |120 | Object.Outdoor.RoadSign |Road signs / | | | |Traffic lights | +----+-----------------------------------------+-------------------+ |121 | Object.Outdoor.Vegetation |Trees / Plants / | | | |Vegetation | +----+-----------------------------------------+-------------------+ |122 | Object.SpecificScenes.FireVisual |Fire / Flames | | | |(visual spectrum) | +----+-----------------------------------------+-------------------+ |123 | Object.SpecificScenes.Flood |Flooding / Water | | | |accumulation | +----+-----------------------------------------+-------------------+ |124 | Object.SpecificScenes.SmokeVisual |Smoke plume (visual| | | |spectrum) | +----+-----------------------------------------+-------------------+ |125 | Object.SpecificScenes.Snow |Snow coverage | +----+-----------------------------------------+-------------------+ |126 | Object.Vehicles.Aircraft |Aircraft (drones / | | | |planes / | | | |helicopters) | +----+-----------------------------------------+-------------------+ |127 | Object.Vehicles.Boat |Boats / Ships | +----+-----------------------------------------+-------------------+ |128 | Object.Vehicles.Bus |Buses | +----+-----------------------------------------+-------------------+ |129 | Object.Vehicles.Car |Cars / Automobiles | +----+-----------------------------------------+-------------------+ |130 | Object.Vehicles.LicensePlate |License plates | | | |(Automatic Number | | | |Plate Recognition -| | | |ANPR) | +----+-----------------------------------------+-------------------+ |131 | Object.Vehicles.Moto |Motorcycles / | | | |Bicycles | +----+-----------------------------------------+-------------------+ |132 | Object.Vehicles.Truck |Trucks | +----+-----------------------------------------+-------------------+ |133 | Particulate.Aerosols.Bioaerosol |Viral or bacterial | | | |particles (bio- | | | |aerosol detectors) | +----+-----------------------------------------+-------------------+ |134 | Particulate.Aerosols.Dust |Airborne dust | | | |(particulate | | | |counters) | +----+-----------------------------------------+-------------------+ |135 | Particulate.Aerosols.Pollen |Pollen and | | | |allergens | Lehmann & Andrejak Expires 27 April 2027 [Page 147] Internet-Draft IDMEFv2 October 2026 +----+-----------------------------------------+-------------------+ |136 | Particulate.Aerosols.SmokeIonization |Combustion | | | |particles | | | |(Ionization smoke | | | |detectors) | +----+-----------------------------------------+-------------------+ |137 | Particulate.Aerosols.SmokePhotoelectric |Visible smoke | | | |obscuration | | | |(Photoelectric | | | |smoke detectors) | +----+-----------------------------------------+-------------------+ |138 | Particulate.Liquids.ChemicalSpill |Chemical spills | | | |(specific | | | |conductivity or pH | | | |changes) | +----+-----------------------------------------+-------------------+ |139 | Particulate.Liquids.FuelSheen |Fuel/Oil sheen on | | | |water | +----+-----------------------------------------+-------------------+ |140 | Particulate.Liquids.LiquidLevel |Level of liquid in | | | |a tank (ultrasonic,| | | |capacitive, float) | +----+-----------------------------------------+-------------------+ |141 | Particulate.Liquids.WaterLeak |Water leakage | | | |(conductivity or | | | |float switches) | +----+-----------------------------------------+-------------------+ |142 | Particulate.Solids.DensityChange |Density changes (in| | | |manufacturing) | +----+-----------------------------------------+-------------------+ |143 | Particulate.Solids.ForeignObject |Foreign objects in | | | |food (X-ray | | | |machines) | +----+-----------------------------------------+-------------------+ |144 | Particulate.Solids.GrainFlow |Grain flow (in | | | |agriculture) | +----+-----------------------------------------+-------------------+ |145 | Particulate.Solids.Landmine |Landmines/UXO | | | |(Ground Penetrating| | | |Radar) | +----+-----------------------------------------+-------------------+ |146 | Particulate.Solids.Metal |Metal (Metal | | | |detectors via eddy | | | |currents) | +----+-----------------------------------------+-------------------+ |147 | Software.Detected.Crowd |Crowd formation | +----+-----------------------------------------+-------------------+ |148 | Software.Detected.CyberAttack |Cyber-attack | Lehmann & Andrejak Expires 27 April 2027 [Page 148] Internet-Draft IDMEFv2 October 2026 | | |(Anomalous network | | | |traffic patterns) | +----+-----------------------------------------+-------------------+ |149 | Software.Detected.Drowsiness |Drowsiness (Eye | | | |closure detection | | | |via camera) | +----+-----------------------------------------+-------------------+ |150 | Software.Detected.Explosion |Explosion (Sudden | | | |light flash + | | | |pressure wave + | | | |sound) | +----+-----------------------------------------+-------------------+ |151 | Software.Detected.FailedBiometric |Failed retina/iris | | | |scan (multiple | | | |failures may | | | |indicate intrusion)| +----+-----------------------------------------+-------------------+ |152 | Software.Detected.FireFusion |Fire (Combination | | | |of smoke, heat, and| | | |flicker) | +----+-----------------------------------------+-------------------+ |153 | Software.Detected.Intrusion |Intrusion (Crossing| | | |a virtual line) | +----+-----------------------------------------+-------------------+ |154 | Software.Detected.Loitering |Loitering (Person | | | |staying too long) | +----+-----------------------------------------+-------------------+ |155 | Software.Detected.Tailgating |Tailgating | | | |(Following someone | | | |through a door) | +----+-----------------------------------------+-------------------+ |156 | ext-value |A value used to | | | |indicate that this | | | |attribute is | | | |extended and the | | | |actual value is | | | |provided using the | | | |corresponding ext-*| | | |attribute. (see | | | |Section 4.1.1) | +----+-----------------------------------------+-------------------+ Table 14: Source Categories Lehmann & Andrejak Expires 27 April 2027 [Page 149] Internet-Draft IDMEFv2 October 2026 C.7. Target Category +======+==============================+==========================+ | Rank | Keyword | Description | +======+==============================+==========================+ | 0 | Undetermined | Target Category is | | | | undetermined | +------+------------------------------+--------------------------+ | 1 | Commercial.ClientBase | Client portfolio, active | | | | contracts | +------+------------------------------+--------------------------+ | 2 | Commercial.Partnerships | Strategic alliances, | | | | partner networks | +------+------------------------------+--------------------------+ | 3 | Commercial.Reputation | Brand image, online | | | | reputation, goodwill | +------+------------------------------+--------------------------+ | 4 | Financial.Cash | Liquidities, bank | | | | accounts | +------+------------------------------+--------------------------+ | 5 | Financial.Investments | Shares, bonds, holdings | | | | in subsidiaries | +------+------------------------------+--------------------------+ | 6 | Financial.Receivables | Customer receivables, | | | | promissory notes | +------+------------------------------+--------------------------+ | 7 | Furniture.Fittings | Lighting, partitions, | | | | flooring | +------+------------------------------+--------------------------+ | 8 | Furniture.HVAC | Air conditioning, | | | | heating systems (non- | | | | industrial) | +------+------------------------------+--------------------------+ | 9 | Furniture.OfficeFurniture | Desks, chairs, filing | | | | cabinets | +------+------------------------------+--------------------------+ | 10 | Human.EmployerBrand | Employment contracts, | | | | recruitment appeal | +------+------------------------------+--------------------------+ | 11 | Human.Organization | Work processes, internal | | | | know-how | +------+------------------------------+--------------------------+ | 12 | Human.Skills | Employee expertise, team | | | | competencies | +------+------------------------------+--------------------------+ | 13 | Infrastructure.CivilWorks | Bridges, loading docks, | | | | quays | +------+------------------------------+--------------------------+ Lehmann & Andrejak Expires 27 April 2027 [Page 150] Internet-Draft IDMEFv2 October 2026 | 14 | Infrastructure.Foundations | Special foundations, | | | | internal roads, | | | | pavements | +------+------------------------------+--------------------------+ | 15 | Infrastructure.Networks | Buried water, gas, | | | | electricity, fiber | | | | networks | +------+------------------------------+--------------------------+ | 16 | IP.Copyrights | Software code, manuals, | | | | artistic works | +------+------------------------------+--------------------------+ | 17 | IP.Patents | Registered patents, | | | | inventions | +------+------------------------------+--------------------------+ | 18 | IP.Trademarks | Brand names, logos, | | | | registered designs | +------+------------------------------+--------------------------+ | 19 | IT.Endpoints | Computers, printers, | | | | scanners | +------+------------------------------+--------------------------+ | 20 | IT.Hardware | Servers, storage arrays, | | | | cabling | +------+------------------------------+--------------------------+ | 21 | IT.Telecom | WiFi access points, | | | | phones, smartphones | +------+------------------------------+--------------------------+ | 22 | Logistics.Containers | Containers, trailers, | | | | wagons | +------+------------------------------+--------------------------+ | 23 | Logistics.SpecialVehicles | Mobile cranes, aerial | | | | work platforms | +------+------------------------------+--------------------------+ | 24 | Logistics.Vehicles | Cars, trucks, forklifts | +------+------------------------------+--------------------------+ | 25 | Marketing.Content | Market studies, ad | | | | campaigns, social media | +------+------------------------------+--------------------------+ | 26 | Marketing.Domains | Website URLs, domain | | | | names | +------+------------------------------+--------------------------+ | 27 | Marketing.Identity | Visual identity, logo, | | | | brand guidelines | +------+------------------------------+--------------------------+ | 28 | Production.HeavyEquipment | Presses, furnaces, | | | | compressors, generators | +------+------------------------------+--------------------------+ | 29 | Production.Machinery | Assembly lines, | | | | industrial robots, | Lehmann & Andrejak Expires 27 April 2027 [Page 151] Internet-Draft IDMEFv2 October 2026 | | | conveyors | +------+------------------------------+--------------------------+ | 30 | Production.MachineTools | Lathes, milling | | | | machines, industrial 3D | | | | printers | +------+------------------------------+--------------------------+ | 31 | RealEstate.Buildings | Factories, warehouses, | | | | offices, commercial | | | | premises | +------+------------------------------+--------------------------+ | 32 | RealEstate.Land | Unbuilt land, forests, | | | | or agricultural grounds | +------+------------------------------+--------------------------+ | 33 | RealEstate.SpecialStructures | Hangars, silos, parking | | | | lots | +------+------------------------------+--------------------------+ | 34 | Software.Applications | ERP, CRM, SaaS platforms | +------+------------------------------+--------------------------+ | 35 | Software.Data | Customer databases, | | | | supplier lists, | | | | prospects | +------+------------------------------+--------------------------+ | 36 | Software.Licenses | Software usage rights, | | | | subscriptions | +------+------------------------------+--------------------------+ | 37 | ext-value | A value used to indicate | | | | that this attribute is | | | | extended and the actual | | | | value is provided using | | | | the corresponding ext-* | | | | attribute. (see | | | | Section 4.1.1) | +------+------------------------------+--------------------------+ Table 15: Target Categories Appendix D. Examples This section contains several examples of events/incidents which may be described using the IDMEF Data Model defined in. For each example, the serialization method listed in Section 5 was used on the original IDMEF message to produce a JSON representation. Lehmann & Andrejak Expires 27 April 2027 [Page 152] Internet-Draft IDMEFv2 October 2026 D.1. Physical intrusion Listing 1 describes an incident where an unidentified man was detected on company premises near the building where server room A is located. { "Version": "2.D.V07", "ID": "819df7bc-35ef-40d8-bbee-1901117370b1", "Description": "Potential intruder detected", "Type": "Physical", "Priority": "Low", "Status": "Incident", "Cause": "Malicious", "CreateTime": "2021-05-10T16:52:13.075994+00:00", "StartTime": "2021-05-10T16:52:13+00:00", "Category": [ "Access.Forced" ], "Analyzer": { "Name": "BigBrother", "Hostname": "bb.acme.com", "Model": "Big Brother v42", "Category": [ "PHY.HAR", "FRC.FR-CAM" ], "Data": [ "Images" ], "Method": [ "Movement", "Biometric", "AI" ], "IP": "192.0.2.1" }, "Sensor": [ { "IP": "192.0.2.2", "Name": "Camera #23", "Model": "SuperDuper Camera v1", "Location": "Hallway to server room A1" } ], "Source": [ { "Note": "Black Organization, aka. APT 4869" Lehmann & Andrejak Expires 27 April 2027 [Page 153] Internet-Draft IDMEFv2 October 2026 } ], "Attachment": [ { "Name": "wanted", "FileName": "fbi-wanted-poster.jpg", "Size": 1234567, "Ref": ["https://www.fbi.gov/wanted/topten"], "ContentType": "image/jpg", "ContentEncoding": "base64", "Content": "..." }, { "Name": "pic01", "Note": "Hi-res picture showing John Doe near server room A1", "ExternalURI": ["ftps://192.0.2.1/cam23/20210510165211.jpg"], "ContentType": "image/jpg" } ] } D.2. Cyberattack Listing 2 describes an incident related to a potential bruteforce attack against the "root" user account of the server at 192.0.2.2 and 2001:db8::/32. { "Version": "2.D.V07", "ID": "819df7bc-35ef-40d8-bbee-1901117370b2", "Description": "Potential bruteforce attack on root user account", "Type": "Cyber", "Priority": "Medium", "CreateTime": "2021-05-10T16:55:29.196408+00:00", "StartTime": "2021-05-10T16:55:29+00:00", "Category": [ "Access.Forced" ], "Analyzer": { "Name": "SIEM", "Hostname": "siem.acme.com", "Model": "Concerto SIEM 5.2", "Category": [ "SIEM.SIEM", "SIEM.LOG" ], "Data": [ "Log" Lehmann & Andrejak Expires 27 April 2027 [Page 154] Internet-Draft IDMEFv2 October 2026 ], "Method": [ "Monitor", "Signature" ], "IP": "192.0.2.1" }, "Sensor": [ { "IP": "192.0.2.5", "Name": "syslog", "Hostname": "www.acme.com", "Model": "rsyslog 8.2110", "Location": "Server room A1, rack 10" } ], "Target": [ { "IP": "192.0.2.2", "Hostname": "www.acme.com", "Location": "Server room A1, rack 10", "User": "root" }, { "IP": "2001:db8::/32", "Hostname": "www.acme.com", "Location": "Server room A1, rack 10", "User": "root" } ] } D.3. Server outage Listing 3 describes an incident where the webserver at "www.example.com" encountered some kind of failure condition resulting in an outage. Lehmann & Andrejak Expires 27 April 2027 [Page 155] Internet-Draft IDMEFv2 October 2026 { "Version": "2.D.V07", "ID": "819df7bc-35ef-40d8-bbee-1901117370b3", "Description": "A server did not reply to an ICMP ping request", "Type": "Availability", "Priority": "Medium", "Status": "Incident", "Cause": "Unknown", "CreateTime": "2021-05-10T16:59:11.875209+00:00", "StartTime": "2021-05-10T16:59:11.875209+00:00", "Category": [ "Availability.Outage" ], "Analyzer": { "Name": "NMS", "Hostname": "nms.example.com", "Model": "Concerto NMS 5.2", "Category": [ "SIEM.NMS" ], "Data": [ "Network" ], "Method": [ "Monitor" ], "IP": "192.0.2.1" }, "Target": [ { "IP": "192.168.1.2", "Hostname": "www.acme.com", "Service": "website", "Location": "Server room A1, rack 10" } ] } D.4. Combined incident Listing 4 describes a combined incident resulting from the correlation of the previous physical, cyber and availability incidents. Lehmann & Andrejak Expires 27 April 2027 [Page 156] Internet-Draft IDMEFv2 October 2026 { "Version": "2.D.V07", "ID": "819df7bc-35ef-40d8-bbee-1901117370b4", "Description": "Intrusion and Sabotage detected", "Type": "Combined", "Priority": "High", "Status": "Incident", "Cause": "Malicious", "CreateTime": "2021-05-10T16:59:15.075994+00:00", "StartTime": "2021-05-10T16:52:11+00:00", "Category": [ "Access.Unauthorized", "Sabotage.Data", , "CorrelID": [ "819df7bc-35ef-40d8-bbee-1901117370b1", "819df7bc-35ef-40d8-bbee-1901117370b2", "819df7bc-35ef-40d8-bbee-1901117370b3" ], "Analyzer": { "Name": "Correlator", "Hostname": "correlator.acme.com", "Model": "Concerto Hybrid Correlator v5.2", "Category": [ ], "Data": [ "Alert" ], "Method": [ "Correlation" ], "IP": "192.0.2.1" }, "Source": [ { "Note": "Black Organization, aka. APT 4869" } ], "Target": [ { "Location": "Server room A1" }, { "IP": "192.0.2.2", "Hostname": "www.acme.com", "User": "root" }, { Lehmann & Andrejak Expires 27 April 2027 [Page 157] Internet-Draft IDMEFv2 October 2026 "IP": "192.0.2.2", "Hostname": "www.acme.com", "Service": "website" } ] } D.5. Hazard incident Listing 5 describes a heavy snow storm announced in 48h on Paris and Versailles. Lehmann & Andrejak Expires 27 April 2027 [Page 158] Internet-Draft IDMEFv2 October 2026 { "Version": "2.D.V07", "ID": "819df7bc-35ef-40d8-bbee-1901117370b1", "Description": "Snow storm forecast", "Priority": "Low", "Status": "Incident", "Cause": "Hazard", "Confidence": 0.8, "CreateTime": "2021-05-10T16:52:13.075994+00:00", "StartTime": "2021-05-12T10:00:00+00:00", "EndTime": "2021-05-12T10:00:00+00:00", "Type": ["Physical"], "Category": [ "Meteo.Snow", "Meteo.Wind", "Meteo.Cold" ], "Analyzer": { "Name": "Weather Monitor", "Hostname": "weather.acme.com", "IP": "192.0.2.1" }, "Source": [ { "Note": "Heavy snow storm coming from North" } ], "Target": [ { "GeoLocation": "48.8584,2.2945", "UnLocation": "FR PAR", "Location": "Acme Paris Site" }, { "GeoLocation": "48.8019,2.1301", "UnLocation": "FR VER", "Location": "Acme Versailles Site" } ] } Appendix E. JSON Validation Schema (Non-normative) Listing 5 contains a JSON Schema that can be used to validate incoming IDMEF messages prior to processing. Please note that extraneous linebreaks have been included due to formatting constraints. Lehmann & Andrejak Expires 27 April 2027 [Page 159] Internet-Draft IDMEFv2 October 2026 { "description": "JSON schema for the Intrusion Detection Message Exchange Format (IDMEF) version 2 (revision 2.D.V09)", "properties": { "Version": { "description": "The version of the IDMEF format in use by this alert. During the drafts tuning period the version is equal to the draft version. Therefore it is \"2.D.V0X\" for Draft V0X.", "enum": [ "2.D.V09" ] }, "ID": { "description": "Unique identifier for the alert.", "$ref": "#/definitions/uuidType" }, "OrganisationName": { "description": "Corporate/Main Office Organisation Name Useful if alerts are sent to a multi-organisation central incident detection manager. Example: ACME Corporation", "type": "string" }, "OrganisationId": { "description": "Corporate/Main Office Organisation ID. Where possible official organisation ID manage by national authority. Useful if alerts are sent to a multi-organisation central incident detection manager. This ID has to be chosen depending on the overall detection perimeter and the nature of the monitored organisation (Private/Public, Commercial, International, etc.) Examples: OrganisationId in France could be SIREN, in England could be CR, Germany could be Handelsregisternummer, Spain could be CIF, Italia could be Partita IVA, USA could be EIN, etc. Commercial OrganisationId in Europe could be V.A.T ID", "type": "string" }, "EntityName": { "description": "Entity Name, monitored by the organisation, where the incident occurred. Could be a town, region or country name or an internal name. Could also be the name of a customer for a MSSP centralizing it's customer incidents in a single system. Do not repeat the organisation name in the EntityName Example: - ACME HeadQuaters is located in Paris France and has a local office in India - If the incident occurred in the local office: \"OrganisationName\": \"ACME\" , \"EntityName\": \"India\" - If the incident occurred in the headquaters: \"OrganisationName\": \"ACME\", \"EntityName\": \"Headquaters\" (or \"Paris\")", "type": "string" }, "EntityId": { "description": "Entity ID, monitored by the organisation, where the incident occurred. Useful if organisation and entity are not directly linked, like a customer and a MSSP.", "type": "string" }, "EntitySector": { "description": "The economic sector(s) and sub-sector(s) in which the entity operates. Values follow the dot notation sector.subsector based on the critical infrastructure taxonomy defined in the NIS2 Directive and CER (Critical Entities Resilience) Directive. This attribute enables sector-based correlation, regulatory compliance reporting, and risk context for incident detection.", "type": "array", "items": { "$ref": "#/definitions/entitysectorEnum" } }, "Type": { "description": "Incident type.", "type": "array", "items": { "$ref": "#/definitions/typeEnum" } }, "Category": { "description": "Incident category.", "type": "array", "items": { "$ref": "#/definitions/categoryEnum" Lehmann & Andrejak Expires 27 April 2027 [Page 160] Internet-Draft IDMEFv2 October 2026 } }, "ext-Category": { "description": "A means by which to extend the Category attribute. (see )", "type": "array", "items": { "type": "string" } }, "Cause": { "description": "Incident cause. The cause can be modified by any analyzer on the way of the alert and later by the operator and/or the analyst if new investigation reveals and confirms a different cause of the event.", "$ref": "#/definitions/causeEnum" }, "Description": { "description": "Short free text human-readable description of the event. The description can add detail to the event category for easiest/faster comprehension by the operator. Example : * Cryptoware WannaCry blocked on pegasus server * Unknown person entering through east doorway", "type": "string" }, "Status": { "description": "Event state in the overall event lifecycle.", "type": "array", "items": { "$ref": "#/definitions/statusEnum" } }, "Priority": { "description": "Priority of the alert. Priority is defined by combining impact and urgency. It indicates how fast the incident should be taken care of.", "$ref": "#/definitions/priorityEnum" }, "Confidence": { "description": "A floating-point value between 0 and 1 indicating the analyzer's confidence in its own reliability of this particular detection, where 0 means that the detection is surely incorrect while 1 means there is no doubt about the detection made.", "type": "number", "minimum": 0, "maximum": 1 }, "Note": { "description": "Free text human-readable additional note, possibly a longer description of the incident if is not already obvious. The Note attribute can be used to store any additional information. It can be additional information about the event and/or about the incident resolution, although the incident resolution information should in principle be stored elsewhere (with a link with the external tool in AltNames)", "type": "string" }, "CreateTime": { "description": "Timestamp indicating when the alert was created.", "$ref": "#/definitions/timestampType" }, "StartTime": { "description": "Timestamp indicating the deduced start of the event. StartTime can be later than CreateTime in case or Alerts created from forecast information (e.g. Snow Storm expected in two days staring at 10h00)", "$ref": "#/definitions/timestampType" }, "EndTime": { "description": "Timestamp indicating the deduced end of the event.", Lehmann & Andrejak Expires 27 April 2027 [Page 161] Internet-Draft IDMEFv2 October 2026 "$ref": "#/definitions/timestampType" }, "ReportTime": { "description": "Timestamp indicating the reporting time of the event, usually to an external CSIRT or a central SIEM.", "$ref": "#/definitions/timestampType" }, "AltNames": { "description": "Alternative identifiers; strings which help pair the event to internal systems' information (for example ticket IDs inside a request tracking systems).", "type": "array", "items": { "type": "string" } }, "AltCategory": { "description": "Alternate categories from a reference other than IDMEFv2 categories (e.g. MISP, MITRE ATT@CK or another proprietary/internal reference).", "type": "array", "items": { "type": "string" } }, "Ref": { "description": "References to sources of information related to the incident and/or vulnerability, and specific to this incident. This MAY be a URL to additional info, or a URN in a registered or unregistered ad-hoc namespace bearing reasonable information value and uniqueness, such as \"urn:cve:CVE-2013-2266\".", "type": "array", "items": { "type": "string", "format": "uri" } }, "CorrelID": { "description": "Identifiers for the messages which were used as information sources to create this message, in case the message has been created based on correlation/analysis/deduction from other messages.", "type": "array", "items": { "$ref": "#/definitions/uuidType" } }, "AggrCondition": { "description": "A list of IDMEF fields used to aggregate events. The values for these fields will be the same in all aggregated events. This attribute should mostly be set by intermediary nodes, which detect duplicates, or aggregate events, spanning multiple detection windows, into a longer one. The \"StartTime\" and \"EndTime\" attributes are used in conjunction with this attribute to describe the aggregation window.", "type": "array", "items": { "type": "string" } }, "PredID": { "description": "A list containing the identifiers of previous messages which are obsoleted by this message. The obsoleted alerts SHOULD NOT be used anymore. This field can be used to \"update\" an alert.", "type": "array", "items": { "$ref": "#/definitions/uuidType" } Lehmann & Andrejak Expires 27 April 2027 [Page 162] Internet-Draft IDMEFv2 October 2026 }, "RelID": { "description": "A list containing the identifiers of other messages related to this message.", "type": "array", "items": { "$ref": "#/definitions/uuidType" } }, "SignedAttributes": { "description": "List of IDMEFv2 paths of the attributes included in the signature.", "type": "array", "items": { "type": "string" } }, "Signature": { "description": "JWS Compact Serialization string containing the signature.", "type": "string" }, "Analyzer": { "type": "object", "description": "The Analyzer class describes the module that has analyzed the data captured by the sensors, identified an event of interest and decided to create an alert.", "properties": { "ID": { "description": "Unique identifier for the analyzer.", "$ref": "#/definitions/uuidType" }, "IP": { "description": "Analyzer IP address.", "$ref": "#/definitions/ipType" }, "Name": { "description": "Name of the analyzer, which must be reasonably unique, however still bear some meaningful sense. This attribute usually denotes the hierarchy of organizational units the detector belongs to and its own name. It MAY also be used to distinguish multiple analyzers running with the same IP address.", "type": "string" }, "Hostname": { "description": "Hostname of this analyzer. SHOULD be a fully-qualified domain name.", "type": "string" }, "Model": { "description": "Analyzer model description (usually its generic name, brand and version).", "type": "string" }, "Category": { "description": "Analyzer categories.", "type": "array", "items": { "$ref": "#/definitions/analyzerCategoryEnum" Lehmann & Andrejak Expires 27 April 2027 [Page 163] Internet-Draft IDMEFv2 October 2026 } }, "ext-Category": { "description": "A means by which to extend the Category attribute. (see )", "type": "array", "items": { "type": "string" } }, "Data": { "description": "Type of data analyzed during the detection.", "type": "array", "items": { "$ref": "#/definitions/analyzerDataEnum" } }, "ext-Data": { "description": "A means by which to extend the Data attribute. (see )", "type": "array", "items": { "type": "string" } }, "Method": { "description": "Detection method.", "type": "array", "items": { "$ref": "#/definitions/analyzerMethodEnum" } }, "ext-Method": { "description": "A means by which to extend the Method attribute. (see )", "type": "array", "items": { "type": "string" } }, "GeoLocation": { "description": "GPS coordinates for the analyzer.", "$ref": "#/definitions/geolocType" }, "UnLocation": { "description": "Standard UN/Locode for the analyzer.", "$ref": "#/definitions/unlocodeType" }, "Location": { "description": "Internal name for the location of the analyzer.", "type": "string" Lehmann & Andrejak Expires 27 April 2027 [Page 164] Internet-Draft IDMEFv2 October 2026 }, "Locator": { "description": "Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path.", "type": "string" }, "CaptureZone": { "description": "A string that describes the \"capture zone\" of the analyzer (if the analyzer is also a sensor), as a JSON-serialized string. Depending on the type of sensor, the capture zone may for instance refer to: A JSON object describing a camera's settings (elevation, horizontal and vertical field of view, azimuth, etc.) A description of the IP network where packet capture is taking place.", "type": "string" } }, "additionalProperties": false }, "Sensor": { "type": "array", "items": { "description": "The Sensor class describes the module that captured the data before sending it to an analyzer. The Sensor may be a subpart of the Analyzer.", "properties": { "ID": { "description": "Unique identifier for the sensor.", "$ref": "#/definitions/uuidType" }, "IP": { "description": "The sensor's IP address.", "$ref": "#/definitions/ipType" }, "Name": { "description": "Name of the sensor, which must be reasonably unique, however still bear some meaningful sense. This attribute usually denotes the hierarchy of organizational units the sensor belongs to and its own name. It MAY also be used to distinguish multiple sensors running with the same IP address.", "type": "string" }, "Hostname": { "description": "The sensor's hostname. This SHOULD be a fully qualified domain name, but may not conform exactly because values extracted from logs, messages, DNS, etc. may themselves be malformed. An empty string MAY be used to explicitly state that this value was inquired but not found (missing DNS entry).", "type": "string" }, "Model": { "description": "The sensor model's description (usually its generic name, brand and version).", "type": "string" }, "Data": { "description": "Type of data captured by the sensor.", "type": "array", "items": { "$ref": "#/definitions/sensorDataEnum" } }, "ext-Data": { "description": "A means by which to extend the Data attribute. (see )", "type": "array", "items": { Lehmann & Andrejak Expires 27 April 2027 [Page 165] Internet-Draft IDMEFv2 October 2026 "type": "string" } }, "GeoLocation": { "description": "GPS coordinates for the analyzer.", "$ref": "#/definitions/geolocType" }, "UnLocation": { "description": "Standard UN/Locode for the sensor.", "$ref": "#/definitions/unlocodeType" }, "Location": { "description": "Internal name for the location of the sensor.", "type": "string" }, "Locator": { "description": "Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path.", "type": "string" }, "CaptureZone": { "description": "A string that describes the \"capture zone\" of the sensor, as a JSON-serialized string. Depending on the type of sensor, the capture zone may for instance refer to: \n- A JSON object describing a camera's settings (elevation, horizontal and vertical field of view, azimuth, etc.)\n- A description of the IP network where packet capture is taking place.", "type": "string" } }, "additionalProperties": false, "type": "object" } }, "Source": { "type": "array", "items": { "description": "The Source class describes the origin(s) of the event(s) leading up to the creation of this alert.", "properties": { "ID": { "description": "Unique identifier for the source.", "$ref": "#/definitions/uuidType" }, "IP": { "description": "Source IP address.", "$ref": "#/definitions/ipType" }, "Hostname": { "description": "Hostname of this source. This SHOULD be a fully qualified domain name, but may not conform exactly because values extracted from logs, messages, DNS, etc. may themselves be malformed. An empty string MAY be used to explicitly state that this value was inquired but not found (missing DNS entry).", "type": "string" }, "Name": { "description": "Name of this source. Naming the source might be necessary for non digital source like a human, a vehicle, a drone, etc.", "type": "string" Lehmann & Andrejak Expires 27 April 2027 [Page 166] Internet-Draft IDMEFv2 October 2026 }, "Category": { "description": "Source category", "type": "array", "items": { "$ref": "#/definitions/sourceCategoryEnum" } }, "Note": { "description": "Free text human-readable additional note for this source.", "type": "string" }, "TI": { "description": "Threat Intelligence data about the source. Values in this list MUST use the format \"attribute:origin\", where \"attribute\" refers to the attribute inside this source found inside a Threat Intelligence database, and \"origin\" contains a short identifier for the Threat Intelligence database. E.g. \"IP:Dshield\". Please note that the same attribute may appear multiple times inside the list (because a match was found in multiple Threat Intelligence databases).", "type": "array", "items": { "type": "string" } }, "User": { "description": "User ID or login responsible for the incident.", "type": "string" }, "Email": { "description": "Email address responsible for the incident. E.g. the value of the \"Reply-To\" or \"From\" header inside a phishing e-mail.", "type": "string", "format": "email" }, "Protocol": { "description": "Protocols related to connections from/to this source. If several protocols are stacked, they MUST be ordered from the lowest (the closest to the medium) to the highest (the closest to the application) according to the ISO/OSI model.", "type": "array", "items": { "$ref": "#/definitions/protocolType" } }, "Port": { "description": "Source ports involved in the incident. Values in this list MUST be integers and MUST be in the range 1-65535.", "type": "array", "items": { "type": "integer" } }, "GeoLocation": { "description": "GPS coordinates for the source.", "$ref": "#/definitions/geolocType" }, "UnLocation": { "description": "Standard UN/Locode for the source.", Lehmann & Andrejak Expires 27 April 2027 [Page 167] Internet-Draft IDMEFv2 October 2026 "$ref": "#/definitions/unlocodeType" }, "Location": { "description": "Internal name for the location of the source.", "type": "string" }, "Locator": { "description": "Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path.", "type": "string" }, "Attachment": { "description": "Identifiers for attachments related to this source. Each identifier listed here MUST match the \"Name\" attribute for one of the attachments described using the Attachment class .", "type": "array", "items": { "$ref": "#/definitions/attachmentNameType" } } }, "additionalProperties": false, "type": "object" } }, "Target": { "type": "array", "items": { "description": "The Target class describes the target(s) impacted by the event(s) leading up to the creation of this alert.", "properties": { "ID": { "description": "Unique identifier for the target.", "$ref": "#/definitions/uuidType" }, "IP": { "description": "Target IP address.", "$ref": "#/definitions/ipType" }, "Hostname": { "description": "Hostname of this target. This SHOULD be a fully qualified domain name, but may not conform exactly because values extracted from logs, messages, DNS, etc. may themselves be malformed. An empty string MAY be used to explicitly state that this value was inquired but not found (missing DNS entry).", "type": "string" }, "Name": { "description": "Name of this target. Naming the target might be necessary for non digital targets like a human, a vehicle, a building, etc.", "type": "string" }, "Category": { "description": "Target category", "type": "array", "items": { "$ref": "#/definitions/targetCategoryEnum" Lehmann & Andrejak Expires 27 April 2027 [Page 168] Internet-Draft IDMEFv2 October 2026 } }, "Note": { "description": "Free text human-readable additional note for this target.", "type": "string" }, "Service": { "description": "Should be High Level Service (messaging, internet, ...), if not defined can be process impacted by the incident.", "type": "string" }, "User": { "description": "User ID or login impacted by the incident.", "type": "string" }, "Email": { "description": "Email address impacted by the incident. E.g. the value of the \"To\" header inside a phishing e-mail.", "type": "string", "format": "email" }, "Port": { "description": "Target ports involved in the incident. Values in this list MUST be integers and MUST be in the range 1-65535.", "type": "array", "items": { "type": "integer" } }, "Polygon": { "description": "Pollygonal incident affected area. Whitespace-delimited list of WGS 84 'latitude,longitude' pairs. Minimum 4 pairs, first equals last", "type": "string" }, "Circle": { "description": "Circular incident infected area. WGS 84 center point 'latitude,longitude' followed by a space and radius in kilometers", "type": "string" }, "GeoLocation": { "description": "GPS coordinates for the target.", "$ref": "#/definitions/geolocType" }, "UnLocation": { "description": "Standard UN/Locode for the target.", "$ref": "#/definitions/unlocodeType" }, "Location": { "description": "Internal name for the location of the target.", "type": "string" }, "Locator": { "description": "Resolvable URL for the entity. May be dynamic or expire; complements Location, which is a persistent path.", Lehmann & Andrejak Expires 27 April 2027 [Page 169] Internet-Draft IDMEFv2 October 2026 "type": "string" }, "Attachment": { "description": "Identifiers for attachments related to this target. Each identifier listed here MUST match the \"Name\" attribute for one of the attachments described using the Attachment class .", "type": "array", "items": { "$ref": "#/definitions/attachmentNameType" } } }, "additionalProperties": false, "type": "object" } }, "Attachment": { "type": "array", "items": { "description": "The Attachment class contains additional data which was captured in relation with the event.", "properties": { "Name": { "description": "A unique identifier among attachments that can be used to reference this attachment from other classes using the \"Attachment\" attribute.", "$ref": "#/definitions/attachmentNameType" }, "FileName": { "description": "Attachment filename. This will usually be the original name of the captured file or the name of the file containing the captured content (e.g. a packet capture file).", "type": "string" }, "Hash": { "description": "A list of hash results for the attachment's Content. The values in this list are computed by taking the raw value of the attachment's \"Content\" attribute. The hash result is computed before any other transformation (e.g. Base64 encoding) is applied to the content, so that a receiving IDMEF system may reverse the transformation, apply the same hashing function and obtain the same hash result. See also the definition for the \"ContentEncoding\" attribute below. It is RECOMMENDED that compatible implementations use one of the hashing functions from the SHA-2 or SHA-3 families to compute the hash results in this list.", "type": "array", "items": { "$ref": "#/definitions/hashType" } }, "Size": { "description": "Length of the content (in bytes). This value MUST be a non-negative integer.", "type": "integer" }, "Ref": { "description": "References to sources of information related to the incident and/or vulnerability, and specific to this attachment.", "type": "array", "items": { "type": "string", "format": "uri" } }, "ExternalURI": { "description": "If the attachment's content is available and/or recognizable from an external resource, this is the URI (usually a URL) to that resource. This MAY also be a URN in a registered or unregistered ad-hoc namespace bearing reasonable information value and uniqueness, such as \"urn:mhr:55eaf7effadc07f866d1eaed9c64e7ee49fe081a\" or \"magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C\".", Lehmann & Andrejak Expires 27 April 2027 [Page 170] Internet-Draft IDMEFv2 October 2026 "type": "array", "items": { "type": "string", "format": "uri" } }, "Note": { "description": "Free text human-readable additional note for this attachment.", "type": "string" }, "ContentType": { "description": "Internet Media Type of the attachment. For compatibility reasons, implementations SHOULD prefer one of the well-known media types registered in IANA .", "$ref": "#/definitions/mediatypeType" }, "ContentEncoding": { "description": "Content encoding. The following encodings are defined in this version of the specification: \n- \"json\": The content refers to a JSON object which has been serialized to a string using the serialization procedure defined in .\n- \"base64\": The content has been serialized using the Base64 encoding defined in . The \"base64\" encoding SHOULD be used when the content contains binary data. If omitted, the \"json\" encoding MUST be assumed.", "type": "string" }, "Content": { "description": "The attachment's content, in case it is directly embedded inside the message. For large attachments, it is RECOMMENDED that implementations make use of the \"ExternalURI\" attribute to refererence a copy of the content saved in an external storage mechanism.", "type": [ "object", "string" ] } }, "additionalProperties": false, "type": "object", "required": [ "Name" ] } } }, "additionalProperties": false, "type": "object", "required": [ "Analyzer", "Version", "ID", "CreateTime" ], "definitions": { "entitysectorEnum": { "enum": [ "Undefined", "Administration.CentralGovernment", "Administration.Diplomatic", Lehmann & Andrejak Expires 27 April 2027 [Page 171] Internet-Draft IDMEFv2 October 2026 "Administration.EmergencyServices", "Administration.Judiciary", "Administration.Local", "Administration.Other", "Banking.Banking", "Banking.Other", "Cemeteries.Crematoria", "Cemeteries.Public", "Cemeteries.Other", "Chemical.Production", "Chemical.Storage", "Chemical.Other", "Civil.ElectionMonitoring", "Civil.HumanitarianAid", "Civil.NGOs", "Civil.Other", "Cultural.Archives", "Cultural.HistoricalSites", "Cultural.Libraries", "Cultural.Museums", "Cultural.Other", "Defense.CommandControl", "Defense.Cyber", "Defense.IndustrialBase", "Defense.Logistics", "Defense.Installations", "Defense.Research", "Defense.Other", "Digital.CloudServices", "Digital.DataCenters", "Digital.DigitalProviders", "Digital.DomainNameSystems", "Digital.ICTServiceManagement", "Digital.SatelliteCommunications", "Digital.TelecomNetworks", "Digital.UnderseaCables", "Digital.Other", "Education.PrimarySecondary", "Education.ResearchSchools", "Education.Universities", "Education.Other", "Emergency.CivilProtection", "Emergency.Medical", "Emergency.FireAndRescue", "Emergency.Police", "Emergency.Other", "Energy.DistrictHeating", "Energy.Electricity", Lehmann & Andrejak Expires 27 April 2027 [Page 172] Internet-Draft IDMEFv2 October 2026 "Energy.Gas", "Energy.Hydrogen", "Energy.Nuclear", "Energy.Oil", "Energy.Other", "Finance.MarketInfrastructures", "Finance.Insurance", "Finance.PaymentSystems", "Finance.Other", "Food.AgriculturalProduction", "Food.FoodDistribution", "Food.FoodProcessing", "Food.FoodSafety", "Food.Other", "Health.BloodAndTissue", "Health.HealthcareProviders", "Health.Laboratories", "Health.MedicalDevices", "Health.PharmaceuticalSupplyChain", "Health.PublicHealth", "Health.Other", "Logistics.FreightForwarding", "Logistics.LastMileDelivery", "Logistics.ThirdPartyLogistics", "Logistics.Warehousing", "Logistics.Other", "Manufacturing.Aerospace", "Manufacturing.Batteries", "Manufacturing.Chemical", "Manufacturing.Electronic", "Manufacturing.Defense", "Manufacturing.MedicalDevices", "Manufacturing.MotorVehicles", "Manufacturing.Pharmaceutical", "Manufacturing.Semiconductors", "Manufacturing.Strategic", "Manufacturing.Other", "Media.Infrastructure", "Media.OnlineMedia", "Media.Press", "Media.Radio", "Media.Television", "Media.Other", "Mining.CriticalRawMaterials", "Mining.EnergyMinerals", "Mining.Other", "Nuclear.FuelCycle", "Nuclear.Medical", Lehmann & Andrejak Expires 27 April 2027 [Page 173] Internet-Draft IDMEFv2 October 2026 "Nuclear.PowerGeneration", "Nuclear.Research", "Nuclear.Other", "Postal.CourierServices", "Postal.Other", "Religious.PilgrimageSites", "Religious.PlacesOfWorship", "Religious.Other", "Research.BiologicalSafety", "Research.ChemicalSafety", "Research.Research", "Research.Other", "Space.GroundStations", "Space.LaunchFacilities", "Space.SpaceActivities", "Space.Other", "Transport.Aviation", "Transport.Maritime", "Transport.Pipeline", "Transport.PublicTransport", "Transport.Rail", "Transport.Road", "Transport.Other", "Waste.Hazardous", "Waste.NonHazardous", "Waste.Nuclear", "Waste.Recycling", "Waste.Other", "Water.DamsAndReservoirs", "Water.DrinkingWater", "Water.Irrigation", "Water.Wastewater", "Water.Other" ], "description": "Possible alert entitysector" }, "typeEnum": { "enum": [ "Cyber", "Physical", "Availability", "Hazards", "Combined" ], "description": "Possible alert type" }, "categoryEnum": { "enum": [ Lehmann & Andrejak Expires 27 April 2027 [Page 174] Internet-Draft IDMEFv2 October 2026 "Abuse.Coercion", "Abuse.Extremism", "Abuse.Grooming", "Abuse.Harassment", "Abuse.Trafficking", "Abuse.Other", "Access.Authorized", "Access.Backdoor", "Access.Cloned", "Access.Compromise", "Access.Escalation", "Access.Expired", "Access.Forced", "Access.Lost", "Access.Tailgating", "Access.Unauthorized", "Access.Other", "Anomaly.Burst", "Anomaly.Chaos", "Anomaly.Context", "Anomaly.Correlation", "Anomaly.Deviation", "Anomaly.Drift", "Anomaly.Oscillation", "Anomaly.Relation", "Anomaly.Sequence", "Anomaly.Threshold", "Anomaly.Timing", "Anomaly.Unknown", "Anomaly.Other", "Availability.DDoS", "Availability.DoS", "Availability.Failure", "Availability.Flapping", "Availability.Heartbeat", "Availability.Misconfiguration", "Availability.Outage", "Availability.Overload", "Availability.Recovery", "Availability.Restart", "Availability.Start", "Availability.Status", "Availability.Stop", "Availability.Other", "Biological.Animal", "Biological.Epidemic", "Biological.Insect", "Biological.Zombies", Lehmann & Andrejak Expires 27 April 2027 [Page 175] Internet-Draft IDMEFv2 October 2026 "Biological.Other", "Climate.Drought", "Climate.LakeOutburst", "Climate.Wildfire", "Climate.Other", "Extraterrestrial.Aliens", "Extraterrestrial.Impact", "Extraterrestrial.SpaceWeather", "Extraterrestrial.Other", "Fraud.Copyright", "Fraud.Corruption", "Fraud.Espionage", "Fraud.Masquerade", "Fraud.Usage", "Fraud.Other", "Geophysical.Earthquake", "Geophysical.MassMovement", "Geophysical.Other", "Geophysical.Volcanic", "Hydro.Flood", "Hydro.Landslide", "Hydro.Wave", "Hydro.Other", "Insider.Malicious", "Insider.Negligent", "Insider.Other", "Malware.Adware", "Malware.Backdoor", "Malware.ResourceHijacking", "Malware.Downloader", "Malware.Ransomware", "Malware.Rootkit", "Malware.Spyware", "Malware.Trojan", "Malware.Virus", "Malware.Worm", "Malware.Other", "Meteo.Cold", "Meteo.Fog", "Meteo.Heat", "Meteo.Rain", "Meteo.Snow", "Meteo.Wind", "Meteo.Other", "National.Conflict", "National.Crime", "National.Cyber", "National.Economic", Lehmann & Andrejak Expires 27 April 2027 [Page 176] Internet-Draft IDMEFv2 October 2026 "National.Environmental", "National.Societal", "National.Terrorism", "National.Other", "Operational.Configuration", "Operational.Misuse", "Operational.PolicyViolation", "Operational.ProcessFailure", "Operational.Update", "Operational.Other", "Recon.Aerial", "Recon.Landscape", "Recon.Network", "Recon.OSINT", "Recon.Other", "Sabotage.Data", "Sabotage.Destruction", "Sabotage.Disruption", "Sabotage.Equipment", "Sabotage.Graffiti", "Sabotage.Tampering", "Sabotage.Vandalism", "Sabotage.Other", "Safety.Accident", "Safety.Aggression", "Safety.Explosion" ], "description": "Possible alert category" }, "causeEnum": { "enum": [ "Normal", "Error", "Malicious", "Malfunction", "Hazard", "Unknown" ], "description": "Possible alert cause" }, "statusEnum": { "enum": [ "Event", "Incident", "Open", "Closed", "FalsePositive", "Obsolete" Lehmann & Andrejak Expires 27 April 2027 [Page 177] Internet-Draft IDMEFv2 October 2026 ], "description": "Possible alert status" }, "priorityEnum": { "enum": [ "Unknown", "Info", "Low", "Medium", "High", "Critical" ], "description": "Possible alert priority" }, "analyzerCategoryEnum": { "enum": [ "Undetermined", "APP.BAST", "APP.DAST", "APP.IAST", "APP.RASP", "APP.SANDBOX", "APP.SAST", "APP.SCA", "CLD.CASB", "CLD.CIEM", "CLD.CSPM", "CLD.CWPP", "DDoS.ANTI-DDOS", "DDoS.SCRUB", "DDoS.WAF-DDOS", "EMAIL.ANTI-PHISH", "EMAIL.DMARC", "EMAIL.SEG", "EMAIL.SPAM-FILTER", "END.AM", "END.AV", "END.DLP-EP", "END.EDR", "END.EPP", "END.HIDS", "END.HIPS", "END.HPT", "HUM.REPORT", "ID.DCAP", "ID.DLP", "ID.IAM", "ID.IRM", Lehmann & Andrejak Expires 27 April 2027 [Page 178] Internet-Draft IDMEFv2 October 2026 "ID.MFA", "ID.PAM", "ID.PIM", "ID.SECRETS", "ID.UEBA", "NAT.AIR", "NAT.FIRE", "NAT.HYDRO", "NAT.METEO", "NAT.RADIO", "NAT.SAT", "NAT.SEISMO", "NET.DNS-FW", "NET.DPI", "NET.FW", "NET.NAC", "NET.NBAD", "NET.NDR", "NET.NGFW", "NET.NIDS", "NET.NIPS", "NET.PROXY", "NET.WAF", "NET.WIDS", "NET.WIPS", "OT.IOT-IDS", "OT.OT-IDS", "OT.PLC-SCAN", "OT.SCADA", "OT.SENSOR", "PHY.1D-LAS", "PHY.2D-LAS", "PHY.3D-LAS", "PHY.ACCESS-CTRL", "PHY.ADS", "PHY.CBRN", "PHY.FIRE", "PHY.FR-CAM", "PHY.GAS", "PHY.GLASS-BRK", "PHY.HAR", "PHY.LWIR", "PHY.MOT-SEN", "PHY.MWIR", "PHY.OBJ-DET", "PHY.PERIMETER", "PHY.RADAR", "PHY.SMOKE", Lehmann & Andrejak Expires 27 April 2027 [Page 179] Internet-Draft IDMEFv2 October 2026 "PHY.SWIR", "PHY.VAD", "PHY.VNIR", "PHY.WATER", "SIEM.APM", "SIEM.ETL", "SIEM.LOG", "SIEM.NMS", "SIEM.SIEM", "SIEM.SOAR", "SIEM.UPTIME", "TI.CTI", "TI.TI-FEED", "TI.TIP", "VM.ASM", "VM.PENTEST", "VM.VULN-SCANNER", "ext-value" ], "description": "Possible analyzer category" }, "analyzerDataEnum": { "enum": [ "Undetermined", "Acoustics", "Alert", "Contact", "Content", "Data", "Datagram", "External", "File", "Flow", "Fog", "Humidity", "Images", "Lidar", "Light", "Log", "Magnetic", "Particles", "PCAP", "Rain", "Seismic", "SNMP", "Temperature", "Thermal", "Vibration", Lehmann & Andrejak Expires 27 April 2027 [Page 180] Internet-Draft IDMEFv2 October 2026 "Water", "ext-value" ], "description": "Possible analyzer data" }, "analyzerMethodEnum": { "enum": [ "Undetermined", "AI", "Anomaly", "Behavioral", "Biometric", "Blackhole", "Contextual", "Correlation", "Ensemble", "Fingerprinting", "Frequency", "Fusion", "Geolocation", "Graph-based", "Heat", "Heuristic", "Honeypot", "Hygiene", "Integrity", "Metadata", "Monitor", "Movement", "Orchestration", "Pattern", "Policy", "Predictive", "Protocol", "Recon", "Reputation", "Rule-based", "Sequence", "Signature", "Statistical", "Tarpit", "Threat Intelligence", "Threshold", "Trend", "ext-value" ], "description": "Possible analyzer method" }, Lehmann & Andrejak Expires 27 April 2027 [Page 181] Internet-Draft IDMEFv2 October 2026 "sourceCategoryEnum": { "enum": [ "Undetermined", "Acoustic.Sound.GlassBreak", "Acoustic.Sound.Infrasound", "Acoustic.Sound.PressurizedLeak", "Acoustic.Sound.SonarEcho", "Acoustic.Sound.UltrasonicNoise", "Acoustic.Vibration.Footstep", "Acoustic.Vibration.Seismic", "Acoustic.Vibration.StructuralCrack", "Acoustic.Vibration.VehicleVibe", "Acoustic.Vibration.VibAnalysis", "ChemBio.Gases.CO", "ChemBio.Gases.CWA", "ChemBio.Gases.Freon", "ChemBio.Gases.Hydrogen", "ChemBio.Gases.Methane", "ChemBio.Gases.O2Level", "ChemBio.Gases.Propane", "ChemBio.Gases.Radon", "ChemBio.Gases.VOC", "ChemBio.Properties.ORP", "ChemBio.Properties.pHLevel", "ChemBio.Properties.Salinity", "ChemBio.Threats.Anthrax", "ChemBio.Threats.Botulinum", "ChemBio.Threats.Pathogen", "ChemBio.Threats.Ricin", "Cyber.Application.SQLQuery", "Cyber.Application.XSSPayload", "Cyber.Cloud.APIToken", "Cyber.Cloud.BucketName", "Cyber.Cloud.CloudResourceID", "Cyber.Cloud.OAuthApp", "Cyber.Email.EmailAuthResult", "Cyber.Email.MessageID", "Cyber.Email.RecipientEmail", "Cyber.Email.ReplyToEmail", "Cyber.Email.ReturnPath", "Cyber.Email.SenderEmail", "Cyber.Email.XOrigIP", "Cyber.Endpoint.CmdLine", "Cyber.Endpoint.DLL", "Cyber.Endpoint.FileHash", "Cyber.Endpoint.FilePath", "Cyber.Endpoint.MemoryArtifact", "Cyber.Endpoint.PID", Lehmann & Andrejak Expires 27 April 2027 [Page 182] Internet-Draft IDMEFv2 October 2026 "Cyber.Endpoint.ProcessName", "Cyber.Endpoint.RegistryKey", "Cyber.Endpoint.ScheduledTask", "Cyber.Endpoint.ServiceName", "Cyber.Forensics.NetFlow", "Cyber.Forensics.PacketPayload", "Cyber.Hardware.DeviceSerial", "Cyber.Hardware.USBDeviceID", "Cyber.Identity.LoginTimestamp", "Cyber.Identity.Username", "Cyber.Network.IPv4", "Cyber.Network.IPv6", "Cyber.Network.MAC", "Cyber.Network.Port", "Cyber.Network.Protocol", "Cyber.Web.Domain", "Cyber.Web.HTTPMethod", "Cyber.Web.ReferrerHeader", "Cyber.Web.SessionID", "Cyber.Web.URIPath", "Cyber.Web.URL", "Cyber.Web.UserAgent", "ElectroMag.Infrared.GasLeakIR", "ElectroMag.Infrared.HeatTemp", "ElectroMag.Infrared.MoistureContent", "ElectroMag.Infrared.ThermalGradient", "ElectroMag.Infrared.WarmBody", "ElectroMag.Ultraviolet.BioContamUV", "ElectroMag.Ultraviolet.CoronaArc", "ElectroMag.Ultraviolet.FlameUV", "ElectroMag.Ultraviolet.ForgeryUV", "ElectroMag.Light.BiometricEye", "ElectroMag.Light.EdgesShapes", "ElectroMag.Light.Flicker", "ElectroMag.Light.LightColor", "ElectroMag.Light.LightPresence", "ElectroMag.Light.MotionOptical", "ElectroMag.Light.ObjectsGeneric", "Force.Atmospheric.Altitude", "Force.Atmospheric.BaroPress", "Force.Atmospheric.VacuumLevel", "Force.Fluid.Airflow", "Force.Fluid.WaterPressure", "Force.Touch.GripStrength", "Force.Touch.PhysicalContact", "Force.Touch.TirePressure", "Force.Touch.Weight", "Radiation.General.Alpha", Lehmann & Andrejak Expires 27 April 2027 [Page 183] Internet-Draft IDMEFv2 October 2026 "Radiation.General.Beta", "Radiation.General.Cosmic", "Radiation.General.Gamma", "Radiation.General.Neutron", "Radiation.General.RadonDecay", "Radiation.General.Xray", "Magnetic.General.CurrentFlow", "Magnetic.General.ESD", "Magnetic.General.Ferrous", "Magnetic.General.MagneticAnomaly", "Magnetic.General.Orientation", "Magnetic.General.Powerline", "Magnetic.General.Voltage", "Object.Indoor.Container", "Object.Indoor.Document", "Object.Indoor.Electronics", "Object.Indoor.Furniture", "Object.Indoor.Weapon", "Object.LivingBeings.Animal", "Object.LivingBeings.BodyPose", "Object.LivingBeings.EyeGaze", "Object.LivingBeings.Face", "Object.LivingBeings.HandGesture", "Object.LivingBeings.Human", "Object.Outdoor.Building", "Object.Outdoor.Pothole", "Object.Outdoor.RoadSign", "Object.Outdoor.Vegetation", "Object.SpecificScenes.FireVisual", "Object.SpecificScenes.Flood", "Object.SpecificScenes.SmokeVisual", "Object.SpecificScenes.Snow", "Object.Vehicles.Aircraft", "Object.Vehicles.Boat", "Object.Vehicles.Bus", "Object.Vehicles.Car", "Object.Vehicles.LicensePlate", "Object.Vehicles.Moto", "Object.Vehicles.Truck", "Particulate.Aerosols.Bioaerosol", "Particulate.Aerosols.Dust", "Particulate.Aerosols.Pollen", "Particulate.Aerosols.SmokeIonization", "Particulate.Aerosols.SmokePhotoelectric", "Particulate.Liquids.ChemicalSpill", "Particulate.Liquids.FuelSheen", "Particulate.Liquids.LiquidLevel", "Particulate.Liquids.WaterLeak", Lehmann & Andrejak Expires 27 April 2027 [Page 184] Internet-Draft IDMEFv2 October 2026 "Particulate.Solids.DensityChange", "Particulate.Solids.ForeignObject", "Particulate.Solids.GrainFlow", "Particulate.Solids.Landmine", "Particulate.Solids.Metal", "Software.Detected.Crowd", "Software.Detected.CyberAttack", "Software.Detected.Drowsiness", "Software.Detected.Explosion", "Software.Detected.FailedBiometric", "Software.Detected.FireFusion", "Software.Detected.Intrusion", "Software.Detected.Loitering", "Software.Detected.Tailgating", "ext-value" ], "description": "Possible source category" }, "targetCategoryEnum": { "enum": [ "Undetermined", "Commercial.ClientBase", "Commercial.Partnerships", "Commercial.Reputation", "Financial.Cash", "Financial.Investments", "Financial.Receivables", "Furniture.Fittings", "Furniture.HVAC", "Furniture.OfficeFurniture", "Human.EmployerBrand", "Human.Organization", "Human.Skills", "Infrastructure.CivilWorks", "Infrastructure.Foundations", "Infrastructure.Networks", "IP.Copyrights", "IP.Patents", "IP.Trademarks", "IT.Endpoints", "IT.Hardware", "IT.Telecom", "Logistics.Containers", "Logistics.SpecialVehicles", "Logistics.Vehicles", "Marketing.Content", "Marketing.Domains", "Marketing.Identity", Lehmann & Andrejak Expires 27 April 2027 [Page 185] Internet-Draft IDMEFv2 October 2026 "Production.HeavyEquipment", "Production.Machinery", "Production.MachineTools", "RealEstate.Buildings", "RealEstate.Land", "RealEstate.SpecialStructures", "Software.Applications", "Software.Data", "Software.Licenses", "ext-value" ], "description": "Possible target category" }, "attachmentNameType": { "description": "A a unique identifier among attachments.", "type": "string", "pattern": "^[a-zA-Z0-9]+$" }, "portType": { "description": "A network port number. The value 0 is excluded from the range because it never appears in an actual network connection.", "type": "integer", "minimum": 0, "maximum": 65535, "exclusiveMinimum": true }, "timestampType": { "description": "A JSON string containing a timestamp conforming to the format given in section 5.6 of RFC 3339.", "type": "string", "pattern": "^[0-9]{4}-(0[0-9]|1[012])-([0-2][0-9]|3[01])T([0-1][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\\.[0-9]+)?(Z|[-+]([0-1][0-9]|2[0-3]):[0-5][0-9])?$" }, "geolocType": { "description": "Geolocation coordinates. The format for this type matches the definition for locations inside ISO 6709 (eg. \"+48.75726, +2.299528, +65.1\").", "type": "string", "pattern": "^[-+]?([0-9]+(\\.[0-9]*)?)(, ?[-+]?([0-9]+(\\.[0-9]*)?)){1,2}$" }, "unlocodeType": { "description": "A valid UN/LOCODE location (e.g. \"FR PAR\"). See also the UN/LOCODE Code List 2020-2 at https://unece.org/trade/cefact/unlocode-code-list-country-and-territory.", "type": "string", "pattern": "^[A-Z]{2} ?[A-Z]{3}$" }, "ipType": { "description": "An Internet Protocol address, either version 4 or version 6.", "type": "string", "pattern": "^(((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)|([0-9a-fA-F]{1,4}:){7,7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:)|fe80:(:[0-9a-fA-F]{0,4}){0,4}%[0-9a-zA-Z]{1,}|::(ffff(:0{1,4}){0,1}:){0,1}((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])|([0-9a-fA-F]{1,4}:){1,4}:((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9]))$" }, "mediatypeType": { "description": "A valid media type (e.g. \"text/plain\") conforming to the format defined in section 3.1.1.1 of RFC 7231. See also http://www.iana.org/assignments/media-types/media-types.xhtml.", "type": "string", Lehmann & Andrejak Expires 27 April 2027 [Page 186] Internet-Draft IDMEFv2 October 2026 "pattern": "^[-!#$%&'*+.^_`|~0-9a-zA-Z]+/[-!#$%&'*+.^_`|~0-9a-zA-Z]+([ \t]*;[ \t]*[-!#$%&'*+.^_`|~0-9a-zA-Z]+=([-!#$%&'*+.^_`|~0-9a-zA-Z]+|\"([\\x5D-~\t !#-\\x5B]|\\\\([\t 0-9a-zA-Z]))*\"))*$" }, "uuidType": { "description": "Canonical textual representation for an UUID, as defined in RFC 4122 (e.g. \"e5f9bbae-163e-42f9-a2f2-0daaf78fefb1\")", "type": "string", "pattern": "^[0-9A-Fa-f]{8}(-[0-9A-Fa-f]{4}){3}-[0-9A-Fa-f]{12}$" }, "protocolType": { "description": "A JSON string containing a service or protocol name from the set of permitted values defined in the IANA \"Service Name and Transport Protocol Port Number\" registry (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml).", "type": "string", "pattern": "^[a-zA-Z0-9](-?[a-zA-Z0-9])*$" }, "hashType": { "description": "A cryptographic hash acting as a checksum for some content, using the format \"function:hex-value\" (e.g. \"md5:dc89f0b4ff9bd3b061dd66bb66c991b1\").", "type": "string", "pattern": "^[a-zA-Z0-9-]+:([a-fA-F0-9]{2})+$" } }, "$schema": "http://json-schema.org/draft-04/schema#", "title": "IDMEF 2.D.V09" } Authors' Addresses Gilles Lehmann Telecom SudParis France Email: gilles.lehmann@telecom-sudparis.eu Thomas Andrejak Bytes'n AI France Email: Thomas.Andrejak@gmail.com Lehmann & Andrejak Expires 27 April 2027 [Page 187]