idnits 2.17.1 draft-ietf-idwg-requirements-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2002) is 7856 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2828 (ref. '4') (Obsoleted by RFC 4949) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intrusion Detection Working Group M. Wood 3 Internet-Draft Internet Security Systems, Inc 4 Expires: April 22, 2003 M. Erlinger 5 Harvey Mudd College 6 October 22, 2002 8 Intrusion Detection Message Exchange Requirements 9 draft-ietf-idwg-requirements-10 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 22, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 The purpose of the Intrusion Detection Exchange Format Working Group 41 (IDWG) is to define data formats and exchange procedures for sharing 42 information of interest to intrusion detection and response systems, 43 and to the management systems which may need to interact with them. 44 This Internet-Draft describes the high-level requirements for such a 45 communication mechanism, including the rationale for those 46 requirements where clarification is needed. Scenarios are used to 47 illustrate some requirements. 49 Table of Contents 51 1. Conventions Used in This Document . . . . . . . . . . . . 5 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 53 2.1 Rationale for IDMEF . . . . . . . . . . . . . . . . . . . 6 54 2.2 Intrusion Detection Terms . . . . . . . . . . . . . . . . 7 55 2.2.1 Activity: . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.2.2 Administrator: . . . . . . . . . . . . . . . . . . . . . . 7 57 2.2.3 Alert: . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.2.4 Analyzer: . . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.2.5 Data Source: . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.2.6 Event: . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.2.7 IDS: . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.2.8 Manager . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.2.9 Notification: . . . . . . . . . . . . . . . . . . . . . . 8 64 2.2.10 Operator: . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.2.11 Response: . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.2.12 Sensor: . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 2.2.13 Signature: . . . . . . . . . . . . . . . . . . . . . . . . 9 68 2.2.14 Security Policy: . . . . . . . . . . . . . . . . . . . . . 9 69 2.3 Architectural Assumptions . . . . . . . . . . . . . . . . 10 70 2.4 Organization of This Document . . . . . . . . . . . . . . 11 71 2.5 Document Impact on IDMEF Designs . . . . . . . . . . . . . 12 72 3. General Requirements . . . . . . . . . . . . . . . . . . . 13 73 3.1 Use of Existing RFCs . . . . . . . . . . . . . . . . . . . 13 74 3.1.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 13 75 3.2 IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . 13 76 3.2.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4. Message Format Requirements . . . . . . . . . . . . . . . 14 78 4.1 Internationalization and Localization . . . . . . . . . . 14 79 4.1.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.1.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.2 Message Filtering and Aggregation . . . . . . . . . . . . 14 82 4.2.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.2.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 14 84 5. IDMEF Communications Protocol (IDP) Requirements . . . . . 15 85 5.1 Reliable Message Transmission . . . . . . . . . . . . . . 15 86 5.1.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.2 Interaction with Firewalls . . . . . . . . . . . . . . . . 15 88 5.2.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 15 89 5.2.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 15 90 5.3 Mutual Authentication . . . . . . . . . . . . . . . . . . 16 91 5.3.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 16 92 5.4 Message Confidentiality . . . . . . . . . . . . . . . . . 16 93 5.4.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 16 94 5.5 Message Integrity . . . . . . . . . . . . . . . . . . . . 16 95 5.5.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 16 96 5.6 Per-source Authentication . . . . . . . . . . . . . . . . 17 97 5.6.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 17 98 5.7 Denial of Service . . . . . . . . . . . . . . . . . . . . 17 99 5.7.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 17 100 5.7.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 17 101 5.8 Message Duplication . . . . . . . . . . . . . . . . . . . 17 102 5.8.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 17 103 5.8.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 18 104 6. Message Content Requirements . . . . . . . . . . . . . . . 19 105 6.1 Detected Data . . . . . . . . . . . . . . . . . . . . . . 19 106 6.1.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 19 107 6.2 Event Identity . . . . . . . . . . . . . . . . . . . . . . 19 108 6.2.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 19 109 6.2.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 19 110 6.3 Event Background Information . . . . . . . . . . . . . . . 20 111 6.3.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 20 112 6.3.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 20 113 6.4 Additional Data . . . . . . . . . . . . . . . . . . . . . 20 114 6.4.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 20 115 6.5 Event Source and Target Identity . . . . . . . . . . . . . 20 116 6.5.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 20 117 6.6 Device Address Types . . . . . . . . . . . . . . . . . . . 21 118 6.6.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 21 119 6.6.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 21 120 6.7 Event Impact . . . . . . . . . . . . . . . . . . . . . . . 21 121 6.7.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 21 122 6.8 Automatic Response . . . . . . . . . . . . . . . . . . . . 21 123 6.8.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 21 124 6.9 Analyzer Location . . . . . . . . . . . . . . . . . . . . 22 125 6.9.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 22 126 6.9.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 22 127 6.10 Analyzer Identity . . . . . . . . . . . . . . . . . . . . 22 128 6.10.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 22 129 6.10.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 22 130 6.11 Degree of Confidence . . . . . . . . . . . . . . . . . . . 22 131 6.11.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 23 132 6.11.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 23 133 6.12 Alert Identification . . . . . . . . . . . . . . . . . . . 23 134 6.12.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 23 135 6.12.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 23 136 6.13 Alert Creation Date and Time . . . . . . . . . . . . . . . 23 137 6.13.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 24 138 6.13.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 24 139 6.14 Time Synchronization . . . . . . . . . . . . . . . . . . . 24 140 6.14.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 24 141 6.14.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 24 142 6.15 Time Format . . . . . . . . . . . . . . . . . . . . . . . 24 143 6.15.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25 144 6.16 Time Granularity and Accuracy . . . . . . . . . . . . . . 25 145 6.16.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25 146 6.17 Message Extensions . . . . . . . . . . . . . . . . . . . . 25 147 6.17.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25 148 6.18 Message Semantics . . . . . . . . . . . . . . . . . . . . 25 149 6.18.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25 150 6.18.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 26 151 6.19 Message Extensibility . . . . . . . . . . . . . . . . . . 26 152 6.19.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 26 153 7. Security Considerations . . . . . . . . . . . . . . . . . 27 154 Informative References . . . . . . . . . . . . . . . . . . 28 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28 156 A. History of Significant Changes . . . . . . . . . . . . . . 29 157 A.1 Significant Changes Since requirements-09 . . . . . . . . 29 158 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30 159 Full Copyright Statement . . . . . . . . . . . . . . . . . 31 161 1. Conventions Used in This Document 163 This is not an IETF standards track document [1] and thus the 164 keywords MUST, MUST NOT, SHOULD, and MAY are NOT as in RFC 2119, [2] 165 but rather: 167 o MUST: This word, or the terms "REQUIRED" or "SHALL", means that 168 the described behavior or characteristic is an absolute 169 requirement for a proposed IDWG specification. 171 o MUST NOT: This phrase, or the phrase "SHALL NOT", means that the 172 described behavior or characteristic is an absolute prohibition of 173 a proposed IDWG specification. 175 o SHOULD: This word, or the adjective "RECOMMENDED", means that 176 there may exist valid reasons in particular circumstances for a 177 proposed IDWG specification to ignore described behavior or 178 characteristics. 180 o MAY: This word, or the adjective "OPTIONAL", means that described 181 behavior or characteristics are truly optional for a proposed IDWG 182 specification. One proposed specification may choose to include 183 the described behavior or characteristic while another proposed 184 specification may omit the same behavior or characteristic. 186 2. Introduction 188 This document defines requirements for the Intrusion Detection 189 Message Exchange Format (IDMEF), which is the intended work product 190 of the Intrusion Detection Exchange Format Working Group (IDWG). 191 IDMEF is planned to be a standard format which automated Intrusion 192 Detection Systems (IDS) [4] can use for reporting what they have 193 deemed to be suspicious or of interest. This document also specifies 194 requirements for a communication protocol for communicating IDMEF. 195 As chartered IDWG, has the responsibility to first evaluate existing 196 communication protocols before choosing to specify a new one. Thus 197 the requirements in this document can be used to evaluate existing 198 communication protocols. If IDWG determines that a new communication 199 protocol is necessary, the requirements in this document can be used 200 to evaluate proposed solutions. 202 2.1 Rationale for IDMEF 204 The reasons such a format should be useful are as follows: 206 1. A number of commercial and free Intrusion Detection Systems are 207 available and more are becoming available all the time. Some 208 products are aimed at detecting intrusions on the network, others 209 are aimed at host operating systems, while still others are aimed 210 at applications. Even within a given category, the products have 211 very different strengths and weaknesses. Hence it is likely that 212 users will deploy more than a single product, and users will want 213 to observe the output of these products from one or more 214 manager(s). A standard format for reporting will simplify this 215 task greatly. 217 2. Intrusions frequently involve multiple organizations as victims, 218 or multiple sites within the same organization. Typically, those 219 sites will use different IDSs. It would be very helpful to 220 correlate such distributed intrusions across multiple sites and 221 administrative domains. Having reports from all sites in a 222 common format would facilitate this task. 224 3. The existence of a common format should allow components from 225 different IDSs to be integrated more readily. Thus, Intrusion 226 Detection (ID) research should migrate into commercial products 227 more easily. 229 4. In addition to enabling communication from an ID analyzer to an 230 ID manager, the IDMEF notification system may also enable 231 communication between a variety of IDS components. However, for 232 the remainder of this document, we refer to the communication as 233 going from an analyzer to a manager. 235 All of these reasons suggest that a common format for reporting 236 anything deemed suspicious should help the IDS market to grow and 237 innovate more successfully, and should result in IDS users obtaining 238 better results from deployment of ID systems. 240 2.2 Intrusion Detection Terms 242 In order to make the rest of the requirements clearer, we define some 243 terms about typical IDSs. These terms are presented in alphabetical 244 order. The diagram at the end of this section illustrates the 245 relationships of some of the terms defined herein. 247 2.2.1 Activity: 249 Elements of the data source or occurrences within the data source 250 that are identified by the sensor or analyzer as being of interest to 251 the operator. Examples of this include (but are not limited to) 252 network session showing unexpected telnet activity, operating system 253 log file entries showing a user attempting to access files to which 254 he is not authorized to have access, application log files showing 255 persistent login failures, etc. 257 Activity can range from extremely serious occurrences (such as an 258 unequivocally malicious attack) to less serious occurrences (such as 259 unusual user activity that's worth a further look) to neutral 260 activity (such as user login). 262 2.2.2 Administrator: 264 The human with overall responsibility for setting the security policy 265 of the organization, and, thus, for decisions about deploying and 266 configuring the IDS. This may or may not be the same person as the 267 operator of the IDS. In some organizations, the administrator is 268 associated with the network or systems administration groups. In 269 other organizations, it's an independent position. 271 2.2.3 Alert: 273 A message from an analyzer to a manager that an event of interest has 274 been detected. An alert typically contains information about the 275 unusual activity that was detected, as well as the specifics of the 276 occurrence. 278 2.2.4 Analyzer: 280 The ID component or process that analyzes the data collected by the 281 sensor for signs of unauthorized or undesired activity or for events 282 that might be of interest to the security administrator. In many 283 existing IDSs, the sensor and the analyzer are part of the same 284 component. In this document, the term analyzer is used generically 285 to refer to the sender of the IDMEF message. 287 2.2.5 Data Source: 289 The raw information that an intrusion detection system uses to detect 290 unauthorized or undesired activity. Common data sources include (but 291 are not limited to) raw network packets, operating system audit logs, 292 application audit logs, and system-generated checksum data. 294 2.2.6 Event: 296 The occurrence in the data source that is detected by the sensor and 297 which may result in an IDMEF alert being transmitted. For example, 298 'N' failed logins in 'T' seconds might indicate a brute-force login 299 attack. 301 2.2.7 IDS: 303 Intrusion detection system. Some combination of one or more of the 304 following components: sensor, analyzer, manager. 306 2.2.8 Manager 308 The ID component or process from which the operator manages the 309 various components of the ID system. Management functions typically 310 include (but are not limited to) sensor configuration, analyzer 311 configuration, event notification management, data consolidation, and 312 reporting. 314 2.2.9 Notification: 316 The method by which the IDS manager makes the operator aware of the 317 alert occurrence and thus the event. In many IDSs, this is done via 318 the display of a colored icon on the IDS manager screen, the 319 transmission of an e-mail or pager message, or the transmission of an 320 SNMP trap, although other notification techniques are also used. 322 2.2.10 Operator: 324 The human that is the primary user of the IDS manager. The operator 325 often monitors the output of the ID system and initiates or 326 recommends further action. 328 2.2.11 Response: 330 The actions taken in response to an event. Responses may be 331 undertaken automatically by some entity in the IDS architecture or 332 may be initiated by a human. Sending a notification to the operator 333 is a very common response. Other responses include (but are not 334 limited to) logging the activity, recording the raw data (from the 335 data source) that characterized the event, terminating a network, 336 user, or application session, or altering network or system access 337 controls. 339 2.2.12 Sensor: 341 The ID component that collects data from the data source. The 342 frequency of data collection will vary across IDS offerings. The 343 sensor is setup to forward events to the analyzer. 345 2.2.13 Signature: 347 A rule used by the analyzer to identify interesting activity to the 348 security administrator. Signatures represent one of the mechanisms 349 (though not necessarily the only mechanism) by which IDSs detect 350 intrusions. 352 2.2.14 Security Policy: 354 The predefined, formally documented statement which defines what 355 activities are allowed to take place on an organization's network or 356 on particular hosts to support the organization's requirements. This 357 includes, but is not limited to, which hosts are to be denied 358 external network access. 360 ________ 361 | | -------- 362 | Data |_________ ________| | __________ 363 | Source | Activity |Sensor | | | 364 |________| | |________| | Operator |_______ 365 | | |__________| | 366 \|/ Event A | 367 _____V___ | /|\ | 368 | | | \ | 369 | Sensor |__ | Notification | 370 |_________| Event | \ \|/ 371 A | V_________ \ V 372 /|\ | | | \ Response 373 | --->| Analyzer|__ | A 374 | | | Alert | /|\ 375 | |_________| | | | 376 | A | | | 377 | /|\ \|/ | | 378 |________________| ____V___ | | 379 | | |_| | 380 | | Manager|_________| 381 | |________| 382 | A 383 Security /|\ 384 _______________ | Policy__________| 385 | | | 386 | Administrator |__| 387 |_______________| 389 The diagram above illustrates the terms above and their 390 relationships. Not every IDS will have all of these separate 391 components exactly as shown. Some IDSs will combine these components 392 into a single module; some will have multiple instances of these 393 modules. 395 2.3 Architectural Assumptions 397 In this document, as defined in the terms above, we assume that an 398 analyzer determines somehow that a suspicious event has been seen by 399 a sensor, and sends an alert to a manager. The format of that alert 400 and the method of communicating it are what IDMEF proposes to 401 standardize. 403 For the purposes of this document, we assume that the analyzer and 404 manager are separate components, and that they are communicating 405 pairwise across a TCP/IP network. No other form of communication 406 between these entities is contemplated in this document, and no other 407 use of IDMEF alerts is considered. We refer to the communication 408 protocol that communicates IDMEF as the IDMEF Communication Protocol 409 (IDP). 411 The Trust Model is not specified as a requirement, but is rather left 412 to the choice of the IDMEF communications protocol, i.e., a design 413 decision. What is specified are individual security related 414 requirements, Section 5. 416 We try to make no further architectural assumptions than those just 417 stated. For example, the following points should not matter: 419 o Whether the sensor and the analyzer are integrated or separate. 421 o Whether the analyzer and manager are isolated, or embedded in some 422 large hierarchy or distributed mesh of components. 424 o Whether the manager actually notifies a human, takes action 425 automatically, or just analyzes incoming alerts and correlates 426 them. 428 o Whether a component might act as an analyzer with respect to one 429 component, while also acting as a manager with respect to another. 431 2.4 Organization of This Document 433 Besides this requirements document, the IDWG should produce two other 434 documents. The first should describe a data format or language for 435 exchanging information about suspicious events. In this, the 436 requirements document, we refer to that document as the "data-format 437 specification". The second document to be produced should identify 438 existing IETF protocols that are best used for conveying the data so 439 formatted, and explain how to package this data in those existing 440 formats or the document should specify a new protocol. We refer to 441 this as the IDP (IDMEF Communication Protocol). 443 Accordingly, the requirements here are partitioned into four sections 445 o The first of these contains general requirements that apply to all 446 aspects of the IDMEF specification Section 3. 448 o The second section describes requirements on the formatting of 449 IDMEF messages Section 4. 451 o The third section outlines requirements on the communications 452 mechanism, IDP, used to move IDMEF messages from the analyzer to 453 the manager Section 5. 455 o The final section contains requirements on the content and 456 semantics of the IDMEF messages Section 6 . 458 For each requirement, we attempt to state the requirement as clearly 459 as possible without imposing an idea of what a design solution should 460 be. Then we give the rationale for why this requirement is 461 important, and state whether this should be an essential feature of 462 the specification, or is beneficial but could be lacking if it is 463 difficult to fulfill. Finally, where it seems necessary, we give an 464 illustrative scenario. In some cases, we include possible design 465 solutions in the scenario. These are purely illustrative. 467 2.5 Document Impact on IDMEF Designs 469 It is expected that proposed IDMEF designs will, at a minimum, 470 satisfy the requirements expressed in this document. However, this 471 document will be used only as one of many criteria in the evaluation 472 of various IDMEF designs and proposed communication protocols. It is 473 recognized that the working group may use additional metrics to 474 evaluate competing IDMEF designs and/or communication protocols. 476 3. General Requirements 478 3.1 Use of Existing RFCs 480 The IDMEF SHALL reference and use previously published RFCs where 481 possible. 483 3.1.1 Rationale: 485 The IETF has already completed a great deal of research and work into 486 the areas of networks and security. In the interest of time, it is 487 smart to use already defined and accepted standards. 489 3.2 IPv4 and IPv6 491 The IDMEF specification MUST take into account that IDMEF should be 492 able to operate in environments that contain IPv4 and IPv6 493 implementations. 495 3.2.1 Rationale: 497 Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6 environments are 498 expected to exist within the time frame of IDMEF implementations, the 499 IDMEF specification MUST support IPv6 and IPv4 environments. 501 4. Message Format Requirements 503 The IDMEF message format is intended to be independent of the IDMEF 504 communications protocol (IDP). It should be possible to use a 505 completely different transport mechanism without changing the IDMEF 506 format. The goal behind this requirement is to ensure a clean 507 separation between semantics and communication mechanisms. Obviously 508 the IDMEF communication protocol is recommended. 510 4.1 Internationalization and Localization 512 IDMEF message formats SHALL support full internationalization and 513 localization. 515 4.1.1 Rationale: 517 Since network security and intrusion detection are areas that cross 518 geographic, political, and cultural boundaries, the IDMEF messages 519 MUST be formatted such that they can be presented to an operator in a 520 local language and adhering to local presentation customs. 522 4.1.2 Scenario: 524 An IDMEF specification might include numeric event identifiers. An 525 IDMEF implementation might translate these numeric event identifiers 526 into local language descriptions. In cases where the messages 527 contain strings, the information might be represented using the ISO/ 528 IEC IS 10646-1 character set and encoded using the UTF-8 529 transformation format to facilitate internationalization [3]. 531 4.2 Message Filtering and Aggregation 533 The format of IDMEF messages MUST support filtering and/or 534 aggregation of data by the manager. 536 4.2.1 Rationale: 538 Since it is anticipated that some managers might want to perform 539 filtering and/or data aggregation functions on IDMEF messages, the 540 IDMEF messages MUST be structured to facilitate these operations. 542 4.2.2 Scenario: 544 An IDMEF specification proposal might recommend fixed format messages 545 with strong numerical semantics. This would lend itself to high- 546 performance filtering and aggregation by the receiving station. 548 5. IDMEF Communications Protocol (IDP) Requirements 550 5.1 Reliable Message Transmission 552 The IDP MUST support reliable transmission of messages. 554 5.1.1 Rationale: 556 IDS managers often rely on receipt of data from IDS analyzers to do 557 their jobs effectively. Since IDS managers will rely on IDMEF 558 messages for this purpose, it is important that IDP deliver IDMEF 559 messages reliably. 561 5.2 Interaction with Firewalls 563 The IDP MUST support transmission of messages between ID components 564 across firewall boundaries without compromising security. 566 5.2.1 Rationale: 568 Since it is expected that firewalls will often be deployed between 569 IDMEF capable analyzers and their corresponding managers, the ability 570 to relay messages via proxy or other suitable mechanism across 571 firewalls is necessary. Setting up this communication MUST NOT 572 require changes to the intervening firewall(s) that weaken the 573 security of the protected network(s). Nor SHOULD this be achieved by 574 mixing IDMEF messages with other kinds of traffic (e.g., by 575 overloading the HTTP POST method) since that would make it difficult 576 for an organization to apply separate policies to IDMEF traffic and 577 other kinds of traffic. 579 5.2.2 Scenario: 581 One possible design is the use of TCP to convey IDMEF messages. The 582 general goal in this case is to avoid opening dangerous inbound 583 "holes" in the firewall. When the manager is inside the firewall and 584 the analyzers are outside the firewall, this is often achieved by 585 having the manager initiate an outbound connection to each analyzer. 586 However, it is also possible to place the manager outside the 587 firewall and the analyzers on the inside; this can occur when a 588 third-party vendor (such as an ISP) is providing monitoring services 589 to a user. In this case, the outbound connections would be initiated 590 by each analyzer to the manager. A mechanism that permits either the 591 manager or the analyzer to initiate connections would provide maximum 592 flexibility in manager and analyzer deployment. 594 5.3 Mutual Authentication 596 The IDP MUST support mutual authentication of the analyzer and the 597 manager to each other. Application-layer authentication is required 598 irrespective of the underlying transport layer. 600 5.3.1 Rationale: 602 Since the alert messages are used by a manager to direct responses or 603 further investigation related to the security of an enterprise 604 network, it is important that the receiver have confidence in the 605 identity of the sender and that the sender have confidence in the 606 identity of the receiver. This is peer-to-peer authentication of 607 each party to the other. It MUST NOT be limited to authentication of 608 the underlying communications mechanism, for example, because of the 609 risk that this authentication process might be subverted or 610 misconfigured. 612 5.4 Message Confidentiality 614 The IDP MUST support confidentiality of the message content during 615 message exchange. The selected design MUST be capable of supporting 616 a variety of encryption algorithms and MUST be adaptable to a wide 617 variety of environments. 619 5.4.1 Rationale: 621 IDMEF messages potentially contain extremely sensitive information 622 (such as passwords) and would be of great interest to an intruder. 623 Since it is likely some of these messages will be transmitted across 624 uncontrolled network segments, it is important that the content be 625 shielded. Furthermore, since the legal environment for encryption 626 technologies is extremely varied and changes often, it is important 627 that the design selected be capable of supporting a number of 628 different encryption options and be adaptable by the user to a 629 variety of environments. 631 5.5 Message Integrity 633 The IDP MUST ensure the integrity of the message content. The 634 selected design MUST be capable of supporting a variety of integrity 635 mechanisms and MUST be adaptable to a wide variety of environments. 637 5.5.1 Rationale: 639 IDMEF messages are used by the manager to direct action related to 640 the security of the protected enterprise network. It is vital for 641 the manager to be certain that the content of the message has not 642 been changed after transmission. 644 5.6 Per-source Authentication 646 The IDP MUST support separate authentication keys for each sender. 647 If symmetric algorithms are used, these keys would need to be known 648 to the manager it is communicating with. 650 5.6.1 Rationale: 652 Given that sensitive security information is being exchanged via the 653 IDMEF, it is important that the manager can authenticate each 654 analyzer sending alerts. 656 5.7 Denial of Service 658 The IDP SHOULD resist protocol denial of service attacks. 660 5.7.1 Rationale: 662 A common way to defeat secure communications systems is through 663 resource exhaustion. While this does not corrupt valid messages, it 664 can prevent any communication at all. It is desirable that IDP 665 resist such denial of service attacks. 667 5.7.2 Scenario: 669 An attacker penetrates a network being defended by an IDS. Although 670 the attacker is not certain that an IDS is present, he is certain 671 that application-level encrypted traffic (i.e., IDMEF traffic) is 672 being exchanged between components on the network being attacked. He 673 decides to mask his presence and disrupt the encrypted communications 674 by initiating one or more flood events. If the IDP can resist such 675 an attack, the probability that the attacker will be stopped 676 increases. 678 5.8 Message Duplication 680 The IDP SHOULD resist malicious duplication of messages. 682 5.8.1 Rationale: 684 A common way to impair the performance of secure communications 685 mechanisms is to duplicate the messages being sent, even though the 686 attacker might not understand them, in an attempt to confuse the 687 receiver. It is desirable that the IDP resist such message 688 duplication. 690 5.8.2 Scenario: 692 An attacker penetrates a network being defended by an IDS. The 693 attacker suspects that an IDS is present and quickly identifies the 694 encrypted traffic flowing between system components as being a 695 possible threat. Even though she cannot read this traffic, she 696 copies the messages and directs multiple copies at the receiver in an 697 attempt to confuse it. If the IDP resists such message duplication, 698 the probability that the attacker will be stopped increases. 700 6. Message Content Requirements 702 6.1 Detected Data 704 There are many different types of IDSs, such as those based on: 705 signatures, anomalies, correlation, network monitoring, host 706 monitoring, or application monitoring. The IDMEF design MUST strive 707 to accommodate these diverse approaches by concentrating on conveying 708 *what* an IDS has detected, rather than *how* it detected it. 710 6.1.1 Rationale: 712 Rationale: There are many types of IDSs that analyze a variety of 713 data sources. Some are profile based and operate on log files, 714 attack signatures etc. Others are anomaly based and define normal 715 behavior and detect deviations from the established baseline. Each 716 of these IDSs reports different data that, in part, depends on their 717 intrusion detection methodology. All MUST be supported by this 718 standard. 720 6.2 Event Identity 722 The content of IDMEF messages MUST contain the identified name of the 723 event (event identity) if it is known. This name MUST be drawn from 724 a standardized list of events (if available) or will be an 725 implementation-specific name if the event identity has not yet been 726 standardized. It is not known how this standardized list will be 727 defined or updated. Requirements on the creation of this list are 728 beyond our efforts. Other groups within the security arena are 729 investigating the creation of such lists. 731 6.2.1 Rationale: 733 Given that this document presents requirements on standardizing ID 734 message formats so that an ID manager is able to receive alerts from 735 analyzers from multiple implementations, it is important that the 736 manager understand the semantics of the reported events. There is, 737 therefore, a need to identify known events and store information 738 concerning their methods and possible fixes to these events. Some 739 events are well known and this recognition can help the operator. 741 6.2.2 Scenario: 743 Intruder launches an attack that is detected by two different 744 analyzers from two distinct implementations. Both report the same 745 event identity to the ID manager, even though the algorithms used to 746 detect the attack by each analyzer might have been different. 748 6.3 Event Background Information 750 The IDMEF message design MUST include information, which the sender 751 should provide, that allows a receiver to locate background 752 information on the kind of event that is being reported in the alert. 754 6.3.1 Rationale: 756 This information is used by administrators to report and fix 757 problems. 759 6.3.2 Scenario: 761 Attacker performs a well-known attack. A reference to a URL to 762 background information on the attack is included in the IDMEF 763 message. The operator uses this information to initiate repairs on 764 the vulnerable system. 766 6.4 Additional Data 768 The IDMEF message MUST be able to reference additional detailed data 769 related to this specific underlying event. It is OPTIONAL for 770 implementations to use this field. No requirements are placed on the 771 format or content of this field. It is expected that this will be 772 defined and described by the implementor. 774 6.4.1 Rationale: 776 Operators might want more information on specifics of an event. This 777 field, if filled in by the analyzer, MAY point to additional or more 778 detailed information about the event. 780 6.5 Event Source and Target Identity 782 The IDMEF message MUST contain the identity of the source of the 783 event and target component identifier if it is known. In the case of 784 a network-based event, this will be the source and destination IP 785 address of the session used to launch the event. Note that the 786 identity of source and target will vary for other types of events, 787 such as those launched/detected at the operating system or 788 application level. 790 6.5.1 Rationale: 792 This will allow the operator to identify the source and target of the 793 event. 795 6.6 Device Address Types 797 The IDMEF message MUST support the representation of different types 798 of device addresses. 800 6.6.1 Rationale: 802 A Device is a uniquely addressable element on the network. (i.e., 803 not limited to computers or networks nor a specific level of the 804 network protocol hierarchy). Additionally, devices involved in an 805 intrusion event might use addresses that are not IP-centric. 807 6.6.2 Scenario: 809 The IDS recognizes an intrusion on a particular device and includes 810 both the IP address and the MAC address of the device in the IDMEF 811 message. In another situation, the IDS recognizes an intrusion on a 812 device which has only a MAC address and includes only that address in 813 the IDMEF message. Another situation involves analyzers in an ATM 814 switch fabric which use E.164 address formats. 816 6.7 Event Impact 818 The IDMEF message MUST contain an indication of the possible impact 819 of this event on the target. The IDMEF design document MUST define 820 the scope of this value. 822 6.7.1 Rationale: 824 Information concerning the possible impact of the event on the target 825 system provides an indication of what the intruder is attempting to 826 do and is critical data for the operator to perform damage 827 assessment. Not all systems will be able to determine this, but it 828 is important data to transmit for those systems that can. This 829 requirement places no requirements on the list itself (e.g., 830 properties of the list, maintenance, etc.), rather the requirement 831 only specifies that the IDMEF must contain a field for specifying the 832 impact and that the IDMEF must define the scope of such values. 834 6.8 Automatic Response 836 The IDMEF message MUST provide information about the automatic 837 actions taken by the analyzer in response to the event (if any). 839 6.8.1 Rationale: 841 It is very important for the operator to know if there was an 842 automated response and what that response was. This will help 843 determine what further action to take, if any. 845 6.9 Analyzer Location 847 The IDMEF message MUST include information which would make it 848 possible to later identify and locate the individual analyzer which 849 reported the event. 851 6.9.1 Rationale: 853 The identity of the detecting analyzer often proves to be a valuable 854 piece of data to have in determining how to respond to a particular 855 event. 857 6.9.2 Scenario: 859 Scenario: One interesting scenario involves the progress of an 860 intrusion event throughout a network. If the same event is detected 861 and reported by multiple analyzers, the identity of the analyzer (in 862 the case of a network-based analyzer) might provide some indication 863 of the network location of the target systems and might warrant a 864 specific type of response. This might be implemented as an IP 865 address. 867 6.10 Analyzer Identity 869 The IDMEF message MUST be able to contain the identity of the 870 implementor and the analyzer that detected the event. 872 6.10.1 Rationale: 874 Rationale: Users might run multiple IDSs to protect their enterprise. 875 This data will help the systems administrator determine which 876 implementor and analyzer detected the event. 878 6.10.2 Scenario: 880 Analyzer X from implementor Y detects a potential intrusion. A 881 message is sent reporting that it found a potential break-in with X 882 and Y specified. The operator is therefore able to include the known 883 capabilities or weaknesses of analyzer X in his decision regarding 884 further action. 886 6.11 Degree of Confidence 888 The IDMEF message MUST be able to state the degree of confidence of 889 the report. The completion of this field by an analyzer is OPTIONAL, 890 as this data might not be available at all analyzers. 892 6.11.1 Rationale: 894 Many IDSs contain thresholds to determine whether or not to generate 895 an alert. This might influence the degree of confidence one has in 896 the report or perhaps would indicate the likelihood of the report 897 being a false alarm. 899 6.11.2 Scenario: 901 The alarm threshold monitor is set at a low level to indicate that an 902 organization wants reports on any suspicious activity, regardless of 903 the probability of a real attack. The degree of confidence measure 904 is used to indicate if this is a low probability or high probability 905 event. 907 6.12 Alert Identification 909 The IDMEF message MUST be uniquely identifiable in that it can be 910 distinguished from other IDMEF messages. 912 6.12.1 Rationale: 914 An IDMEF message might be sent by multiple geographically-distributed 915 analyzers at different times. A unique identifier will allow an 916 IDMEF message to be identified efficiently for data reduction and 917 correlation purposes. 919 6.12.2 Scenario: 921 The unique identifier might consist of a unique originator identifier 922 (e.g. IPv4 or IPv6 address) concatenated with a unique sequence 923 number generated by the originator. In a typical IDS deployment, a 924 low-level event analyzer will log the raw sensor information into, 925 e.g., a database while analyzing and reporting results to higher 926 levels. In this case, the unique raw message identifier can be 927 included in the result message as supporting evidence. Higher level 928 analyzers can later use this identifier to retrieve the raw message 929 from the database if necessary. 931 6.13 Alert Creation Date and Time 933 The IDMEF MUST support reporting alert creation date and time in each 934 event, where the creation date and time refer to the date and time 935 that the analyzer decided to create an alert. The IDMEF MAY support 936 additional dates and times, such as the date and time the event 937 reference by the alert began. 939 6.13.1 Rationale: 941 Time is important from both a reporting and correlation point of 942 view. Event onset time might differ from the alert creation time 943 because it might take some time for the sensor to accumulate 944 information about a monitored activity before generating the event, 945 and additional time for the analyzer to receive the event and create 946 an alert. The event onset time is therefore more representative of 947 the actual time that the reported activity began than is the alert 948 creation time. 950 6.13.2 Scenario: 952 If an event is reported in the quiet hours of the night, the operator 953 might assign a higher priority to it than she would to the same event 954 reported in the busy hours of the day. Furthermore, an event (like a 955 lengthy port scan) may take place over a long period of time and it 956 would be useful for the analyzer to report the time of the alert as 957 well as the time the event began. 959 6.14 Time Synchronization 961 Time SHALL be reported such that events from multiple analyzers in 962 different time zones can be received by the same manager and that the 963 local time at the analyzer can be inferred. 965 6.14.1 Rationale: 967 For event correlation purposes, it is important that the manager be 968 able to normalize the time information reported in the IDMEF alerts. 970 6.14.2 Scenario: 972 A distributed ID system has analyzers located in multiple timezones, 973 all reporting to a single manager. An intrusion occurs that spans 974 multiple timezones as well as multiple analyzers. The central 975 manager requires sufficient information to normalize these alerts and 976 determine that all were reported near the same "time" and that they 977 are part of the same attack. 979 6.15 Time Format 981 The format for reporting the date MUST be compliant with all current 982 standards for Year 2000 rollover, and it MUST have sufficient 983 capability to continue reporting date values past the year 2038. 985 6.15.1 Rationale: 987 It is desirable that the IDMEF have a long lifetime and that 988 implementations be suitable for use in a variety of environments. 989 Therefore, characteristics that limit the lifespan of the IDMEF (such 990 as 2038 date representation limitation) MUST be avoided. 992 6.16 Time Granularity and Accuracy 994 Time granularity and time accuracy in event messages SHALL NOT be 995 specified by the IDMEF. 997 6.16.1 Rationale: 999 The IDMEF cannot assume a certain clock granularity on sensing 1000 elements, and so cannot impose any requirements on the granularity of 1001 the event timestamps. Nor can the IDMEF assume that the clocks being 1002 used to timestamp the events have a specified accuracy. 1004 6.17 Message Extensions 1006 The IDMEF message MUST support an extension mechanism used by 1007 implementors to define implementation-specific data. The use of this 1008 mechanism by the implementor is OPTIONAL. This data contains 1009 implementation-specific information determined by each implementor. 1010 The implementor MUST indicate how to interpret these extensions, 1011 although there are no specific requirements placed on how 1012 implementors describe their implementation-specific extensions. The 1013 lack or presence of such message extensions for implementation- 1014 specific data MUST NOT break interoperation. 1016 6.17.1 Rationale: 1018 Implementors might wish to supply extra data such as the version 1019 number of their product or other data that they believe provides 1020 value added due to the specific nature of their product. 1021 Implementors may publish a document or web site describing their 1022 extensions; they might also use an in-band extension mechanism that 1023 is self-describing. Such extensions are not a license to break the 1024 interoperation of IDMEF messages. 1026 6.18 Message Semantics 1028 The semantics of the IDMEF message MUST be well defined. 1030 6.18.1 Rationale: 1032 Good semantics are key to understanding what the message is trying to 1033 convey so there are no errors. Operators will decide what action to 1034 take based on these messages, so it is important that they can 1035 interpret them correctly. 1037 6.18.2 Scenario: 1039 Without this requirement, the operator receives an IDMEF message and 1040 interprets it one way. The implementor who constructed the message 1041 intended it to have a different meaning from the operator's 1042 interpretation. The resulting corrective action is, therefore, 1043 incorrect. 1045 6.19 Message Extensibility 1047 The IDMEF itself MUST be extensible. As new ID technologies emerge 1048 and as new information about events becomes available, the IDMEF 1049 message format MUST be able to include this new information. Such 1050 message extensibility must occur in such a manner that 1051 interoperability is NOT impacted. 1053 6.19.1 Rationale: 1055 As intrusion detection technology continues to evolve, it is likely 1056 that additional information relating to detected events will become 1057 available. The IDMEF message format MUST be able to be extended by a 1058 specific implementation to encompass this new information. Such 1059 extensions are not a license to break the interoperation of IDMEF 1060 messages. 1062 7. Security Considerations 1064 This document does not treat security matters, except that Section 5 1065 specifies security requirements for the protocols to be developed. 1067 Informative References 1069 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1070 9, RFC 2026, October 1996. 1072 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1073 Levels", BCP 14, RFC 2119, March 1997. 1075 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 1076 BCP 18, RFC 2277, January 1998. 1078 [4] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. 1080 Authors' Addresses 1082 Mark Wood 1083 Internet Security Systems, Inc 1084 6303 Barfield Road 1085 Atlanta, GA 30328 1086 US 1088 EMail: mark1@iss.net 1090 Michael A. Erlinger 1091 Harvey Mudd College 1092 Computer Science Dept 1093 301 East 12th Street 1094 Claremont, CA 91711 1095 US 1097 EMail: mike@cs.hmc.edu 1098 URI: http://www.cs.hmc.edu/ 1100 Appendix A. History of Significant Changes 1102 The RFC Editor should remove this section and its corresponding TOC 1103 references prior to publication. 1105 A.1 Significant Changes Since requirements-09 1107 Change section 6.17, Message Extensions, to indicate that such 1108 extensions CANNOT affect interoperability 1110 Change section 6.19, Message Extensions, to indicate that such 1111 extensions CANNOT affect interoperability 1113 Add a Reference Section and some related anchors 1115 Appendix B. Acknowledgements 1117 The following individuals contributed substantially to this document 1118 and should be recognized for their efforts. This document would not 1119 exist without their help: 1121 Mark Crosbie, Hewlett-Packard 1123 David Curry, IBM Emergency Response Services 1125 David Donahoo, Air Force Information Warfare Center 1127 Mike Erlinger, Harvey Mudd College 1129 Fengmin Gong, Microcomputing Center of North Carolina 1131 Dipankar Gupta, Hewlett-Packard 1133 Glenn Mansfield, Cyber Solutions, Inc. 1135 Jed Pickel, CERT Coordination Center 1137 Stuart Staniford-Chen, Silicon Defense 1139 Maureen Stillman, Nokia IP Telephony 1141 Full Copyright Statement 1143 Copyright (C) The Internet Society (2002). All Rights Reserved. 1145 This document and translations of it may be copied and furnished to 1146 others, and derivative works that comment on or otherwise explain it 1147 or assist in its implementation may be prepared, copied, published 1148 and distributed, in whole or in part, without restriction of any 1149 kind, provided that the above copyright notice and this paragraph are 1150 included on all such copies and derivative works. However, this 1151 document itself may not be modified in any way, such as by removing 1152 the copyright notice or references to the Internet Society or other 1153 Internet organizations, except as needed for the purpose of 1154 developing Internet standards in which case the procedures for 1155 copyrights defined in the Internet Standards process must be 1156 followed, or as required to translate it into languages other than 1157 English. 1159 The limited permissions granted above are perpetual and will not be 1160 revoked by the Internet Society or its successors or assigns. 1162 This document and the information contained herein is provided on an 1163 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1164 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1165 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1166 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1167 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1169 Acknowledgement 1171 Funding for the RFC Editor function is currently provided by the 1172 Internet Society.