idnits 2.17.1 draft-wierzbicki-cidss-01.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 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1216. ** 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 1 longer page, the longest (page 19) 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 (March 2005) is 6975 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 443 == Unused Reference: '1' is defined on line 1340, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1343, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1349, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1352, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1365, 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. -------------------------------------------------------------------------------- 1 Intrusion Detection Signatures Working Group 2 Internet Draft A. Wierzbicki 3 J. Kalinski 4 T. Kruszona 5 Document: draft-wierzbicki-cidss-01.txt Polish-Japanese 6 Institute of 7 Information 8 Technology 9 Expires: September 2005 March 2005 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.......................................24 72 Copyright Notice.................................................24 73 Intellectual Property Statement..................................24 74 Appendix A.......................................................26 75 Appendix B.......................................................28 76 References.......................................................28 77 Author's Addresses...............................................29 78 Comments to:.....................................................29 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 ------------------------------------- 142 | First part of a signature | 143 | ... |<-------|--| 144 | ... |<-------|--| 145 | ... |<-------|--| 146 | ... |<-------|--| 147 ------------------------------------- | | 148 ------------------------------------------- | | 149 | Second part of a signature | | | 150 | | | | 151 | ... | | | 152 | ... | | | 153 | | | | 154 | ... | | | 155 | | | | 156 | ...|----- | 157 | | | 158 | ... |--------- 159 | | 160 | | 161 ------------------------------------------- 163 Figure 1 The main components and logical structure of a CIDSS 164 signature 166 2. XML CIDSS Signatures 168 This section describes the logical and structural rules for creating 169 signatures in CIDSS format. Each XML element and attribute used in 170 the CIDSS format are described and explained on examples. In appendix 171 A, a full CIDSS signature is provided that has been used to provide 172 the examples used in this section. 173 CIDSS meets XML ver. 1.0 requirements [9]. CIDSS is defined as a 174 dialect of XML using the XML Schema Definition (XSD). The schema of 175 CIDSS is an appendix to this document (see appendix B: CIDSS XSD 176 schema. cidss.xsd) 178 2.1 Structure of a CIDSS document 180 A CIDSS document is a collection of signatures. Each signature is 181 independent, and can be stored in a separate CIDSS document or 182 together with other signatures. The main XML element of a CIDS 183 document is the _Signatures_ element. 185 2.2 Structure of a CIDSS signature 187 A CIDSS signature is composed of several XML elements, contained in a 188 common _Signature_ element. A signature can be divided into two 189 basic, logical parts. The first part, that includes (among others) 190 the elements _Sources_, _Destinations_, _Protocols_ and _Patterns_, 191 is used to define building blocks of a signature definition. These 192 blocks are combined in the second part of a signature, and are kept 193 separate in order to shorten the signature definition and avoid 194 redundancy. For instance, the definition of relevant information 195 about the TCP protocol might be kept inside the _Protocols_ element 196 and might be later combined with several patterns (defined inside the 197 _Patterns_ element). Rather than repeat the definition of the TCP 198 protocol each time a new pattern is used, the signature definition 199 will refer to the information kept inside the _Protocols_ element. 200 The second part of a signature contains information on how to use the 201 building blocks defined in the first part. The main XML element of 202 the second part of a signature is the _Session_ element. A _Session_ 203 element defines the main signature behavior. A signature MAY use 204 state managed by the IDS for a certain flow of packets (or session). 205 However, it is possible to create stateless signatures, by omitting 206 information REQUIRED for the state mechanisms to work. Then, the 207 information contained in a _Session_ element defines the conditions 208 that MUST be fulfilled by sensor data in order to trigger the 209 signature. 210 In the second part of a signature, the information contained in the 211 first part is combined using logical expressions. Each element in the 212 first part of a signature that contains a _building block_ for the 213 signature definition MUST have an identifier that is unique in the 214 signature (not necessarily in the CIDSS document that contains the 215 signature). This identifier can be used in the second part of a 216 signature to refer to the _building block_ defined by this element. 217 The building blocks MAY be combined using logical expressions that 218 are constructed by the _AND_ and _OR_ operators. The logical 219 expressions are contained in special tags, and are treated as strings 220 by the XML parser. CIDSS logical expressions are described in section 221 2.4. 223 2.3 Data types used by the Pattern_Content element 225 The data types used in CIDSS signatures are compatible with the 226 XML[9] and XML Schema (XSD) [10] specification. The following data 227 types are supported: 229 - String values 230 You MUST use encoding defined by "encoding" attribute (e.g. ). UTF-8 RECOMMENDED. Refer to 232 Appendix A and Appendix B 233 - Hexadecimal values 234 - Decimal values 236 2.4 Logical expressions used in CIDSS signature definitions 238 Some elements in the CIDSS signature contain information that 239 describes how other elements MUST be combined in the signature 240 definitions. The content of these elements is a String value that 241 contains a logical expression. A translating software MUST be able to 242 process these expressions. 243 CIDSS logical expressions MUST use operators _AND_, _OR_, and _NOT_ 244 (uppercase). The operators are interpreted as follows: 246 - AND - logical conjunction 247 - OR - logical alternative 248 - NOT - logical negation 250 The operator precedence in CIDSS logical expressions MUST be 251 interpreted as follows: NOT precedes AND precedes OR. 252 CIDSS logical expressions MAY contain ordinary braces _(_ or _)_ that 253 are interpreted as in logical expressions. 254 Apart from braces and operators, CIDSS logical expressions MUST 255 contain unique identifiers of other XML elements in the CIDSS 256 signature definition that MAY be used in logical expressions. 258 2.5 XML elements and attributes used in CIDSS 260 In this section, all XML elements defined by the CIDSS standard SHALL 261 be introduced. Each element will be defined using a common template 262 to simplify a presentation. This template is explained below: 264 Element name 266 Element description. 267 Presence: [mandatory | optional, single | multiple] 268 Location: element name 269 Attributes: attribute name [type [, unique]] 270 Contained elements: element names 272 mandatory _ means that the element MUST exist in the signature 273 optional _ the element MAY exist in the signature 274 single _ if the element exists in the signature, then this element 275 MUST exist in exactly one instance 276 multiple _ if the element exists in the signature, then this element 277 MAY exist many instances 278 unique _ value of the element MUST NOT be repeated as value of the 279 same element in other place 281 Signatures 283 A root element of a CIDSS XML document. 285 Presence: mandatory, single 286 Location: root element 287 Contained elements: Signature [multiple, mandatory] 288 Example: 289 291 where "" SHOULD be replaced by the filename of the 292 XSD schema file (e.g. cidss.xsd) 294 Signature 296 This element contains all information about a signature. Describes 297 conditions required to identify traffic as suspicious and to take an 298 action. 300 Presence: mandatory 301 Location: element Signatures 302 Attributes: SID [type: integer, single, mandatory, unique] 303 Contained elements: Enabled [single, mandatory], Sig_Source [single, 304 optional], Description [single, optional], Action [single, optional], 305 Protocols [multiple, mandatory], Sources [multiple, mandatory], 306 Destinations [multiple, mandatory], Patterns [single, mandatory], 307 Logged_Packets [single, optional], Message [single, optional], 308 Comment [multiple, optional] 309 Example: See Appendix A 311 Enabled 313 Defines a current signature state. Setting this to true, the 314 signature will be analyzed by the IDS. Otherwise the signature SHOULD 315 be skipped. 317 Presence: mandatory 318 Type: Boolean 319 Default value: true 320 Location: element Signature 321 Example: true 323 Sig_Source 325 Optional element for use in translators. Specifies the IDS from which 326 the signature was translated or ported. This element SHOULD contain 327 string that identifies a signature source. 329 Presence: optional 330 Type: String 331 Location: element Signature 332 Example: Snort 334 Description 336 This element MAY contain a simple description of the signature. 338 Presence: optional 339 Type: String 340 Location: element Signature 341 Example: Try to get passwd file using ftp 342 protocol 344 Action 345 This MAY define actions performed by an IDS after intrusion detection 346 Suggested values: drop, allow, alert, and warning 348 Presence: optional, single 349 Type: String 350 Location: element Signature 351 Example: alert 353 Protocols 355 This element contains description of multiple protocols used in 356 potential attack. 358 Location: Signature 359 Presence: mandatory, multiple 360 Attributes: ID[integer,unique] 362 Protocol 364 The element used to describe the network protocol. Options of the 365 protocol used in this element depend on a protocol type. 366 The Proto_ID attribute is used for identification in the Proto_Logic 367 element _ it is REQUIRED only when there is more than one Protocol in 368 the Protocols element. 370 Presence: mandatory, multiple. 371 Type: String 372 Attributes: Proto_ID [integer, unique], Type [enum: tcp, udp, ip, 373 icmp, application] 374 Location: element Signature 375 Contained elements: TCP_Ack [single, optional], TCP_State [single, 376 optional], TCP_Seq [single, optional], TCP_Dsize [single, optional], 377 TCP_Flags [single, optional], TCP_Window [single, optional], 378 UDP_Dsize [single, optional], ICMP_Dsize [single, optional], 379 ICMP_Icmp_Id [single, optional], ICMP_Icmp_Seq [single, optional], 380 ICMP_Icode [single, optional], ICMP_Itype [single, optional], IP_Ttl 381 [single, optional], IP_Tos [single, optional], IP_Ipopts [single, 382 optional], IP_Fragbits [single, optional], IP_Id [single, optional], 383 IP_Ip_Proto [single, optional], IP_Dsize [single, optional], Isdataat 384 [single, optional], Rpc [single, optional] 386 Isdataat 388 Checks that the data fields in the packet are in the specified 389 offset. 391 Allowed values: Integer or integer (more than a given value) 393 Location: Protocol 394 Presence: single, optional 395 Example: <5 397 Rpc 399 This element specifies the RPC application, version, and procedure 400 numbers in SUNRCP call requests. It MUST contain a string in the 401 following format: 403 Allowed format: , [|*], 404 [|*]> 405 Location: Protocol, Type==_Application_ 406 Presence: single, optional 407 Type: String 408 Example: 100000,*,3 410 TCP_Ack 412 Checks the specific TCP ack number 414 Location: Protocol, Type==_TCP_ 415 Presence: single, optional 416 Type: integer 417 Example: 0 419 TCP_Seq 421 Checks the specific TCP seq number 423 Location: Protocol, Type==_TCP_ 424 Presence: single, optional 425 Type: integer 426 Example: TCP_Seq>0 428 TCP_State 430 Describes current protocol state e.g. established, stateless 432 Location: Protocol, Type==_TCP_ 433 Allowed values: [established|stateless] 434 Presence: single, optional 435 Type: string 436 Example: established 438 TCP_Flags 440 Check if the specific TCP Flags are present 442 Location: Protocol, Type==_TCP_ 443 Allowed values: [!|*|+][FSRPAU120] 444 Values description: F-FIN, S-SYN, R-RST, P-PSH, A-ACK, U-URG, 1- 445 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 450 Presence: multiple, optional 451 Type: String 452 Example: +SA 454 TCP_Window 456 Checks value of the TCP window size 458 Location: Protocol, Type==_TCP_ 459 Presence: single, optional 460 Type: integer 461 Example: 34000 463 TCP_Dsize 465 Checks the packet data field size in TCP protocol 467 Allowed signs: <, >, <=, >=, number 468 Location: Protocol, Type==_TCP_ 469 Presence: single, optional 470 Type: String 471 Example: <=40000 473 UDP_Dsize 475 Checks packet data field size in UDP protocol 477 Allowed signs: <, >, <=, >=, number 478 Location: Protocol, Type==_UDP_ 479 Presence: single, optional 480 Type: String 481 Example: <=33400 483 ICMP_Dsize 485 Checks the packet data field size in ICMP protocol 487 Allowed signs: <, >, <=, >=, number 488 Location: Protocol, Type==_ICMP_ 489 Presence: single, optional 490 Type: String 491 Example: >=64 493 ICMP_Icmp_Id 495 Checks the value of specific ICMP ID 497 Location: Protocol, Type==_ICMP_ 498 Presence: single, optional 499 Type: integer 500 Example: 0 502 ICMP_Icmp_Seq 504 Checks the value of ICMP sequence 506 Location: Protocol, Type==_ICMP_ 507 Presence: single, optional 508 Type: integer 509 Example: 0 511 ICMP_Icode 513 Checks the value of specific ICMP code 515 Allowed signs: <, >, number 516 Location: Protocol, Type==_ICMP_ 517 Presence: single, optional 518 Type: String 519 Example: >25 521 ICMP_Itype 523 Checks the value of specified ICMP type 525 Allowed signs: <, >, number 526 Location: Protocol, Type==_ICMP_ 527 Presence: single, optional 528 Type: String 529 Example: >25 531 IP_Ttl 533 Specifies IP time-to-live value 535 Allowed signs: <, >, <=, >=,-, number 536 Location: Protocol, Type==_IP_ 537 Presence: single, optional 538 Type: string 539 Example: 6-8 - values between 6 and 8 541 IP_Tos 543 Check the IP ToS field for specified value 544 Location: Protocol, Type==_IP_ 546 Presence: single, optional 547 Type: integer 548 Example: 2 550 IP_Fragbits 551 Checks fragmentations bits for the specified value 553 Location: Protocol, Type==_IP_ 554 Presence: single, optional 555 Type: String 556 Example: DM+ 558 IP_Id 560 Checks ID field in IP protocol for the specified value 562 Location: Protocol, Type==_IP_ 563 Presence: single, optional 564 Type: integer 565 Example: 34222 567 IP_Ipopts 569 This element checks if the specified IP option is present. 571 Allowed values: rr _ Record route, eol _ end of list, nop _ no op, ts 572 _ Time Stamp, sec _ IP security option, lsrr _ Loose source routing, 573 ssrr _ Strict source routing, satid _ Stream identifier, any _ any IP 574 options are set 575 Location: Protocol, Type==_IP_ 576 Presence: single, optional 577 Type: String 578 Example: lsrr 580 IP_Dsize 582 Checks size of packet data field 584 Allowed signs: <, >, <=, >=, number 585 Location: Protocol, Type==_IP_ 586 Presence: single, optional 587 Type: String 588 Example: 34000 590 IP_Ip_Proto 592 Checks IP protocol header for the specified value 594 Allowed signs: <, >, <=, >=, number, name 595 Location: Protocol, Type==_IP_ 596 Presence: single, optional 597 Type: String 598 Example: igmp 600 Proto_Logic 601 This element describes logical rules to combine the information in 602 Protocol elements contained in one Protocols element. Logical 603 operators in Proto Logic element are described in section 2.4. 605 Presence: optional, single 606 Location: element Patterns 607 Example: 1 OR (2 AND 3) 609 Sources 611 This element contains information that describes properties of a 612 source of network communications. If Sources occurs more then once, 613 then every Sourcs MUST have an unique id (attribute) used in 614 Src_Logic that defines logical dependences between each of them. 616 Presence: mandatory, multiple 617 Location: element Signature 618 Attributes: ID 619 Contained elements: Source[multiple, mandatory], Src_Logic [single, 620 optional] 621 Example: See Appendix A 623 Source 625 This element contains descriptions of source hosts. Src_ID attribute 626 is local (in one Sources element) id for use with the Src_Logic 627 element. 629 Presence: mandatory, multiple 630 Location: element Sources 631 Attributes: Src_ID [presence: mandatory if more than one Source_ in 632 one Sources element, type: integer, unique] 633 Contained elements: Source_IP[single, mandatory], Source_Port[single, 634 optional] 635 Example: See Appendix 637 Destinations 639 This element contains information that describes properties of a 640 destination of network communications. If Destinations occurs more 641 then once, then every Destination MUST have an unique id (attribute) 642 used in Dst_Logic to define logical dependences between each of them. 644 Presence: mandatory, multiple 645 Location: element Signature 646 Contained elements: Destination [multiple, mandatory] 647 Example: See Appendix A 649 Destination 650 This element contains descriptions of destination hosts. Dst_ID 651 attribute is local (in one Destinations element) id for use with the 652 Dst_Logic element. 654 Presence: mandatory, multiple 655 Location: element Destinations 656 Attributes: Dst_ID [presence: mandatory if more than one Destination_ 657 in one Destinations element, type: integer, unique] 658 Contained elements: Destination_IP [single, mandatory], 659 Destination_Port [single, optional] 660 Example: See Appendix A 662 Source_IP 664 This element contains an IPv4 or IPv6 network address in any 665 notation. The value "any" means that all addresses will be considered 666 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 667 value of Neg attribute is "true", then the values specified in the 668 Source_IP element are interpreted as addresses that MUST NOT match 669 the source address in order for the signature to apply. Mask 670 attribute defines IP mask for current IP. 672 Allowed values: Any string 673 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 674 true|false, default: false], Mask [presence: mandatory, type: string, 675 allowed values: mask in octet or bit notation] 676 Presence: mandatory, single 677 Type: String 678 Location: element Source 679 Example: $EXTERNAL_NET 680 Variable $EXTERNAL_NET is defined in an IDS. (e.g. 681 $EXTERNAL_NET=1.2.3.4) 683 Destination_IP 685 This element contains an IPv4 or IPv6 network address in any 686 notation. The value "any" means that all addresses will be considered 687 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 688 value of Neg attribute is "true", then the values specified in the 689 Destination_IP element are interpreted as addresses that MUST NOT 690 match the source address in order for the signature to apply. Mask 691 attribute defines IP mask for current IP. 693 Allowed values: Any string 694 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 695 true|false, default: false], Mask [presence: mandatory, type: string, 696 allowed values: mask in octet or bit notation] 697 Presence: mandatory, single 698 Type: String 699 Location: element Destination 700 Example: Similar as in Source_IP element 702 Source_Port 704 The value of this element is a port number or range of ports 705 expressed by two port numbers divided with a _:_ sign. The _135:139_ 706 expression means that all ports between 135 and 139 will be 707 considered, accounting ports 135 and 139. The value "any" means that 708 all ports will be considered. 709 Presence: If Protocol Type is set to tcp, udp or ip then mandatory, 710 if Protocol Type value is icmp then MUST NOT be set. 712 Type: String 713 Location: element Source 714 Example: any 716 Destination_Port 718 The value of this element is a port number or range of ports 719 expressed by two port numbers divided with a _:_ sign. The _135:139_ 720 expression means that all ports between 135 and 139 will be 721 considered, accounting ports 135 and 139. The value "any" means that 722 all ports will be considered. 724 Presence: If Protocol Type value is set to tcp, udp or ip then 725 mandatory, if Protocol Type value is icmp then MUST NOT be set. 726 Type: String 727 Location: element Destination 728 Example: 445 730 Src_Logic 732 Defines logical dependences between each Source description. Logical 733 operators: (, ), AND, OR 735 Location: Sources 736 Example: 2 OR (1 AND 3) 738 Dst_Logic 740 Defines logical dependences between each Destination description. 741 Logical operators: (, ), AND, OR 743 Location: Destinations 744 Example: 1 AND 2 746 Patterns 748 This element contains multiple Pattern elements. 750 Presence: mandatory, if Protocol is to tcp, udp, ip or application 751 than element is present. 753 Location: element Signature 754 Contained elements: Pattern [multiple, optional] 755 Attributes: ID[integer, unique] 756 Example: See Appendix A 758 Pattern 760 This element contains information about the content of a packet that 761 is considered as potentially dangerous. Attribute Pat_ID is used in 762 Pat_Logic element to define logical expressions using multiple 763 Pattern elements 765 Presence: mandatory, multiple 766 Location: element Patterns 767 Contained elements: Pattern_Type [single, mandatory], Pattern_Content 768 [single, optional], Pattern_Depth [single, optional], 769 Pattern_Uricontent [single, optional], Pattern_Offset [single, 770 optional], Pattern_Within [single, optional], Pattern_Distance 771 [single, optional] 772 Attributes: Pat_ID [integer, unique] 773 Example: See Appendix A 775 Pattern_Type 777 Using CIDSS you can specify patterns in hexadecimal, decimal, or 778 string 780 Presence: mandatory 781 Type: String 782 Location: element Pattern 783 Permitted values: "hex", "dec", "string" 784 Default value: _string_ 785 Example: string 787 Pattern_Content 789 Defines packet content that is interpreted as an intrusion and 790 considered dangerous. To define the content, regular expressions can 791 be used in the Pattern_Content element. Regular expression MUST be in 792 the PCRE format (Perl Compatible Regular Expressions) [13]. If 793 Rawbytes attribute value is _true_ it means pattern is searched in 794 raw packets ignoring decoding that was done by preprocessors. 796 Presence: mandatory, single 797 Attributes: CaseSensitive [allowed values: true|false, default value: 798 true], Rawbytes [allowed values: true|false, default value: false] 799 Type: Same as value of Pattern_Type 800 Location: element Pattern 801 Example: RETR passwd 803 Pattern_Depth 805 Defines how many bytes of the packet MUST be searched in order to 806 find the content defined in the Pattern_Content element that is 807 contained by the same Pattern element as this element. 809 Presence: optional, single 810 Location: element Pattern 811 Type: Integer 812 Example: 10 814 Pattern_Uricontent 816 This element describes content of packet in URI format. If content is 817 e.g. URL address it MAY be used in clear form in Pattern_Uricontent 818 without special signs. 820 Type: string 821 Location: Pattern 822 Presence: optional, single 823 Example: 824 local/apache/htdocs/ 826 Pattern_Offset 828 Specifies offset in bytes from beginning of packet to search for the 829 pattern. 831 Type: integer 832 Location: Pattern 833 Presence: optional, single 834 Example: 5 836 Pattern_Within 838 Used to describe how many packets MUST be at most between two 839 patterns. 841 Type: integer 842 Location: Pattern 843 Presence: optional, single 844 Example: 4 846 Pattern_Distance 848 Defines how far the IDS SHOULD look into a packet for the specified 849 pattern relative to last match. 851 Type: integer 852 Location: Pattern 853 Presence: optional, single 854 Example: 3 856 Pat_Logic 858 This element describes logical rules to combine the information in 859 Pattern elements contained in one Patterns element. Logical operators 860 in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in 861 section 2.4). 863 Presence: optional, single 864 Location: element Patterns 865 Example: (NOT 1 AND 2) OR 3 867 Logged_Packets 869 Number of packets logged when the system detects an intrusion 871 Presence: optional, single 872 Location: element Signature 873 Example: 0 875 Message 877 Contains the message generated by the IDS when a packet described by 878 this signature was detected. 880 Presence: optional, single 881 Location: element Signature 882 Type: String 883 Example: FTP password file GET request 885 Comment 887 This element MAY be used for additional comments and information 888 about the signature. The element MAY contain additional information 889 about signature vendor, vulnerability description, http links etc. 891 Presence: optional, multiple 892 Location: element Signature 893 Example: Vendor: Arachnids 895 Session 897 Defines a session that could be identified by the signature if the 898 state mechanisms of an IDS could be used. Otherwise, the information 899 contained in this element describes the conditions that MUST be 900 satisfied by the sensor data in order to trigger the signature. 902 Location: Signature 903 Presence: single, mandatory 904 Contained elements: Session_Filter [single, optional], Session_Start 905 [single, optional], Session_End [single, optional], 906 Session_Identification [single, optional], Session_Instructions 907 [single, optional] 909 Session_Filter 911 Contains IDs of Source, Destination, Protocol and Pattern elements, 912 combined using logical expressions in the format described in section 913 2.4. The information contained in this element specifies the 914 conditions that MUST be met by sensor data so that the packet will be 915 included in this session. 917 Location: Session 918 Presence: single, optional 919 Allowed values: CIDSS logical expressions. 921 Session_Start 923 Contains IDs of Source, Destination, Protocol or Pattern elements, 924 combined using logical expressions in the format described in section 925 2.4. The information contained in this element specifies the 926 conditions that MUST be met by sensor data so that the packet will 927 define the beginning of a new session. All session state MUST be 928 reset by the IDS when a new session begins. 930 Location: Session 931 Presence: single, optional 932 Allowed values: CIDSS logical expressions. 934 Session_End 936 Contains IDs of Source, Destination, Protocol or Pattern elements, 937 combined using logical expressions in the format described in section 938 2.4. The information contained in this element specifies the 939 conditions that MUST be met by sensor data so that the packet will 940 define the beginning of a new session. 941 Instead of or in addition to conditions for sensor data, this element 942 MAY include the element Session_Timeout, that specifies a timeout for 943 the session or MAY include Session_Pckt_Count, that defines maximum 944 number of packets considered in current session. When both conditions 945 are specified, then the one that is fulfilled first will terminate 946 the session. 948 Location: Session 949 Presence: single, mandatory if the Session_Start attribute is present 950 Contained elements: Session_Timeout [single, optional], 951 Session_Pckt_Count [single, optional] 953 Session_Pckt_Count 955 Wierzbicki et al. Expires - September 956 Defines maximum number of packets that are considered during session. 958 Presence: single, optional 959 Location: Session_End 960 Type: Integer 961 Example: 5 963 Session_Timeout 965 Defines a timeout for the session. The time MUST be specified in the 966 format: an integer and a single character (the character MUST be one 967 of: ms,s,m,h _ milliseconds, seconds, minutes, hours). 969 Presence: optional, single 970 Type: String 971 Location: Session_End 972 Example: 10s 973 Example description: The timeout for the session is 10 seconds. 975 Session_Identification 977 Defines additional conditions that MUST be met by sensor data so that 978 a packet will be included in this session. These conditions apply 979 after a session has started. For instance, a TCP session will include 980 only the packets that have the same source and destination as the 981 source and destination of packets that started the session. The 982 conditions are specified by including special elements in this 983 element. 985 Location: Session 986 Presence: single, mandatory if the Session_Start attribute is present 987 Contained elements: Same_Source_IP [single, optional], 988 Same_Source_Port [single, optional], Same_Destination_IP [single, 989 optional], Same_Destination_Port [single, optional], Same_Protocol 990 [single, optional], Same_Direction [single, optional] 992 Same_Source_IP 994 If this element is present in Session_Identification, packets that 995 will be included in the session MUST have the same source IP address 996 as the starting packet. 998 Type: boolean 999 Presence: single, optional 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 Type: boolean 1009 Presence: single, optional 1010 Location: Session_Identification 1012 Same_Destination_IP 1014 If this element is present in Session_Identification, packets that 1015 will be included in the session MUST have the same destination IP 1016 address as the starting packet. 1018 Type: boolean 1019 Presence: single, optional 1020 Location: Session_Identification 1022 Same_Destination_Port 1024 If this element is present in Session_Identification, packets that 1025 will be included in the session MUST have the same destination port 1026 as the starting packet. 1028 Type: boolean 1029 Presence: single, optional 1030 Location: Session_Identification 1032 Same_Protocol 1034 If this element is present in Session_Identification, packets that 1035 will be included in the session MUST be of the same protocol as the 1036 starting packet. 1038 Type: boolean 1039 Presence: single, optional 1040 Location: Session_Identification 1042 Same_Direction 1044 If this element is present in Session_Identification, packets that 1045 will be included in the session MUST have been sent in the same 1046 direction as the starting packet. 1048 Type: boolean 1049 Presence: single, optional 1050 Location: Session_Identification 1052 Session_Instructions 1054 This element works like a switch statement for the state mechanism of 1055 an IDS. The information contained in this element defines the 1056 statefull behavior of an IDS for this session. The element contains 1057 several Session_Case elements that include conditions for the case to 1058 apply, as well as instructions to be carried out if the case applies. 1059 For efficiency reasons, it is assumed that all conditions for state 1060 instructions will be brought down into a conjunctive normal form (a 1061 logical expression that includes alternatives only at the highest 1062 level). That means that in every case element, all case conditions 1063 are treated as a logical conjunction (logical AND). This ought to 1064 simplify the processing of these instructions. 1066 Location: Session 1067 Presence: single, optional 1068 Contained elements: Session_Case [multiple] 1070 Session_Case 1072 This element contains the conditions and instructions of a case in 1073 the switch statement that is defined by the containing 1074 Session_Instructions element. For readability, the conditions are 1075 split up into three groups: additional conditions for sensor data 1076 that MUST be satisfied so that the packet will apply to this case, 1077 the direction of the packet, and the conditions that MUST be 1078 satisfied by the state variables of a session in order for the case 1079 to apply. The instructions of a case are contained in the mandatory 1080 Case_State_Instructions element. 1082 Location: Session_Instructions 1083 Presence: multiple 1084 Contained elements: Case_Filter [single, optional], Direction 1085 [single, optional], Case_State_Condition [single, optional], 1086 Case_State_Instructions [single, mandatory] 1088 Case_Filter 1090 Contains IDs of Source, Destination, Protocol or Pattern elements, 1091 combined using logical expressions in the format described in section 1092 2.4. The information contained in this element specifies the 1093 conditions that MUST be met by sensor data so that the packet will 1094 apply to this case. 1096 Location: Session_Case 1097 Presence: single, optional 1098 Allowed values: CIDSS logical expressions. 1100 Direction 1102 Defines a direction of network traffic, once a source and destination 1103 of traffic are specified (e.g. after the start of a session). Allowed 1104 values are: _sd_ and _ds_. If direction value is _sd_ it means that 1105 the packet has been sent from source to destination. If the value of 1106 this element is _ds_ it means that traffic goes from destination to 1107 source. 1109 Allowed values: sd|ds 1110 Default value: sd 1111 Location: Session_Case 1112 Presence: single, optional 1114 Case_State_Condition 1116 This element contains conditional state expressions that MUST all be 1117 satisfied (evaluate to a boolean value of _true_) in order for the 1118 case to apply. These instructions MAY check the values of state 1119 variables stored by the IDS for this session. 1121 Location: Session_Case 1122 Presence: single, optional 1123 Contained elements: Isset_Var, Compare_Var 1125 Case_State_Instructions 1127 This element contains state instructions that MUST all be 1128 sequentially carried out by the IDS if the case applies. These 1129 instructions MAY set, unset or modify the values of state variables 1130 stored by the IDS for this session. 1132 Location: Session_Case 1133 Presence: single, optional 1134 Contained elements: Set_Var, Unset_Var 1136 Isset_Var 1138 A conditional state expression that evaluates to a boolean value of 1139 _true_ if the variable of a name that is specified in the _var_ 1140 attribute is set in the state of this session. 1142 Location: Case_State_Condition 1143 Presence: multiple, optional 1144 Attributes: var [type: string; single, mandatory] 1146 Compare_Var 1148 Location: Case_State_Condition 1149 Presence: multiple, optional 1150 Attributes: var [type: string; single, mandatory], value [type: 1151 string; single, mandatory] 1153 Set_Var 1155 Sets value of _var_ attribute in state of particular session. 1157 Location: Case_State_Instructions 1158 Presence: multiple, optional 1159 Attributes: var [type: string; single, mandatory], value [type: 1160 string; single, mandatory] 1162 Unset_Var 1163 Nullifies value of _var_ used in this session. 1165 Location: Case_State_Instructions 1166 Presence: multiple, optional 1167 Attributes: var [type: string; single, mandatory] 1169 3. Security Considerations 1171 This Internet Draft describes the CIDSS format for storing 1172 information about IDS signatures. The applications of this standard 1173 can raise security concerns, but there are no security concerns 1174 related strictly to the document format. 1176 It is RECOMMENDED that a system for storing CIDSS data SHOULD be 1177 protected against unauthorized access and unauthorized use. The means 1178 for achieving this protection are outside the scope of this document. 1180 Copyright Notice 1182 Copyright (C) The Internet Society (2004). This document is subject 1183 to the rights, licenses and restrictions contained in BCP 78, and 1184 except as set forth therein, the authors retain all their rights. 1186 This document and the information contained herein are provided on an 1187 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1188 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1189 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1190 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1191 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1192 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1194 Intellectual Property Statement 1196 The IETF takes no position regarding the validity or scope of any 1197 Intellectual Property Rights or other rights that might be claimed to 1198 pertain to the implementation or use of the technology described in 1199 this document or the extent to which any license under such rights 1200 might or might not be available; nor does it represent that it has 1201 made any independent effort to identify any such rights. Information 1202 on the procedures with respect to rights in RFC documents can be 1203 found in BCP 78 and BCP 79. 1205 Copies of IPR disclosures made to the IETF Secretariat and any 1206 assurances of licenses to be made available, or the result of an 1207 attempt made to obtain a general license or permission for the use of 1208 such proprietary rights by implementers or users of this 1209 specification can be obtained from the IETF on-line IPR repository at 1210 http://www.ietf.org/ipr. 1212 The IETF invites any interested party to bring to its attention any 1213 copyrights, patents or patent applications, or other proprietary 1214 rights that may cover technology that may be required to implement 1215 this standard. Please address the information to the IETF at 1216 ietf-ipr@ietf.org. 1218 Appendix A 1219 XML CIDSS Document Example 1221 Here we present a sample signature in CIDSS format. Elements of this 1222 signature have been used as examples in the previous sections. (This 1223 appendix MAY NOT be compatible with Internet Draft formatting). 1225 1226 1228 1229 true 1230 snort 1231 alert 1232 NETBIOS SMB-DS DCERPC Remote Activation bind attempt; 1233 sid=2252 1234 NETBIOS SMB-DS DCERPC Remote Activation bind 1235 attempt 1236 reference:cve,CAN-2003-0528; reference:cve,CAN-2003-0605; 1237 reference:cve,CAN-2003-0715; 1238 reference:url,www.microsoft.com/technet/security/bulletin/MS03- 1239 039.mspx; 1240 1241 1242 any 1243 any 1244 1245 1246 10.0.0.0 1247 any 1248 1249 1250 192.168.1.0 1251 any 1252 1253 SRC_1 AND SRC_2 AND SRC_3 1254 1255 1256 1257 any 1258 445 1259 1260 1261 192.168.1.0 1263 445 1264 1265 1266 10.0.0.0 1268 445 1270 1271 DST_1 AND DST_2 AND DST_3 1272 1273 1274 1275 established 1276 1277 PROTO_1 1278 1279 1280 1281 string 1282 |FF|SMB% 1284 5 1285 4 1286 1287 1288 string 1289 &|00| 1291 2 1292 56 1293 1294 1295 string 1296 |5C 1297 00|P|00|I|00|P|00|E|00 5C 00| 1298 12 1299 5 1300 1301 1302 hex 1303 05 1304 1 1305 1306 1307 hex 1308 0B 1309 1 1310 1 1311 1312 1313 string 1314 |B8|J|9F|M|1C|}|CF 11 1315 86 1E 00| |AF|n|7C|W 1316 16 1317 29 1318 1319 PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 AND PAT_5 AND 1320 PAT_6 1321 1322 1323 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND 1324 DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 1325 AND PAT_5 AND PAT_6) 1326 1327 5 1328 1329 1330 1331 1333 Appendix B 1334 The schema of CIDSS _ cidss.xsd 1336 Available at http://translator.b59.net/docs/cidss.xsd 1338 References 1340 [1] Bradner S., "Key words for use in RFCs to Indicate 1341 Requirement Levels", BCP 14, RFC 2119, March 1997. 1343 [2] Curry D., Lynch Merrill, Debar H., "The Intrusion 1344 Detection 1345 Message Exchange Format", Internet Draft 1346 draft-ietf-idwg-idmef-xml-11, January 2004, expires July 1347 2004. 1349 [3] McLaughlin Brett, Java & XML, 2nd Edition, 1350 ISBN: 0-596-00197-5 1352 [4] K. Miakisz, Translator i wspolny jezyk sygnatur 1353 systemow wykrywania wlaman (Translator and Common 1354 Intrusion Detection Systems Language), Bachelor thesis, 1355 Polish-Japanese Institute of Information Technology, 1356 2003 1358 [5] Roesch Martin, Green Chris, "Snort Users Manual", Snort 1359 Release 2.1.0, December 2003, http://www.snort.org 1361 [6] "Dragon. Intrusion Detection System. Topics on Writing 1362 Signatures" Enterasys Networks, 2002, 1363 http://dragon.enterasys.com 1365 [7] arachNIDS - Whitehats Network Security Resource, 1366 http://whitehats.com/ids/ 1368 [8] Shoki, "Shoki User's Guide", Release 0.3.0, 1369 http://shoki.sourceforge.net/ 1371 [9] Extensible Markup Language (XML) 1.0, Third Edition, 1372 http://www.w3.org/TR/2004/REC-xml-20040204/ 1374 [10] XML Schema _ Specifications and Development, 1375 http://www.w3.org/XML/Schema#dev 1377 [11] ISS _ Internet Security Systems, Documentation, 1378 http://www.iss.net/support/documentation/ 1380 [12] Cisco _ NetRanger, Documentation, 1381 http://www.cisco.com/univercd/cc/td/doc/product/iaabu/\ 1382 netrangr/ 1384 [13] PCRE _ Perl Compatible Regular Expressions, 1385 http://www.pcre.org/ 1387 Author's Addresses 1389 dr Adam Wierzbicki 1390 Polish-Japanese Institute of Information Technology 1391 Koszykowa 86 1392 02-008 Warsaw, Poland 1393 Email: adamw@pjwstk.edu.pl 1395 Jacek Kalinski 1396 Rechniewskiego 6/24 1397 03-980 Warsaw, Poland 1398 Email: jacek@dyski.one.pl 1400 Tomasz Kruszona 1401 Garwolinska 9/83 1402 04-348 Warsaw, Poland 1403 Email: t.kruszona@b59.net 1405 Comments to: 1406 dr Adam Wierzbicki 1407 Polish-Japanese Institute of Information Technology 1408 Koszykowa 86 1409 02-008 Warsaw, Poland 1410 Email: adamw@pjwstk.edu.pl