idnits 2.17.1 draft-wierzbicki-cidss-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 34. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1205. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 3) being 59 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Here we present a sample signature in CIDSS format. Elements of this signature have been used as examples in the previous sections. (This appendix MAY NOT be compatible with Internet Draft formatting). -- 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 2004) is 7134 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) -- Looks like a reference, but probably isn't: 'FSRPAU120' on line 444 == Unused Reference: '1' is defined on line 1329, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1332, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1354, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-idwg-idmef-xml-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-idwg-idmef-xml (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Wierzbicki 3 J. Kalinski 4 T. Kruszona 5 Document: draft-wierzbicki-cidss-00.txt Polish-Japanese 6 Institute of 7 Information 8 Technology 9 Expires: April 2005 October 2004 11 Common Intrusion Detection Signatures Standard 13 Status of this Memo 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsolete by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 By submitting this Internet-Draft, we certify that any applicable 32 patent or other IPR claims of which we are aware have been disclosed, 33 or will be disclosed, and any of which we become aware will be 34 disclosed, in accordance with RFC 3668. 36 Distribution of this memo is unlimited. 38 Abstract 40 The purpose of the Common Intrusion Detection Signatures Standard 41 (CIDSS) is to define a common data format for storing signatures from 42 different intrusion detection systems. 44 This Internet-Draft describes a common data format to represent 45 information contained in signatures of intrusion detection systems, 46 and explains the rationale for using this common format. The proposed 47 format is a dialect of the Extensible Markup Language (XML). An XML 48 Document Type Definition is developed, and examples are provided. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119. 56 Table of Contents 58 Status of this Memo...............................................1 59 Abstract..........................................................1 60 Conventions used in this document.................................2 61 Table of Contents.................................................2 62 1. Introduction...................................................2 63 1.1 About CIDSS................................................2 64 1.2 Potential Applications of CIDSS............................3 65 2. XML CIDSS Signatures...........................................4 66 2.1 Structure of a CIDSS document..............................4 67 2.2 Structure of a CIDSS signature.............................4 68 2.3 Data types used by the Pattern_Content element.............5 69 2.4 Logical expressions used in CIDSS signature definitions....5 70 2.5 XML elements and attributes used in CIDSS..................6 71 3. Security Considerations.......................................23 72 Copyright Notice.................................................24 73 Intellectual Property Statement..................................24 74 Appendix A.......................................................25 75 Appendix B.......................................................27 76 References.......................................................27 77 Author's Addresses...............................................28 78 Comments to:.....................................................28 80 1. Introduction 82 1.1 About CIDSS 84 Common Intrusion Detection Signatures Standard is intended to be a 85 standard format of signatures used widely in Network Intrusion 86 Detection Systems (NIDS). An IDS is controlled by a set of decision 87 rules. A decision rule of an IDS is composed of two components: a 88 description of specific characteristics of an intrusion attempt (a 89 signature) and an action that has to be carried out when the data 90 provided by IDS sensors matches the signature. This document focuses 91 on the remaining part of an IDS decision rule: the IDS signature. 93 Currently, every IDS uses a different format of signatures. CIDSS 94 defines a common format of signatures that attempts to express all 95 information contained in signatures of various IDS. The CIDSS 96 signature format is based on XML to facilitate the adaptation and 97 applications of the proposed standard. The CIDSS signature format is 98 designed to be extensible, and therefore it SHOULD be simple to 99 incorporate features of future and current IDS systems that have not 100 been taken into account in the first design. 102 The main goal of CIDSS is to enable administrators of IDS systems to 103 share, compare, evaluate and criticize signatures used to detect 104 intrusion events. The increasingly dynamic, global, and frequent 105 nature of intrusion attempts is a trend that forces administrators to 106 greater efforts to protect increasingly valuable information. The 107 possibility to disseminate knowledge and experience about IDS 108 systems' operation would be enhanced by the introduction of a common 109 signature format. Therefore the use of a common IDS signature format 110 SHOULD lead to a greater security of information. Other possible 111 applications of CIDSS will be discussed in the next section. 113 CIDSS Homepage: http://cidss.b59.net 115 1.2 Potential Applications of CIDSS 117 One of the main applications of CIDSS is the translation of 118 signatures between various IDS. The ability to translate a signature 119 of an IDS into the common data format and to carry out a reverse 120 translation implies that it SHOULD be possible to translate 121 signatures of different IDS using the common data format as an 122 intermediate form. The development of this standard has been carried 123 out in parallel with the development of an IDS signature translator. 124 Currently, the translator is able to translate signatures of Snort 125 [5] and Dragon [6] IDS into the common format, and among the three 126 systems. It's also partially tested with: Shoki [8], ISS 127 RealSecure(TM) [11], and Cisco NetRanger(TM) [12]. The IDS translator 128 is developed under the GNU General Public License and is available 129 from http://translator.b59.net. 131 Another possible application of CIDSS would be the creation and 132 maintenance of signature databases by independent providers of IDS 133 signatures. The use of XML as a base for the common signature format 134 enables a simple integration of collections of signatures into a 135 database. This SHOULD improve the searching and management of a 136 signature collection. The business model of an independent signature 137 provider could be the delivery of up-to-date, comprehensive signature 138 collections to increase security of specific services, systems and 139 platforms. 141 Wierzbicki et al. Expires 142 ------------------------------------- 143 | First part of a signature | 144 | ... |<-------|--| 145 | ... |<-------|--| 146 | ... |<-------|--| 147 | ... |<-------|--| 148 ------------------------------------- | | 149 ------------------------------------------- | | 150 | Second part of a signature | | | 151 | | | | 152 | ... | | | 153 | ... | | | 154 | | | | 155 | ... | | | 156 | | | | 157 | ...|----- | 158 | | | 159 | ... |--------- 160 | | 161 | | 162 ------------------------------------------- 164 Figure 1 The main components and logical structure of a CIDSS 165 signature 167 2. XML CIDSS Signatures 169 This section describes the logical and structural rules for creating 170 signatures in CIDSS format. Each XML element and attribute used in 171 the CIDSS format are described and explained on examples. In appendix 172 A, a full CIDSS signature is provided that has been used to provide 173 the examples used in this section. 174 CIDSS meets XML ver. 1.0 requirements [9]. CIDSS is defined as a 175 dialect of XML using the XML Schema Definition (XSD). The schema of 176 CIDSS is an appendix to this document (see appendix B: CIDSS XSD 177 schema. cidss.xsd) 179 2.1 Structure of a CIDSS document 181 A CIDSS document is a collection of signatures. Each signature is 182 independent, and can be stored in a separate CIDSS document or 183 together with other signatures. The main XML element of a CIDS 184 document is the "Signatures" element. 186 2.2 Structure of a CIDSS signature 188 A CIDSS signature is composed of several XML elements, contained in a 189 common "Signature" element. A signature can be divided into two 190 basic, logical parts. The first part, that includes (among others) 191 the elements "Sources", "Destinations", "Protocols" and "Patterns", 192 is used to define building blocks of a signature definition. These 193 blocks are combined in the second part of a signature, and are kept 194 separate in order to shorten the signature definition and avoid 195 redundancy. For instance, the definition of relevant information 196 about the TCP protocol might be kept inside the "Protocols" element 197 and might be later combined with several patterns (defined inside the 198 "Patterns" element). Rather than repeat the definition of the TCP 199 protocol each time a new pattern is used, the signature definition 200 will refer to the information kept inside the "Protocols" element. 201 The second part of a signature contains information on how to use the 202 building blocks defined in the first part. The main XML element of 203 the second part of a signature is the "Session" element. A "Session" 204 element defines the main signature behavior. A signature MAY use 205 state managed by the IDS for a certain flow of packets (or session). 206 However, it is possible to create stateless signatures, by omitting 207 information REQUIRED for the state mechanisms to work. Then, the 208 information contained in a "Session" element defines the conditions 209 that MUST be fulfilled by sensor data in order to trigger the 210 signature. 211 In the second part of a signature, the information contained in the 212 first part is combined using logical expressions. Each element in the 213 first part of a signature that contains a "building block" for the 214 signature definition MUST have an identifier that is unique in the 215 signature (not necessarily in the CIDSS document that contains the 216 signature). This identifier can be used in the second part of a 217 signature to refer to the "building block" defined by this element. 218 The building blocks MAY be combined using logical expressions that 219 are constructed by the "AND" and "OR" operators. The logical 220 expressions are contained in special tags, and are treated as strings 221 by the XML parser. CIDSS logical expressions are described in section 222 2.4. 224 2.3 Data types used by the Pattern_Content element 226 The data types used in CIDSS signatures are compatible with the 227 XML[9] and XML Schema (XSD) [10] specification. The following data 228 types are supported: 230 - String values 231 You MUST use encoding defined by "encoding" attribute (e.g. ). UTF-8 RECOMMENDED. Refer to 233 Appendix A and Appendix B 234 - Hexadecimal values 235 - Decimal values 237 2.4 Logical expressions used in CIDSS signature definitions 239 Some elements in the CIDSS signature contain information that 240 describes how other elements MUST be combined in the signature 241 definitions. The content of these elements is a String value that 242 contains a logical expression. A translating software MUST be able to 243 process these expressions. 244 CIDSS logical expressions MUST use operators "AND", "OR", and "NOT" 245 (uppercase). The operators are interpreted as follows: 247 - AND - logical conjunction 248 - OR - logical alternative 249 - NOT - logical negation 251 The operator precedence in CIDSS logical expressions MUST be 252 interpreted as follows: NOT precedes AND precedes OR. 253 CIDSS logical expressions MAY contain ordinary braces "(" or ")" that 254 are interpreted as in logical expressions. 255 Apart from braces and operators, CIDSS logical expressions MUST 256 contain unique identifiers of other XML elements in the CIDSS 257 signature definition that MAY be used in logical expressions. 259 2.5 XML elements and attributes used in CIDSS 261 In this section, all XML elements defined by the CIDSS standard SHALL 262 be introduced. Each element will be defined using a common template 263 to simplify a presentation. This template is explained below: 265 Element name 267 Element description. 268 Presence: [mandatory | optional, single | multiple] 269 Location: element name 270 Attributes: attribute name [type [, unique]] 271 Contained elements: element names 273 mandatory - means that the element MUST exist in the signature 274 optional - the element MAY exist in the signature 275 single - if the element exists in the signature, then this element 276 MUST exist in exactly one instance 277 multiple - if the element exists in the signature, then this element 278 MAY exist many instances 279 unique - value of the element MUST NOT be repeated as value of the 280 same element in other place 282 Signatures 284 A root element of a CIDSS XML document. 286 Presence: mandatory, single 287 Location: root element 288 Contained elements: Signature [multiple, mandatory] 289 Example: 290 292 where "" SHOULD be replaced by the filename of the 293 XSD schema file (e.g. cidss.xsd) 295 Signature 297 This element contains all information about a signature. 299 Presence: mandatory 300 Location: element Signatures 301 Attributes: SID [type: integer; single, mandatory, unique] 302 Contained elements: Enabled [single, mandatory], Sig_Source [single, 303 optional], Description [single, optional], Action [single, optional], 304 Protocols [multiple, mandatory], Sources [multiple, mandatory], 305 Destinations [multiple, mandatory], Patterns [single, mandatory], 306 Logged_Packets [single, optional], Message [single, optional], 307 Comment [multiple, optional] 308 Example: See Appendix A 310 Enabled 312 Defines a current signature state. Setting this to true, the 313 signature will be analyzed by the IDS. Otherwise the signature SHOULD 314 be skipped. 316 Presence: mandatory 317 Type: Boolean 318 Default value: true 319 Location: element Signature 320 Example: true 322 Sig_Source 324 Optional element for use in translators. Specifies the IDS from which 325 the signature was translated or ported. This element SHOULD contain 326 string that identifies a signature source. 328 Presence: optional 329 Type: String 330 Location: element Signature 331 Example: Snort 333 Description 335 This element MAY contain a simple description of the signature. 337 Presence: optional 338 Type: String 339 Location: element Signature 340 Example: Try to get passwd file using ftp 341 protocol 343 Action 345 MAY define actions performed by an IDS after intrusion detection 346 Suggested values: drop, allow, alert, and warning. 348 Wierzbicki et al. Expires 349 Presence: optional, single 350 Type: String 351 Location: element Signature 352 Example: alert 354 Protocols 356 This element contains description of multiple protocols used in 357 potential attack. 359 Location: Signature 360 Presence: mandatory, multiple 361 Attributes: ID[integer,unique] 363 Protocol 365 The element used to describe the network protocol. Options of the 366 protocol used in this element depend on a protocol type. 367 The Proto_ID attribute is used for identification in the Proto_Logic 368 element - it is REQUIRED only when there is more than one Protocol in 369 the Protocols element. 371 Presence: mandatory, multiple. 372 Type: String 373 Attributes: Proto_ID [integer, unique], Type [enum: tcp, udp, ip, 374 icmp, application] 375 Location: element Signature 376 Contained elements: TCP_Ack [single, optional], TCP_State [single, 377 optional], TCP_Seq [single, optional], TCP_Dsize [single, optional], 378 TCP_Flags [single, optional], TCP_Window [single, optional], 379 UDP_Dsize [single, optional], ICMP_Dsize [single, optional], 380 ICMP_Icmp_Id [single, optional], ICMP_Icmp_Seq [single, optional], 381 ICMP_Icode [single, optional], ICMP_Itype [single, optional], IP_Ttl 382 [single, optional], IP_Tos [single, optional], IP_Ipopts [single, 383 optional], IP_Fragbits [single, optional], IP_Id [single, optional], 384 IP_Ip_Proto [single, optional], IP_Dsize [single, optional], Isdataat 385 [single, optional], Rpc [single, optional] 387 Isdataat 389 Checks that the data fields in the packet are in the specified 390 offset. 392 Allowed values: Integer or integer (more than a given value) 394 Location: Protocol 395 Presence: single, optional 396 Example: <5 398 Rpc 400 This element specifies the RPC application, version, and procedure 401 numbers in SUNRCP call requests. It MUST contain a string in the 402 following format: 404 Allowed format: , [|*], 405 [|*]> 406 Location: Protocol, Type=="Application" 407 Presence: single, optional 408 Type: String 409 Example: 100000,*,3 411 TCP_Ack 413 Checks the specific TCP ack number 415 Location: Protocol, Type=="TCP" 416 Presence: single, optional 417 Type: integer 418 Example: 0 420 TCP_Seq 422 Checks the specific TCP seq number 424 Location: Protocol, Type=="TCP" 425 Presence: single, optional 426 Type: integer 427 Example: TCP_Seq>0 429 TCP_State 431 Describes current protocol state e.g. established, stateless 433 Location: Protocol, Type=="TCP" 434 Allowed values: [established|stateless] 435 Presence: single, optional 436 Type: string 437 Example: established 439 TCP_Flags 441 Check if the specific TCP Flags are present 443 Location: Protocol, Type=="TCP" 444 Allowed values: [!|*|+][FSRPAU120] 445 Values description: F-FIN, S-SYN, R-RST, P-PSH, A-ACK, U-URG, 1- 446 Reserved bit 1, 2-Reserved bit 2, 0-No Flags set. 447 Modifiers description: + - match on the specific bits, plus any 448 others, * - match if any of the specified bits are set, ! - match if 449 specified bits are not set 451 Wierzbicki et al. Expires - April 2005 452 Presence: multiple, optional 453 Type: String 454 Example: +SA 456 TCP_Window 458 Checks value of the TCP window size 460 Location: Protocol, Type=="TCP" 461 Presence: single, optional 462 Type: integer 463 Example: 34000 465 TCP_Dsize 467 Checks the packet data field size in TCP protocol 469 Allowed signs: <, >, <=, >=, number 470 Location: Protocol, Type=="TCP" 471 Presence: single, optional 472 Type: String 473 Example: <=40000 475 UDP_Dsize 477 Checks packet data field size in UDP protocol 479 Allowed signs: <, >, <=, >=, number 480 Location: Protocol, Type=="UDP" 481 Presence: single, optional 482 Type: String 483 Example: <=33400 485 ICMP_Dsize 487 Checks the packet data field size in ICMP protocol 489 Allowed signs: <, >, <=, >=, number 490 Location: Protocol, Type=="ICMP" 491 Presence: single, optional 492 Type: String 493 Example: >=64 495 ICMP_Icmp_Id 497 Checks the value of specific ICMP ID 499 Location: Protocol, Type=="ICMP" 500 Presence: single, optional 501 Type: integer 502 Example: 0 504 ICMP_Icmp_Seq 506 Checks the value of ICMP sequence 508 Location: Protocol, Type=="ICMP" 509 Presence: single, optional 510 Type: integer 511 Example: 0 513 ICMP_Icode 515 Checks the value of specific ICMP code 517 Allowed signs: <, >, number 518 Location: Protocol, Type=="ICMP" 519 Presence: single, optional 520 Type: String 521 Example: >25 523 ICMP_Itype 525 Checks the value of specified ICMP type 527 Allowed signs: <, >, number 528 Location: Protocol, Type=="ICMP" 529 Presence: single, optional 530 Type: String 531 Example: >25 533 IP_Ttl 535 Specifies IP time-to-live value 537 Allowed signs: <, >, <=, >=,-, number 538 Location: Protocol, Type=="IP" 539 Presence: single, optional 540 Type: string 541 Example: 6-8 - values between 6 and 8 543 IP_Tos 545 Check the IP ToS field for specified value 546 Location: Protocol, Type=="IP" 548 Presence: single, optional 549 Type: integer 550 Example: 2 552 IP_Fragbits 554 Checks fragmentations bits for the specified value 555 Location: Protocol, Type=="IP" 556 Presence: single, optional 557 Type: String 558 Example: DM+ 560 IP_Id 562 Checks ID field in IP protocol for the specified value 564 Location: Protocol, Type=="IP" 565 Presence: single, optional 566 Type: integer 567 Example: 34222 569 IP_Ipopts 571 This element checks if the specified IP option is present. 573 Allowed values: rr - Record route, eol - end of list, nop - no op, ts 574 - Time Stamp, sec - IP security option, lsrr - Loose source routing, 575 ssrr - Strict source routing, satid - Stream identifier, any - any IP 576 options are set 577 Location: Protocol, Type=="IP" 578 Presence: single, optional 579 Type: String 580 Example: lsrr 582 IP_Dsize 584 Checks size of packet data field 586 Allowed signs: <, >, <=, >=, number 587 Location: Protocol, Type=="IP" 588 Presence: single, optional 589 Type: String 590 Example: 34000 592 IP_Ip_Proto 594 Checks IP protocol header for the specified value 596 Allowed signs: <, >, <=, >=, number, name 597 Location: Protocol, Type=="IP" 598 Presence: single, optional 599 Type: String 600 Example: igmp 602 Proto_Logic 604 This element describes logical rules to combine the information in 605 Protocol elements contained in one Protocols element. Logical 606 operators in Proto Logic element are described in section 2.4. 608 Presence: optional, single 609 Location: element Patterns 610 Example: 1 OR (2 AND 3) 612 Sources 614 This element contains information that describes properties of a 615 source of network communications. If Sources occurs more then once, 616 then every Sourcs MUST have an unique id (attribute) used in 617 Src_Logic that defines logical dependences between each of them. 619 Presence: mandatory, multiple 620 Location: element Signature 621 Attributes: ID 622 Contained elements: Source[multiple, mandatory], Src_Logic [single, 623 optional] 624 Example: See Appendix A 626 Source 628 This element contains descriptions of source hosts. Src_ID attribute 629 is local (in one Sources element) id for use with the Src_Logic 630 element. 632 Presence: mandatory, multiple 633 Location: element Sources 634 Attributes: Src_ID [presence: mandatory if more than one Source_ in 635 one Sources element, type: integer, unique] 636 Contained elements: Source_IP[single, mandatory], Source_Port[single, 637 optional] 638 Example: See Appendix 640 Destinations 642 This element contains information that describes properties of a 643 destination of network communications. If Destinations occurs more 644 then once, then every Destination MUST have an unique id (attribute) 645 used in Dst_Logic to define logical dependences between each of them. 647 Presence: mandatory, multiple 648 Location: element Signature 649 Contained elements: Destination [multiple, mandatory] 650 Example: See Appendix A 652 Destination 654 This element contains descriptions of destination hosts. Dst_ID 655 attribute is local (in one Destinations element) id for use with the 656 Dst_Logic element. 658 Presence: mandatory, multiple 659 Location: element Destinations 660 Attributes: Dst_ID [presence: mandatory if more than one Destination_ 661 in one Destinations element, type: integer, unique] 662 Contained elements: Destination_IP [single, mandatory], 663 Destination_Port [single, optional] 664 Example: See Appendix A 666 Source_IP 668 This element contains an IPv4 or IPv6 network address in any 669 notation. The value "any" means that all addresses will be considered 670 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 671 value of Neg attribute is "true", then the values specified in the 672 Source_IP element are interpreted as addresses that MUST NOT match 673 the source address in order for the signature to apply. Mask 674 attribute defines IP mask for current IP. 676 Allowed values: Any string 677 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 678 true|false, default: false], Mask [presence: mandatory, type: string, 679 allowed values: mask in octet or bit notation] 680 Presence: mandatory, single 681 Type: String 682 Location: element Source 683 Example: $EXTERNAL_NET 684 Variable $EXTERNAL_NET is defined in an IDS. (e.g. 685 $EXTERNAL_NET=1.2.3.4) 687 Destination_IP 689 This element contains an IPv4 or IPv6 network address in any 690 notation. The value "any" means that all addresses will be considered 691 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 692 value of Neg attribute is "true", then the values specified in the 693 Destination_IP element are interpreted as addresses that MUST NOT 694 match the source address in order for the signature to apply. Mask 695 attribute defines IP mask for current IP. 697 Allowed values: Any string 698 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 699 true|false, default: false], Mask [presence: mandatory, type: string, 700 allowed values: mask in octet or bit notation] 701 Presence: mandatory, single 702 Type: String 703 Location: element Destination 704 Example: Similar as in Source_IP element 706 Source_Port 708 The value of this element is a port number or range of ports 709 expressed by two port numbers divided with a ":" sign. The "135:139" 710 expression means that all ports between 135 and 139 will be 711 considered, accounting ports 135 and 139. The value "any" means that 712 all ports will be considered. 713 Presence: If Protocol Type is set to tcp, udp or ip then mandatory, 714 if Protocol Type value is icmp then MUST NOT be set. 716 Type: String 717 Location: element Source 718 Example: any 720 Destination_Port 722 The value of this element is a port number or range of ports 723 expressed by two port numbers divided with a ":" sign. The "135:139" 724 expression means that all ports between 135 and 139 will be 725 considered, accounting ports 135 and 139. The value "any" means that 726 all ports will be considered. 728 Presence: If Protocol Type value is set to tcp, udp or ip then 729 mandatory, if Protocol Type value is icmp then MUST NOT be set. 730 Type: String 731 Location: element Destination 732 Example: 445 734 Src_Logic 736 Defines logical dependences between each Source description. Logical 737 operators: (, ), AND, OR 739 Location: Sources 740 Example: 2 OR (1 AND 3) 742 Dst_Logic 744 Defines logical dependences between each Destination description. 745 Logical operators: (, ), AND, OR 747 Location: Destinations 748 Example: 1 AND 2 750 Patterns 752 This element contains multiple Pattern elements. 754 Presence: mandatory, if Protocol is to tcp, udp, ip or application 755 than element is present. 757 Location: element Signature 758 Contained elements: Pattern [multiple, optional] 759 Attributes: ID[integer, unique] 760 Example: See Appendix A 762 Pattern 764 This element contains information about the content of a packet that 765 is considered as potentially dangerous. Attribute Pat_ID is used in 766 Pat_Logic element to define logical expressions using multiple 767 Pattern elements 769 Presence: mandatory, multiple 770 Location: element Patterns 771 Contained elements: Pattern_Type [single, mandatory], Pattern_Content 772 [single, optional], Pattern_Depth [single, optional], 773 Pattern_Uricontent [single, optional], Pattern_Offset [single, 774 optional], Pattern_Within [single, optional], Pattern_Distance 775 [single, optional] 776 Attributes: Pat_ID [integer, unique] 777 Example: See Appendix A 779 Pattern_Type 781 Using CIDSS you can specify patterns in hexadecimal, decimal, or 782 string 784 Presence: mandatory 785 Type: String 786 Location: element Pattern 787 Permitted values: "hex", "dec", "string" 788 Default value: "string" 789 Example: string 791 Pattern_Content 793 Defines packet content that is interpreted as an intrusion and 794 considered dangerous. To define the content, regular expressions can 795 be used in the Pattern_Content element. Regular expression MUST be in 796 the PCRE format (Perl Compatible Regular Expressions) [13]. If 797 Rawbytes attribute value is "true" it means pattern is searched in 798 raw packets ignoring decoding that was done by preprocessors. 800 Presence: mandatory, single 801 Attributes: CaseSensitive [allowed values: true|false, default value: 802 true], Rawbytes [allowed values: true|false, default value: false] 803 Type: Same as value of Pattern_Type 804 Location: element Pattern 805 Example: RETR passwd 807 Pattern_Depth 809 Defines how many bytes of the packet MUST be searched in order to 810 find the content defined in the Pattern_Content element that is 811 contained by the same Pattern element as this element. 813 Presence: optional, single 814 Location: element Pattern 815 Type: Integer 816 Example: 10 818 Pattern_Uricontent 820 This element describes content of packet in URI format. If content is 821 e.g. URL address it MAY be used in clear form in Pattern_Uricontent 822 without special signs. 824 Type: string 825 Location: Pattern 826 Presence: optional, single 827 Example: 828 local/apache/htdocs/ 830 Pattern_Offset 832 Specifies offset in bytes from beginning of packet to search for the 833 pattern. 835 Type: integer 836 Location: Pattern 837 Presence: optional, single 838 Example: 5 840 Pattern_Within 842 Used to describe how many packets are at most between two patterns. 844 Type: integer 845 Location: Pattern 846 Presence: optional, single 847 Example: 4 849 Pattern_Distance 851 Defines how far the IDS SHOULD look into a packet for the specified 852 pattern relative to last match. 854 Type: integer 855 Location: Pattern 856 Presence: optional, single 857 Example: 3 859 Pat_Logic 861 This element describes logical rules to combine the information in 862 Pattern elements contained in one Patterns element. Logical operators 863 in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in 864 section 2.4). 866 Presence: optional, single 867 Location: element Patterns 868 Example: (NOT 1 AND 2) OR 3 870 Logged_Packets 872 Number of packets logged when the system detects an intrusion 874 Presence: optional, single 875 Location: element Signature 876 Example: 0 878 Message 880 Contains the message generated by the IDS when a packet described by 881 this signature was detected. 883 Presence: optional, single 884 Location: element Signature 885 Type: String 886 Example: FTP password file GET request 888 Comment 890 This element MAY be used for additional comments and information 891 about the signature. The element MAY contain additional information 892 about signature vendor, vulnerability description, http links etc. 894 Presence: optional, multiple 895 Location: element Signature 896 Example: Vendor: Arachnids 898 Session 900 Defines a session that could be identified by the signature if the 901 state mechanisms of an IDS could be used. Otherwise, the information 902 contained in this element describes the conditions that MUST be 903 satisfied by the sensor data in order to trigger the signature. 905 Location: Signature 906 Presence: single, mandatory 907 Contained elements: Session_Filter [single, optional], Session_Start 908 [single, optional], Session_End [single, optional], 909 Session_Identification [single, optional], Session_Instructions 910 [single, optional] 911 Session_Filter 913 Contains IDs of Source, Destination, Protocol and Pattern elements, 914 combined using logical expressions in the format described in section 915 2.4. The information contained in this element specifies the 916 conditions that MUST be met by sensor data so that the packet will be 917 included in this session. 919 Location: Session 920 Presence: single, optional 921 Allowed values: CIDSS logical expressions. 923 Session_Start 925 Contains IDs of Source, Destination, Protocol or Pattern elements, 926 combined using logical expressions in the format described in section 927 2.4. The information contained in this element specifies the 928 conditions that MUST be met by sensor data so that the packet will 929 define the beginning of a new session. All session state MUST be 930 reset by the IDS when a new session begins. 932 Location: Session 933 Presence: single, optional 934 Allowed values: CIDSS logical expressions. 936 Session_End 938 Contains IDs of Source, Destination, Protocol or Pattern elements, 939 combined using logical expressions in the format described in section 940 2.4. The information contained in this element specifies the 941 conditions that MUST be met by sensor data so that the packet will 942 define the beginning of a new session. 943 Instead of or in addition to conditions for sensor data, this element 944 MAY include the element Session_Timeout, that specifies a timeout for 945 the session or MAY include Session_Pckt_Count, that defines maximum 946 number of packets considered in current session. When both conditions 947 are specified, then the one that is fulfilled first will terminate 948 the session. 950 Location: Session 951 Presence: single, mandatory if the Session_Start attribute is present 952 Contained elements: Session_Timeout [single, optional], 953 Session_Pckt_Count [single, optional] 955 Session_Pckt_Count 957 Defines maximum number of packets that are considered during session. 959 Presence: single, optional 960 Location: Session_End 962 Wierzbicki et al. Expires 963 Type: Integer 964 Example: 5 965 Session_Timeout 967 Defines a timeout for the session. The time MUST be specified in the 968 format: an integer and a single character (the character MUST be one 969 of: ms,s,m,h - milliseconds, seconds, minutes, hours). 971 Presence: optional, single 972 Type: String 973 Location: Session_End 974 Example: 10s - the timeout for the 975 session is 10 seconds. 977 Session_Identification 979 Defines additional conditions that MUST be met by sensor data so that 980 a packet will be included in this session. These conditions apply 981 after a session has started. For instance, a TCP session will include 982 only the packets that have the same source and destination as the 983 source and destination of packets that started the session. The 984 conditions are specified by including special elements in this 985 element. 987 Location: Session 988 Presence: single, mandatory if the Session_Start attribute is present 989 Contained elements: Same_Source_IP [single, optional], 990 Same_Source_Port [single, optional], Same_Destination_IP [single, 991 optional], Same_Destination_Port [single, optional], Same_Protocol 992 [single, optional], Same_Direction [single, optional] 994 Same_Source_IP 996 If this element is present in Session_Identification, packets that 997 will be included in the session MUST have the same source IP address 998 as the starting packet. 1000 Location: Session_Identification 1002 Same_Source_Port 1004 If this element is present in Session_Identification, packets that 1005 will be included in the session MUST have the same source port as the 1006 starting packet. 1008 Location: Session_Identification 1010 Same_Destination_IP 1012 If this element is present in Session_Identification, packets that 1013 will be included in the session MUST have the same destination IP 1014 address as the starting packet. 1016 Location: Session_Identification 1018 Same_Destination_Port 1020 If this element is present in Session_Identification, packets that 1021 will be included in the session MUST have the same destination port 1022 as the starting packet. 1024 Location: Session_Identification 1026 Same_Protocol 1028 If this element is present in Session_Identification, packets that 1029 will be included in the session MUST be of the same protocol as the 1030 starting packet. 1032 Location: Session_Identification 1034 Same_Direction 1036 If this element is present in Session_Identification, packets that 1037 will be included in the session MUST have been sent in the same 1038 direction as the starting packet. 1040 Location: Session_Identification 1042 Session_Instructions 1044 This element works like a switch statement for the state mechanism of 1045 an IDS. The information contained in this element defines the 1046 statefull behavior of an IDS for this session. The element contains 1047 several Session_Case elements that include conditions for the case to 1048 apply, as well as instructions to be carried out if the case applies. 1049 For efficiency reasons, it is assumed that all conditions for state 1050 instructions will be brought down into a conjunctive normal form (a 1051 logical expression that includes alternatives only at the highest 1052 level). That means that in every case element, all case conditions 1053 are treated as a logical conjunction (logical AND). This ought to 1054 simplify the processing of these instructions. 1056 Location: Session 1057 Presence: single, optional 1058 Contained elements: Session_Case [multiple] 1060 Session_Case 1062 This element contains the conditions and instructions of a case in 1063 the switch statement that is defined by the containing 1064 Session_Instructions element. For readability, the conditions are 1065 split up into three groups: additional conditions for sensor data 1066 that MUST be satisfied so that the packet will apply to this case, 1068 Wierzbicki et al. Expires April 1069 the direction of the packet, and the conditions that MUST be 1070 satisfied by the state variables of a session in order for the case 1071 to apply. The instructions of a case are contained in the mandatory 1072 Case_State_Instructions element. 1074 Location: Session_Instructions 1075 Presence: multiple 1076 Contained elements: Case_Filter [single, optional], Direction 1077 [single, optional], Case_State_Condition [single, optional], 1078 Case_State_Instructions [single, mandatory] 1080 Case_Filter 1082 Contains IDs of Source, Destination, Protocol or Pattern elements, 1083 combined using logical expressions in the format described in section 1084 2.4. The information contained in this element specifies the 1085 conditions that MUST be met by sensor data so that the packet will 1086 apply to this case. 1088 Location: Session_Case 1089 Presence: single, optional 1090 Allowed values: CIDSS logical expressions. 1092 Direction 1094 Defines a direction of network traffic, once a source and destination 1095 of traffic are specified (e.g. after the start of a session). Allowed 1096 values are: "sd" and "ds". If direction value is "sd" it means that 1097 the packet has been sent from source to destination. If the value of 1098 this element is "ds" it means that traffic goes from destination to 1099 source. 1101 Allowed values: sd|ds 1102 Default value: sd 1103 Location: Session_Case 1104 Presence: single, optional 1106 Case_State_Condition 1108 This element contains conditional state expressions that MUST all be 1109 satisfied (evaluate to a boolean value of "true") in order for the 1110 case to apply. These instructions MAY check the values of state 1111 variables stored by the IDS for this session. 1113 Location: Session_Case 1114 Presence: single, optional 1115 Contained elements: Isset_Var, Compare_Var 1117 Case_State_Instructions 1119 This element contains state instructions that MUST all be 1120 sequentially carried out by the IDS if the case applies. These 1121 instructions MAY set, unset or modify the values of state variables 1122 stored by the IDS for this session. 1124 Location: Session_Case 1125 Presence: single, optional 1126 Contained elements: Set_Var, Unset_Var 1128 Isset_Var 1130 A conditional state expression that evaluates to a boolean value of 1131 "true" if the variable of a name that is specified in the "var" 1132 attribute is set in the state of this session. 1134 Location: Case_State_Condition 1135 Presence: multiple, optional 1136 Attributes: var [type: string; single, mandatory] 1138 Compare_Var 1140 Location: Case_State_Condition 1141 Presence: multiple, optional 1142 Attributes: var [type: string; single, mandatory], value [type: 1143 string; single, mandatory] 1145 Set_Var 1147 Location: Case_State_Instructions 1148 Presence: multiple, optional 1149 Attributes: var [type: string; single, mandatory], value [type: 1150 string; single, mandatory] 1152 Unset_Var 1154 Location: Case_State_Instructions 1155 Presence: multiple, optional 1156 Attributes: var [type: string; single, mandatory] 1158 3. Security Considerations 1160 This Internet Draft describes the CIDSS format for storing 1161 information about IDS signatures. The applications of this standard 1162 can raise security concerns, but there are no security concerns 1163 related strictly to the document format. 1165 It is RECOMMENDED that a system for storing CIDSS data SHOULD be 1166 protected against unauthorized access and unauthorized use. The means 1167 for achieving this protection are outside the scope of this document. 1169 Copyright Notice 1171 Copyright (C) The Internet Society (2004). This document is subject 1172 to the rights, licenses and restrictions contained in BCP 78, and 1173 except as set forth therein, the authors retain all their rights. 1175 This document and the information contained herein are provided on an 1176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1178 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1179 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1180 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1183 Intellectual Property Statement 1185 The IETF takes no position regarding the validity or scope of any 1186 Intellectual Property Rights or other rights that might be claimed to 1187 pertain to the implementation or use of the technology described in 1188 this document or the extent to which any license under such rights 1189 might or might not be available; nor does it represent that it has 1190 made any independent effort to identify any such rights. Information 1191 on the procedures with respect to rights in RFC documents can be 1192 found in BCP 78 and BCP 79. 1194 Copies of IPR disclosures made to the IETF Secretariat and any 1195 assurances of licenses to be made available, or the result of an 1196 attempt made to obtain a general license or permission for the use of 1197 such proprietary rights by implementers or users of this 1198 specification can be obtained from the IETF on-line IPR repository at 1199 http://www.ietf.org/ipr. 1201 The IETF invites any interested party to bring to its attention any 1202 copyrights, patents or patent applications, or other proprietary 1203 rights that may cover technology that may be required to implement 1204 this standard. Please address the information to the IETF at 1205 ietf-ipr@ietf.org. 1207 Appendix A 1208 XML CIDSS Document Example 1210 Here we present a sample signature in CIDSS format. Elements of this 1211 signature have been used as examples in the previous sections. (This 1212 appendix MAY NOT be compatible with Internet Draft formatting). 1214 1215 1217 1218 true 1219 snort 1220 alert 1221 NETBIOS SMB-DS DCERPC Remote Activation bind attempt; 1222 sid=2252 1223 NETBIOS SMB-DS DCERPC Remote Activation bind 1224 attempt 1225 reference:cve,CAN-2003-0528; reference:cve,CAN-2003-0605; 1226 reference:cve,CAN-2003-0715; 1227 reference:url,www.microsoft.com/technet/security/bulletin/MS03- 1228 039.mspx; 1229 1230 1231 any 1232 any 1233 1234 1235 10.0.0.0 1236 any 1237 1238 1239 192.168.1.0 1240 any 1241 1242 SRC_1 AND SRC_2 AND SRC_3 1243 1244 1245 1246 any 1247 445 1248 1249 1250 192.168.1.0 1252 445 1253 1254 1255 10.0.0.0 1257 445 1259 1260 DST_1 AND DST_2 AND DST_3 1261 1262 1263 1264 established 1265 1266 PROTO_1 1267 1268 1269 1270 string 1271 |FF|SMB% 1273 5 1274 4 1275 1276 1277 string 1278 &|00| 1280 2 1281 56 1282 1283 1284 string 1285 |5C 1286 00|P|00|I|00|P|00|E|00 5C 00| 1287 12 1288 5 1289 1290 1291 hex 1292 05 1293 1 1294 1295 1296 hex 1297 0B 1298 1 1299 1 1300 1301 1302 string 1303 |B8|J|9F|M|1C|}|CF 11 1304 86 1E 00| |AF|n|7C|W 1305 16 1306 29 1307 1308 PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 AND PAT_5 AND 1309 PAT_6 1310 1311 1312 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND 1313 DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 1314 AND PAT_5 AND PAT_6) 1315 1316 5 1317 1318 1319 1320 1322 Appendix B 1323 The schema of CIDSS - cidss.xsd 1325 Available at http://translator.b59.net/docs/cidss.xsd 1327 References 1329 [1] Bradner S., "Key words for use in RFCs to Indicate 1330 Requirement Levels", BCP 14, RFC 2119, March 1997. 1332 [2] Curry D., Lynch Merrill, Debar H., "The Intrusion 1333 Detection 1334 Message Exchange Format", Internet Draft 1335 draft-ietf-idwg-idmef-xml-11, January 2004, expires July 1336 2004. 1338 [3] McLaughlin Brett, Java & XML, 2nd Edition, 1339 ISBN: 0-596-00197-5 1341 [4] K. Miakisz, Translator i wspolny jezyk sygnatur 1342 systemow wykrywania wlaman (Translator and Common 1343 Intrusion Detection Systems Language), Bachelor thesis, 1344 Polish-Japanese Institute of Information Technology, 1345 2003 1347 [5] Roesch Martin, Green Chris, "Snort Users Manual", Snort 1348 Release 2.1.0, December 2003, http://www.snort.org 1350 [6] "Dragon. Intrusion Detection System. Topics on Writing 1351 Signatures" Enterasys Networks, 2002, 1352 http://dragon.enterasys.com 1354 [7] arachNIDS - Whitehats Network Security Resource, 1355 http://whitehats.com/ids/ 1357 [8] Shoki, "Shoki User's Guide", Release 0.3.0, 1358 http://shoki.sourceforge.net/ 1360 [9] Extensible Markup Language (XML) 1.0, Third Edition, 1361 http://www.w3.org/TR/2004/REC-xml-20040204/ 1363 [10] XML Schema - Specifications and Development, 1364 http://www.w3.org/XML/Schema#dev 1366 [11] ISS - Internet Security Systems, Documentation, 1367 http://www.iss.net/support/documentation/ 1369 [12] Cisco - NetRanger, Documentation, 1370 http://www.cisco.com/univercd/cc/td/doc/product/iaabu/\ 1371 netrangr/ 1373 [13] PCRE - Perl Compatible Regular Expressions, 1374 http://www.pcre.org/ 1376 Author's Addresses 1378 dr Adam Wierzbicki 1379 Polish-Japanese Institute of Information Technology 1380 Koszykowa 86 1381 02-008 Warsaw, Poland 1382 Email: adamw@pjwstk.edu.pl 1384 Jacek Kalinski 1385 Rechniewskiego 6/24 1386 03-980 Warsaw, Poland 1387 Email: jacek@dyski.one.pl 1389 Tomasz Kruszona 1390 Garwolinska 9/83 1391 04-348 Warsaw, Poland 1392 Email: t.kruszona@b59.net 1394 Comments to: 1395 dr Adam Wierzbicki 1396 Polish-Japanese Institute of Information Technology 1397 Koszykowa 86 1398 02-008 Warsaw, Poland 1399 Email: adamw@pjwstk.edu.pl