RFC 4766
Intrusion Detection Message Exchange Requirements
RFC 4766: Intrusion Detection Message Exchange Requirements 🦋
Okay bestie, this is RFC 4766, and it's giving requirements doc 💅 It was written by M. Wood (Internet Security Systems, Inc.) and M. Erlinger (Harvey Mudd College), and it was published in March 2007 as part of the Network Working Group. It's Informational, which means it's sharing info for the internet community and does NOT set a standard. It doesn't list any RFCs it obsoletes or updates, so it's a solo-main-character situation 👑
Here's the map of what's coming up:
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Overview ........................................................4
2.1. Rationale for IDMEF ........................................4
2.2. Intrusion Detection Terms ..................................4
2.3. Architectural Assumptions ..................................8
2.4. Organization of This Document ..............................9
2.5. Document Impact on IDMEF Designs ..........................10
3. General Requirements ...........................................10
3.1. Use of Existing RFCs ......................................10
3.2. IPv4 and IPv6 .............................................10
4. Message Format Requirements ....................................11
4.1. Internationalization and Localization .....................11
4.2. Message Filtering and Aggregation .........................11
5. IDMEF Communication Protocol (IDP) Requirements ................12
5.1. Reliable Message Transmission .............................12
5.2. Interaction with Firewalls ................................12
5.3. Mutual Authentication .....................................13
5.4. Message Confidentiality ...................................13
5.5. Message Integrity .........................................13
5.6. Per-source Authentication .................................14
5.7. Denial of Service .........................................14
5.8. Message Duplication .......................................14
6. Message Content Requirements ...................................15
6.1. Detected Data .............................................15
6.2. Event Identity ............................................15
6.3. Event Background Information ..............................16
6.4. Additional Data ...........................................16
6.5. Event Source and Target Identity ..........................17
6.6. Device Address Types ......................................17
6.7. Event Impact ..............................................17
6.8. Automatic Response ........................................18
6.9. Analyzer Location .........................................18
6.10. Analyzer Identity ........................................19
6.11. Degree of Confidence .....................................19
6.12. Alert Identification .....................................19
6.13. Alert Creation Date and Time .............................20
6.14. Time Synchronization .....................................21
6.15. Time Format ..............................................21
6.16. Time Granularity and Accuracy ............................21
6.17. Message Extensions .......................................22
6.18. Message Semantics ........................................22
6.19. Message Extensibility ....................................22
7. Security Considerations ........................................23
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................23
9. Acknowledgements ...............................................23Status of This Memo ✨
This memo gives info to the internet community. It does NOT specify an internet standard of any kind. Distribution of this memo is unlimited 🌸
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007).
Abstract 💜
okay so the Intrusion Detection Exchange Format Working Group (IDWG) exists to define data formats and exchange procedures for sharing info that intrusion detection and response systems care about, plus the management systems that might need to talk to them 🫶 This doc lays out the high-level requirements for that communication mechanism, and explains the reasoning behind them wherever it needs clarifying. It also uses scenarios to illustrate some of the requirements, which is honestly my favorite part 🧚
1. Introduction 🦋
This doc lays out requirements for the Intrusion Detection Message Exchange Format (IDMEF) [5], which is a product of the Intrusion Detection Exchange Format Working Group (IDWG). IDMEF was planned to be a standard format that automated Intrusion Detection Systems (IDSs) [4] could use to report what they've decided is suspicious or interesting. This doc also specifies requirements for a communication protocol that carries IDMEF around 📬 As chartered, IDWG is responsible for first evaluating existing communication protocols before it chooses to specify a new one. So the requirements in this doc can be used to evaluate existing communication protocols. And if IDWG decides a new protocol is needed, these same requirements can be used to evaluate the proposed solutions 💅
1.1. Conventions Used in This Document
Heads up, this is not an IETF standards-track doc [2], so the key words MUST, MUST NOT, SHOULD, and MAY are NOT as in BCP 14, RFC 2119 [1]. Instead, here's what they mean here:
- MUST: This word, or the terms REQUIRED or SHALL, means that the described behavior or characteristic is an absolute requirement for a proposed IDWG specification. No wiggle room 😭
- MUST NOT: This phrase, or the phrase SHALL NOT, means that the described behavior or characteristic is an absolute prohibition of a proposed IDWG specification. Absolutely not, bestie 🙅♀️
- SHOULD: This word, or the adjective RECOMMENDED, means that there may exist valid reasons in particular circumstances for a proposed IDWG specification to ignore described behavior or characteristics. So it's a strong suggestion, not a hard rule 🍓
- MAY: This word, or the adjective OPTIONAL, means that the described behavior or characteristic is truly optional for a proposed IDWG specification. One proposed specification may choose to include the described behavior or characteristic, whereas another proposed specification may omit the same behavior or characteristic. Totally up to them ✨
2. Overview 🌈
2.1. Rationale for IDMEF
Okay, here's why a format like this would be super useful:
- There are a bunch of commercial and free Intrusion Detection Systems out there, and more keep showing up all the time 🔥 Some products are built to detect intrusions on the network, others focus on host operating systems, and others focus on applications. Even inside one category, the products have really different strengths and weaknesses. So it's likely that users will deploy more than one product, and they'll want to see the output of all of them from one or more managers. A standard format for reporting will make this way easier 🙌
- Intrusions often involve multiple organizations as victims, or multiple sites within the same organization. Those sites will typically use different IDSs. It would be super helpful to correlate these distributed intrusions across multiple sites and administrative domains, and having reports from every site in a common format would make that way easier 🕵️♀️
- A common format should make it easier to integrate components from different IDSs. That means Intrusion Detection (ID) research should move into commercial products more smoothly ✨
- Besides enabling communication from an ID analyzer to an ID manager, the IDMEF notification system may also enable communication between a variety of IDS components. For the rest of this doc, though, we'll talk about the communication as going from an analyzer to a manager 🧚
All of these reasons suggest that a common format for reporting anything deemed suspicious should help the IDS market grow and innovate more successfully. It should also get IDS users better results from deploying ID systems. Main character energy for the whole industry 👑
2.2. Intrusion Detection Terms
So the rest of the requirements make sense, we're defining some terms about typical IDSs first 💖 They're listed in alphabetical order. The diagram at the end of this section shows how some of the terms defined here relate to each other.
2.2.1. Activity
Activity is the stuff in the data source (or the things happening inside it) that the sensor or analyzer flags as interesting to the operator 👀 Examples include (but are not limited to) a network session showing unexpected telnet activity, operating system log file entries showing a user trying to access files he isn't authorized to access, application log files showing persistent login failures, etc.
Activity can go from super serious (like an unequivocally malicious attack) to less serious (like unusual user activity that's worth a second look) to totally neutral (like a user logging in) 🌸
2.2.2. Administrator
The Administrator is the human with overall responsibility for the organization's security policy, which means they're the one who makes decisions about deploying and configuring the IDS 🫶 This might or might not be the same person as the IDS operator. In some orgs the administrator is part of the network or systems administration groups. In other orgs, it's an independent position.
2.2.3. Alert
An alert is a message from an analyzer to a manager saying an event of interest has been detected 🚨 An alert typically contains info about the unusual activity that was detected, plus the specifics of what happened.
2.2.4. Analyzer
The analyzer is the ID component or process that goes through the data collected by the sensor, looking for signs of unauthorized or undesired activity, or for events that might interest the security administrator 🔍 In lots of existing IDSs, the sensor and the analyzer are part of the same component. In this doc, "analyzer" is used generically to mean the sender of the IDMEF message.
2.2.5. Data Source
The data source is the raw info an intrusion detection system uses to spot unauthorized or undesired activity 💜 Common data sources include (but are not limited to) raw network packets, operating system audit logs, application audit logs, and system-generated checksum data.
2.2.6. Event
An event is an occurrence in the data source that the sensor detects and that might result in an IDMEF alert being sent. For example, an attack 💥
2.2.7. IDS
IDS stands for intrusion detection system. It's some combination of one or more of these components: sensor, analyzer, manager 🧚
2.2.8. Manager
The manager is the ID component or process where the operator manages the various parts of the ID system 💅 Management functions typically include (but are not limited to) sensor configuration, analyzer configuration, event notification management, data consolidation, and reporting.
2.2.9. Notification
Okay so, notification is how the IDS manager tells the operator "hey, something happened!" 🚨 It's the moment the alert and the event actually reach a human's attention. In lots of IDSs, that's a colored icon popping up on the manager's screen 🎨, an e-mail or pager message 📟, or a Simple Network Management Protocol (SNMP) trap 🪤. Other notification techniques exist too, so don't think those three are the only options 💅
2.2.10. Operator
The operator is the human who mainly uses the IDS manager 🧑💻 They're usually the one watching what the ID system spits out, and they're the one who decides to take further action or suggests it. Main character energy, honestly 👑
2.2.11. Response
A response is whatever gets done after an event happens 🎬 Sometimes an entity inside the IDS architecture does it automatically, and sometimes a human starts it. Sending a notification to the operator is super common, but it's not the only move. Other responses include (but aren't limited to) logging the activity 📝, recording the raw data from the data source that made the event look suspicious 🗂️, ending a network, user, or application session 🚫, or changing network or system access controls 🔐
2.2.12. Sensor
The sensor is the ID component that collects data from the data source 👀 How often it collects data depends on which IDS product you're using, so it varies a lot. Once the sensor has its data, it's set up to forward events to the analyzer 📨
2.2.13. Signature
A signature is a rule the analyzer uses to spot activity that the security administrator would find interesting 🔍 Signatures are one way IDSs detect intrusions, but they aren't the only way. There are other mechanisms too 🌈
2.2.14. Security Policy
The Security Policy is the predefined, formally documented statement that spells out what activities are allowed on an organization's network or on particular hosts, so the organization's requirements get met 📜 It includes, but isn't limited to, which hosts are supposed to be blocked from external network access 🙅♀️
Here's the diagram that shows all these terms and how they connect to each other 🗺️ It's a lot, but it's worth it, I promise 🥹
________
| | --------
| Data |_________ ________| | __________
| Source | Activity |Sensor | | |
|________| | |________| | Operator |_______
| | |__________| |
\|/ Event A |
_____V___ | /|\ |
| | | \ |
| Sensor |__ | Notification |
|_________| Event | \ \|/
A | V_________ \ V
/|\ | | | \ Response
| --->| Analyzer|__ | A
| | | Alert | /|\
| |_________| | | |
| A | | |
| /|\ \|/ | |
|________________| ____V___ | |
| | |_| |
| | Manager|_________|
| |________|
| A
Security /|\
_______________ | Policy__________|
| | |
| Administrator |__|
|_______________|Not every IDS is going to have all of these pieces exactly like this 🤷♀️ Some IDSs squish several of these components into one single module, and some have multiple copies of these modules running around. Flexible is iconic 🦋
2.3. Architectural Assumptions
Okay, so here's the setup we're working with 🧸 We assume that an analyzer somehow figures out that a sensor has spotted something suspicious, and then it sends an alert over to a manager 📬 The format of that alert, plus how it gets sent, is exactly what IDMEF is trying to standardize. That's the whole point, bestie 🎯
For this document, we assume the analyzer and the manager are separate components, and they talk to each other in pairs over a TCP/IP network 🌐 We're not thinking about any other way these entities could communicate, and we're not thinking about any other use of IDMEF alerts either. The communication protocol that carries IDMEF is called the IDMEF Communication Protocol (IDP) 📦
The Trust Model isn't specified as a requirement. It's left up to whatever IDMEF Communication Protocol gets picked, so it's a design decision 🛠️ What we do specify are the individual security-related requirements, which you can find in Section 5 🔐
We try really hard not to make any other architectural assumptions beyond the ones we just listed 🙏 For example, these things should not matter:
- Whether the sensor and the analyzer are integrated or separate. 🧩
- Whether the analyzer and manager are isolated, or are embedded in some big hierarchy or distributed mesh of components. 🕸️
- Whether the manager actually notifies a human, takes action automatically, or just analyzes incoming alerts and correlates them. 🤖
- Whether a component might act as an analyzer with respect to one component, while also acting as a manager with respect to another. 🔄
2.4. Organization of This Document
Besides this requirements document, the IDWG should produce two other documents 📚 The first one should describe a data format or language for exchanging information about suspicious events. In this requirements document, we call that one the "data-format specification". The second document should identify existing IETF protocols that are best suited for carrying that formatted data, and explain how to package the data in those existing formats. Or, if that doesn't work out, the document should specify a brand new protocol instead 💫 We call this the IDP (IDMEF Communication Protocol).
So the requirements here are split into four sections 🍰
- The first one has general requirements that apply to all aspects of the IDMEF specification (Section 3). 🌟
- The second one describes requirements on how IDMEF messages are formatted (Section 4). 🎀
- The third one outlines requirements on the communications mechanism, IDP, which moves IDMEF messages from the analyzer to the manager (Section 5). 🚚
- The last one has requirements on the content and semantics of the IDMEF messages (Section 6). 💎
For each requirement, we try to state it as clearly as possible without deciding what the design solution should look like 🧠 Then we explain why the requirement matters, and we say whether it's an essential feature of the specification or something that's nice to have but could be missing if it's hard to pull off. Finally, when it seems helpful, we include an illustrative scenario. Sometimes those scenarios have possible design solutions in them, but those are only examples, not the one true answer 🫶
2.5. Document Impact on IDMEF Designs
Proposed IDMEF designs are expected to, at a minimum, meet the requirements in this document ✅ That said, this document is only one of many things the evaluation will look at. The working group might use extra metrics to compare competing IDMEF designs and/or communication protocols too, and that's totally fair 🥰
3. General Requirements
3.1. Use of Existing RFCs
The IDMEF SHALL reference and use previously published RFCs where possible. 📖✨
3.1.1. Rationale
The IETF has already done a ton of research and work on networks and security 🧠 Since time is precious, it's smart to just use standards that are already defined and accepted instead of reinventing the wheel 🛞
3.2. IPv4 and IPv6
The IDMEF specification MUST take into account that IDMEF should be able to operate in environments that contain IPv4 and IPv6 implementations. 🌍
3.2.1 Rationale
Pure IPv4, hybrid IPv6/IPv4, and pure IPv6 environments are all expected to exist during the time frame of IDMEF implementations 🗓️ So the IDMEF specification MUST support both IPv6 and IPv4 environments. No one gets left out 🫂
4. Message Format Requirements
The IDMEF message format is meant to be independent of the IDMEF Communication Protocol (IDP) 🎁 It should be possible to use a completely different transport mechanism without changing the IDMEF format. The goal here is a clean separation between semantics and communication mechanisms, so the message format and the delivery method don't get tangled together 🧵 Obviously, the IDMEF Communication Protocol is recommended 💜
4.1. Internationalization and Localization
IDMEF message formats SHALL support full internationalization and localization. 🌏🗣️
4.1.1. Rationale
Network security and intrusion detection cross geographic, political, and cultural boundaries, which is a big deal 🌐 So IDMEF messages MUST be formatted so they can be shown to an operator in a local language, following local presentation customs 🇫🇷🇯🇵🇧🇷
4.1.2. Scenario
An IDMEF specification might include numeric event identifiers 🔢 An IDMEF implementation might then translate those numeric identifiers into local language descriptions. When messages contain strings, the information might be represented using the ISO/IEC IS 10646-1 character set and encoded using the UTF-8 transformation format to make internationalization easier [3] 💕
4.2. Message Filtering and Aggregation
The format of IDMEF messages MUST support filtering and/or aggregation of data by the manager. 🗂️✨
4.2.1. Rationale
Some managers might want to do filtering and/or data aggregation on IDMEF messages, and since that's anticipated, the IDMEF messages MUST be structured to make those operations easy 🧁
4.2.2. Scenario
An IDMEF specification proposal might recommend fixed-format messages with strong numerical semantics 🔢 That would be perfect for high-performance filtering and aggregation by the receiving station. Speed queen behavior 🏎️💨
5. IDMEF Communication Protocol (IDP) Requirements
5.1. Reliable Message Transmission
The IDP MUST support reliable transmission of messages. 📬💯
5.1.1. Rationale
IDS managers often rely on receiving data from IDS analyzers to do their jobs well 👀 Since managers depend on IDMEF messages for this, it's really important that IDP delivers IDMEF messages reliably. No dropped alerts, periodt 💅
5.2. Interaction with Firewalls
The IDP MUST support transmission of messages between ID components across firewall boundaries without compromising security. 🧱🔐
5.2.1. Rationale
Firewalls are going to be deployed between IDMEF capable analyzers and their managers a lot, so being able to relay messages through a proxy or another suitable mechanism across firewalls is necessary 🦋 Setting up this communication MUST NOT require changes to the intervening firewall(s) that weaken the security of the protected network(s). Nor SHOULD this be done by mixing IDMEF messages with other kinds of traffic (for example, by overloading the HTTP POST method) 🙅♀️ That would make it really hard for an organization to apply separate policies to IDMEF traffic and everything else, and that's a whole mess 😭
5.2.2. Scenario 🦋
okay so one possible design is using TCP to carry IDMEF messages 💜 The whole goal here is avoiding opening dangerous inbound "holes" in the firewall 🔥 When the manager is inside the firewall and the analyzers are outside, this is usually handled by having the manager start an outbound connection to each analyzer 🫶 But it's also possible to put the manager outside the firewall and the analyzers on the inside. That can happen when a third-party vendor (like an ISP) is running monitoring services for a user 👑 In that case, each analyzer would start the outbound connections to the manager ✨ A mechanism that lets either the manager or the analyzer start a connection would give maximum flexibility in how you deploy managers and analyzers 🌈 main character energy
5.3. Mutual Authentication 🔐
The IDP MUST support mutual authentication of the analyzer and the manager to each other. Application-layer authentication is required irrespective of the underlying transport layer. 💖
5.3.1. Rationale
Alerts are how a manager decides what responses or further investigation are needed for enterprise network security, so the receiver needs to trust who sent them, and the sender needs to trust who receives them 🎀 This is peer-to-peer authentication of each party to the other. It MUST NOT be limited to authentication of the underlying communications mechanism, for example, because that process might be subverted or misconfigured 🙈
5.4. Message Confidentiality 🤫
The IDP MUST support confidentiality of the message content during message exchange. The selected design MUST be capable of supporting a variety of encryption algorithms and MUST be adaptable to a wide variety of environments. 🧚
5.4.1. Rationale
IDMEF messages can hold super sensitive stuff (like passwords), so an intruder would be obsessed with them 💀 Since some of these messages will likely travel over uncontrolled network segments, the content needs to be shielded. The legal situation for encryption tech is also extremely varied and changes often, so the design should support a bunch of encryption options and let the user adapt it to different environments 🌸
5.5. Message Integrity 🛡️
The IDP MUST ensure the integrity of the message content. The selected design MUST be capable of supporting a variety of integrity mechanisms and MUST be adaptable to a wide variety of environments. ✨
5.5.1. Rationale
Managers use IDMEF messages to direct action related to the security of the protected enterprise network, so it's vital that the manager can be certain the content hasn't been changed after transmission 🔥
5.6. Per-source Authentication 🔑
The IDP MUST support separate authentication keys for each sender. If symmetric algorithms are used, these keys would need to be known to the manager it is communicating with. 💅
5.6.1. Rationale
Sensitive security information is being exchanged via IDMEF, so it's important that the manager can authenticate each analyzer sending alerts 🫶
5.7. Denial of Service 🚨
The IDP SHOULD resist protocol denial-of-service attacks. 🙅♀️
5.7.1. Rationale
A common way to defeat secure communications systems is resource exhaustion. While this doesn't corrupt valid messages, it can stop any communication at all 😭 It's desirable that IDP resist such denial-of-service attacks.
5.7.2. Scenario
An attacker penetrates a network defended by an IDS. He isn't certain an IDS is present, but he is certain that application-level encrypted traffic (i.e., IDMEF traffic) is being exchanged between components on the network under attack. He decides to mask his presence and disrupt the encrypted communications by launching one or more flood events. If the IDP can resist such an attack, the probability that the attacker will be stopped increases 👑
5.8. Message Duplication 👯♀️
The IDP SHOULD resist malicious duplication of messages. 🌷
5.8.1. Rationale
A common way to hurt the performance of secure communications mechanisms is duplicating the messages being sent, even though the attacker might not understand them, just to confuse the receiver 🙃 It's desirable that the IDP resist such message duplication.
5.8.2. Scenario
An attacker penetrates a network defended by an IDS. She suspects an IDS is present and quickly spots the encrypted traffic flowing between system components as a possible threat. Even though she can't read this traffic, she copies the messages and directs multiple copies at the receiver in an attempt to confuse it. If the IDP resists such message duplication, the probability that the attacker will be stopped increases 💜
6. Message Content Requirements 📋
6.1. Detected Data 🔍
There are many different types of IDSs, such as those based on signatures, anomalies, correlation, network monitoring, host monitoring, or application monitoring 🦋 The IDMEF design MUST strive to accommodate these diverse approaches by concentrating on conveying what an IDS has detected, rather than how it detected it ✨
6.1.1. Rationale
There are many types of IDSs that analyze a variety of data sources. Some are profile based and operate on log files, attack signatures, etc. Others are anomaly based: they define normal behavior and detect deviations from the established baseline 🌈 Each of these IDSs reports different data that, in part, depends on its intrusion detection methodology. All MUST be supported by this standard 💖
6.2. Event Identity 🪪
The content of IDMEF messages MUST contain the identified name of the event (event identity) if it is known. This name MUST be drawn from a standardized list of events (if available) or will be an implementation-specific name if the event identity has not yet been standardized. It is not known how this standardized list will be defined or updated. Requirements on the creation of this list are beyond our efforts. Other groups within the security arena are investigating the creation of such lists 🫶
6.2.1. Rationale
This document sets requirements for standardizing ID message formats so that an ID manager can receive alerts from analyzers across multiple implementations, so it's important the manager understands the semantics of the reported events 🧠 That means there's a need to identify known events and store information about their methods and possible fixes. Some events are well known, and recognizing them can help the operator 🌸
6.2.2. Scenario
An intruder launches an attack that is detected by two different analyzers from two distinct implementations. Both report the same event identity to the ID manager, even though the algorithms used to detect the attack might have been different in each analyzer 👀
6.3. Event Background Information 📚
The IDMEF message design MUST include information, which the sender should provide, that allows a receiver to locate background information on the kind of event that is being reported in the alert. 🔗
6.3.1. Rationale
Administrators use this information to report and fix problems 🛠️
6.3.2. Scenario
An attacker performs a well-known attack. A reference to a URL with background information on the attack is included in the IDMEF message. The operator uses this information to initiate repairs on the vulnerable system 💅
6.4. Additional Data 🎁
The IDMEF message MUST be able to reference additional detailed data related to this specific underlying event. It is OPTIONAL for implementations to use this field. No requirements are placed on the format or content of this field. It is expected that this will be defined and described by the implementor 🌟
6.4.1. Rationale
Operators might want more specifics on an event. This field, if filled in by the analyzer, MAY point to additional or more detailed information about the event 🔎
6.5. Event Source and Target Identity 🎯
The IDMEF message MUST contain the identity of the source of the event and target component identifier if it is known. In the case of a network-based event, this will be the source and destination IP address of the session used to launch the event. Note that the identity of source and target will vary for other types of events, such as those launched or detected at the operating system or application level 🧚♀️
6.5.1. Rationale
This allows the operator to identify the source and target of the event 💜
6.6. Device Address Types 📡
The IDMEF message MUST support the representation of different types of device addresses. 🌍
6.6.1. Rationale
A device is a uniquely addressable element on the network (i.e., not limited to computers or networks or a specific level of the network protocol hierarchy). Devices involved in an intrusion event might also use addresses that are not IP-centric 🦋
6.6.2. Scenario
The IDS recognizes an intrusion on a particular device and includes both the IP address and the MAC address of the device in the IDMEF message. In another situation, the IDS recognizes an intrusion on a device that has only a MAC address and includes only that address in the IDMEF message. Another situation involves analyzers in an Asynchronous Transfer Mode (ATM) switch fabric that use E.164 address formats 🍓
6.7. Event Impact 💥
The IDMEF message MUST contain an indication of the possible impact of this event on the target. The IDMEF design document MUST define the scope of this value. 🎯
6.7.1. Rationale
Information about the possible impact of the event on the target system shows what the intruder is attempting to do, and it's critical data for the operator to perform damage assessment 😤 Not all systems will be able to determine this, but it's important data to transmit for those systems that can. This requirement places no requirements on the list itself (e.g., properties of the list, maintenance, etc.). Rather, it only specifies that the IDMEF must contain a field for specifying the impact and that the IDMEF must define the scope of such values 📝
6.8. Automatic Response 🤖
The IDMEF message MUST provide information about the automatic actions taken by the analyzer in response to the event (if any). ⚡
6.8.1. Rationale
It is very important for the operator to know if there was an automated response and what that response was. This helps determine what further action to take, if any 💅
6.9. Analyzer Location 📍
The IDMEF message MUST include information that would make it possible to later identify and locate the individual analyzer that reported the event. 🗺️
6.9.1. Rationale
The identity of the detecting analyzer is often a valuable piece of data for determining how to respond to a particular event 🫶
6.9.2. Scenario
One interesting scenario involves the progress of an intrusion event throughout a network. If the same event is detected and reported by multiple analyzers, the identity of the analyzer (in the case of a network-based analyzer) might provide some indication of the network location of the target systems and might warrant a specific type of response. This might be implemented as an IP address 🌈
6.10. Analyzer Identity 🕵️
okay so the IDMEF message MUST be able to carry the identity of the implementor AND the analyzer that actually caught the event. 💅 it's giving receipts!
6.10.1. Rationale
some orgs run multiple IDSs to protect their whole enterprise 🏢 this info helps the sysadmin figure out which implementor and which analyzer spotted the thing. no more guessing, bestie 🔍
6.10.2. Scenario
analyzer X from implementor Y spots a potential intrusion 👀 it sends a message saying it found a possible break-in, with X and Y both named. the operator can then factor in the known strengths or weaknesses of analyzer X when deciding what to do next 🧠✨
6.11. Degree of Confidence 💯
the IDMEF message MUST be able to say how confident the report is. the analyzer filling this in is OPTIONAL, cuz not every analyzer will have this data available 🤷♀️ no pressure!
6.11.1. Rationale
a lot of IDSs have thresholds that decide whether an alert gets generated at all 🚦 that threshold can change how much you trust the report, or hint that it might be a false alarm 🙈
6.11.2. Scenario
the alarm threshold is set really low, which means the org wants reports on ANY sus activity, even if it's probably not a real attack 🫣 the degree-of-confidence field then tells you whether this is a low-probability or high-probability event. iconic sorting 💜
6.12. Alert Identification 🪪
the IDMEF message MUST be uniquely identifiable, meaning it can be told apart from other IDMEF messages 🔑 every message gets its own ID card, periodt.
6.12.1. Rationale
an IDMEF message might get sent by several geographically-distributed analyzers at different times 🌍 a unique identifier lets you find a given message quickly for data reduction and correlation 🧩
6.12.2. Scenario
the unique identifier might be a unique originator identifier (like an IPv4 or IPv6 address) stuck together with a unique sequence number the originator generated 🔢 in a typical IDS setup, a low-level event analyzer logs the raw sensor info into something like a database while it analyzes and reports results up to higher levels 🗄️ so the unique raw message identifier can be included in the result message as supporting evidence 📎 higher-level analyzers can later use that ID to pull the raw message back out of the database whenever they need it 🫶
6.13. Alert Creation Date and Time ⏰
the IDMEF MUST support reporting the alert creation date and time in each event. the creation date and time means the moment the analyzer decided to create an alert ✨ the IDMEF MAY support additional dates and times too, like when the event the alert refers to actually began.
6.13.1. Rationale
time is everything for reporting AND correlation 🕰️ event onset time can be different from alert creation time, because the sensor needs some time to gather info about the monitored activity before it generates the event, and then the analyzer needs more time to receive it and create an alert 🐢 so the event onset time is a better match for when the activity really started than the alert creation time is 💅
6.13.2. Scenario
if an event is reported in the quiet hours of the night, the operator might give it a higher priority than the same event reported during the busy hours of the day 🌙☀️ also, something like a lengthy port scan can run over a long stretch of time, so it's super useful for the analyzer to report both the alert time AND the time the event began ⏳
6.14. Time Synchronization 🌐
time SHALL be reported in a way that lets events from multiple analyzers in different time zones reach the same manager, and that lets you figure out the local time at each analyzer 🗺️
6.14.1. Rationale
for event correlation, the manager needs to be able to normalize the time info in the IDMEF alerts 🧃 otherwise everything's out of sync and nobody's having a good time 😭
6.14.2. Scenario
a distributed ID system has analyzers spread across multiple time zones, all reporting to one manager 🌏 an intrusion happens across several time zones AND several analyzers. the central manager needs enough info to normalize these alerts, see that they were all reported around the same "time", and realize they're part of the same attack 🕵️♀️🔥
6.15. Time Format 📅
the format for reporting the date MUST be compliant with all current standards for the Year 2000 rollover, AND it MUST have enough capability to keep reporting date values past the year 2038 🎆 no cutting corners, bestie.
6.15.1. Rationale
we want the IDMEF to have a long life 🦋 and implementations need to work in all kinds of environments 🌈 so anything that limits how long the IDMEF can last (like the 2038 date representation limit) MUST be avoided 🚫
6.16. Time Granularity and Accuracy ⏱️
time granularity and time accuracy in event messages SHALL NOT be specified by the IDMEF. it's not its job! 🙅♀️
6.16.1. Rationale
the IDMEF can't assume any particular clock granularity on the sensing elements, so it can't put any requirements on how fine the event timestamps are 🔬 it also can't assume the clocks used to timestamp the events have any specified accuracy 🕐 no assumptions, just vibes.
6.17. Message Extensions 🧩
the IDMEF message MUST support an extension mechanism that implementors use to define implementation-specific data. using this mechanism is OPTIONAL for the implementor 💜 this data holds implementation-specific info, decided by each implementor. the implementor MUST indicate how to interpret these extensions, though there are no specific requirements on how implementors describe their own extensions 📝 and the lack or presence of these implementation-specific message extensions MUST NOT break interoperation. super important, bestie 🫶
6.17.1. Rationale
implementors might want to add extra stuff like the version number of their product, or other value-added data that's special to their product 🎁 they can publish a document or a website describing their extensions, OR they can use an in-band extension mechanism that describes itself 📚 but extensions are NOT a free pass to break interoperation of IDMEF messages 🚨
6.18. Message Semantics 📖
the semantics of the IDMEF message MUST be well defined. the meaning has to be clear, no mixed signals 💌
6.18.1. Rationale
good semantics are key to understanding what the message is trying to say, so there are zero errors 🎯 operators decide what action to take based on these messages, so they need to be able to read them correctly 🧠
6.18.2. Scenario
without this requirement, the operator gets an IDMEF message and reads it one way 😬 but the implementor who built the message meant something different. so the corrective action ends up being wrong 💀
6.19. Message Extensibility 🌱
the IDMEF itself MUST be extensible. as new ID technologies pop up and new info about events becomes available, the IDMEF message format MUST be able to include that new info 🆕 and that extensibility MUST happen in a way where interoperability is NOT impacted ✨
6.19.1. Rationale
intrusion detection tech keeps evolving, so more info about detected events will probably show up over time 📈 the IDMEF message format MUST be extendable by a specific implementation to hold this new info 🧃 but extensions are still NOT a license to break interoperation of IDMEF messages 🙅♀️
7. Security Considerations 🚨🔐
okay this one's short but SO important 😤 this document doesn't cover security matters, EXCEPT that Section 5 lays out the security requirements for the protocols that are going to be developed. go check Section 5, it's the main character here 👑
8. References 📚
8.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
- [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
- [4] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
- [5] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765, March 2007.
9. Acknowledgements 🫶🌸
the following individuals contributed substantially to this document and deserve major recognition for their efforts 👏 this document would not exist without their help 💖
- Mark Crosbie, Hewlett-Packard
- David Curry, IBM Emergency Response Services
- David Donahoo, Air Force Information Warfare Center
- Mike Erlinger, Harvey Mudd College
- Fengmin Gong, Microcomputing Center of North Carolina
- Dipankar Gupta, Hewlett-Packard
- Glenn Mansfield, Cyber Solutions, Inc.
- Jed Pickel, CERT Coordination Center
- Stuart Staniford-Chen, Silicon Defense
- Maureen Stillman, Nokia IP Telephony
Authors' Addresses 🦋
Mark Wood
Internet Security Systems, Inc.
6303 Barfield Road
Atlanta, GA 30328
US
EMail: mark1@iss.net
Michael A. Erlinger
Harvey Mudd College
Computer Science Dept
301 East 12th Street
Claremont, CA 91711
US
EMail: mike@cs.hmc.edu
URI: http://www.cs.hmc.edu/Full Copyright Statement ©️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 📜
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. it also doesn't say it has made any independent effort to identify any such rights. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights, can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr.
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. please send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc4766 2007-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms