Internet Draft A. Wierzbicki J. Kalinski T. Kruszona Document: draft-wierzbicki-cidss-00.txt Polish-Japanese Institute of Information Technology Expires: April 2005 October 2004 Common Intrusion Detection Signatures Standard Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. Distribution of this memo is unlimited. Abstract The purpose of the Common Intrusion Detection Signatures Standard (CIDSS) is to define a common data format for storing signatures from different intrusion detection systems. This Internet-Draft describes a common data format to represent information contained in signatures of intrusion detection systems, and explains the rationale for using this common format. The proposed format is a dialect of the Extensible Markup Language (XML). An XML Document Type Definition is developed, and examples are provided. Wierzbicki et al. Expires - April 2005 [Page 1] Common Intrusion Detection Signatures Standard October 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Conventions used in this document.................................2 Table of Contents.................................................2 1. Introduction...................................................2 1.1 About CIDSS................................................2 1.2 Potential Applications of CIDSS............................3 2. XML CIDSS Signatures...........................................4 2.1 Structure of a CIDSS document..............................4 2.2 Structure of a CIDSS signature.............................4 2.3 Data types used by the Pattern_Content element.............5 2.4 Logical expressions used in CIDSS signature definitions....5 2.5 XML elements and attributes used in CIDSS..................6 3. Security Considerations.......................................23 Copyright Notice.................................................24 Intellectual Property Statement..................................24 Appendix A.......................................................25 Appendix B.......................................................27 References.......................................................27 Author's Addresses...............................................28 Comments to:.....................................................28 1. Introduction 1.1 About CIDSS Common Intrusion Detection Signatures Standard is intended to be a standard format of signatures used widely in Network Intrusion Detection Systems (NIDS). An IDS is controlled by a set of decision rules. A decision rule of an IDS is composed of two components: a description of specific characteristics of an intrusion attempt (a signature) and an action that has to be carried out when the data provided by IDS sensors matches the signature. This document focuses on the remaining part of an IDS decision rule: the IDS signature. Currently, every IDS uses a different format of signatures. CIDSS defines a common format of signatures that attempts to express all information contained in signatures of various IDS. The CIDSS signature format is based on XML to facilitate the adaptation and applications of the proposed standard. The CIDSS signature format is designed to be extensible, and therefore it SHOULD be simple to incorporate features of future and current IDS systems that have not been taken into account in the first design. Wierzbicki et al. Expires - April 2005 [Page 2] Common Intrusion Detection Signatures Standard October 2004 The main goal of CIDSS is to enable administrators of IDS systems to share, compare, evaluate and criticize signatures used to detect intrusion events. The increasingly dynamic, global, and frequent nature of intrusion attempts is a trend that forces administrators to greater efforts to protect increasingly valuable information. The possibility to disseminate knowledge and experience about IDS systems' operation would be enhanced by the introduction of a common signature format. Therefore the use of a common IDS signature format SHOULD lead to a greater security of information. Other possible applications of CIDSS will be discussed in the next section. CIDSS Homepage: http://cidss.b59.net 1.2 Potential Applications of CIDSS One of the main applications of CIDSS is the translation of signatures between various IDS. The ability to translate a signature of an IDS into the common data format and to carry out a reverse translation implies that it SHOULD be possible to translate signatures of different IDS using the common data format as an intermediate form. The development of this standard has been carried out in parallel with the development of an IDS signature translator. Currently, the translator is able to translate signatures of Snort [5] and Dragon [6] IDS into the common format, and among the three systems. It's also partially tested with: Shoki [8], ISS RealSecure(TM) [11], and Cisco NetRanger(TM) [12]. The IDS translator is developed under the GNU General Public License and is available from http://translator.b59.net. Another possible application of CIDSS would be the creation and maintenance of signature databases by independent providers of IDS signatures. The use of XML as a base for the common signature format enables a simple integration of collections of signatures into a database. This SHOULD improve the searching and management of a signature collection. The business model of an independent signature provider could be the delivery of up-to-date, comprehensive signature collections to increase security of specific services, systems and platforms. Wierzbicki et al. Expires - April 2005 [Page 3] Common Intrusion Detection Signatures Standard October 2004 ------------------------------------- | First part of a signature | | ... |<-------|--| | ... |<-------|--| | ... |<-------|--| | ... |<-------|--| ------------------------------------- | | ------------------------------------------- | | | Second part of a signature | | | | | | | | ... | | | | ... | | | | | | | | ... | | | | | | | | ...|----- | | | | | ... |--------- | | | | ------------------------------------------- Figure 1 The main components and logical structure of a CIDSS signature 2. XML CIDSS Signatures This section describes the logical and structural rules for creating signatures in CIDSS format. Each XML element and attribute used in the CIDSS format are described and explained on examples. In appendix A, a full CIDSS signature is provided that has been used to provide the examples used in this section. CIDSS meets XML ver. 1.0 requirements [9]. CIDSS is defined as a dialect of XML using the XML Schema Definition (XSD). The schema of CIDSS is an appendix to this document (see appendix B: CIDSS XSD schema. cidss.xsd) 2.1 Structure of a CIDSS document A CIDSS document is a collection of signatures. Each signature is independent, and can be stored in a separate CIDSS document or together with other signatures. The main XML element of a CIDS document is the "Signatures" element. 2.2 Structure of a CIDSS signature A CIDSS signature is composed of several XML elements, contained in a common "Signature" element. A signature can be divided into two basic, logical parts. The first part, that includes (among others) the elements "Sources", "Destinations", "Protocols" and "Patterns", is used to define building blocks of a signature definition. These blocks are combined in the second part of a signature, and are kept Wierzbicki et al. Expires - April 2005 [Page 4] Common Intrusion Detection Signatures Standard October 2004 separate in order to shorten the signature definition and avoid redundancy. For instance, the definition of relevant information about the TCP protocol might be kept inside the "Protocols" element and might be later combined with several patterns (defined inside the "Patterns" element). Rather than repeat the definition of the TCP protocol each time a new pattern is used, the signature definition will refer to the information kept inside the "Protocols" element. The second part of a signature contains information on how to use the building blocks defined in the first part. The main XML element of the second part of a signature is the "Session" element. A "Session" element defines the main signature behavior. A signature MAY use state managed by the IDS for a certain flow of packets (or session). However, it is possible to create stateless signatures, by omitting information REQUIRED for the state mechanisms to work. Then, the information contained in a "Session" element defines the conditions that MUST be fulfilled by sensor data in order to trigger the signature. In the second part of a signature, the information contained in the first part is combined using logical expressions. Each element in the first part of a signature that contains a "building block" for the signature definition MUST have an identifier that is unique in the signature (not necessarily in the CIDSS document that contains the signature). This identifier can be used in the second part of a signature to refer to the "building block" defined by this element. The building blocks MAY be combined using logical expressions that are constructed by the "AND" and "OR" operators. The logical expressions are contained in special tags, and are treated as strings by the XML parser. CIDSS logical expressions are described in section 2.4. 2.3 Data types used by the Pattern_Content element The data types used in CIDSS signatures are compatible with the XML[9] and XML Schema (XSD) [10] specification. The following data types are supported: - String values You MUST use encoding defined by "encoding" attribute (e.g. ). UTF-8 RECOMMENDED. Refer to Appendix A and Appendix B - Hexadecimal values - Decimal values 2.4 Logical expressions used in CIDSS signature definitions Some elements in the CIDSS signature contain information that describes how other elements MUST be combined in the signature definitions. The content of these elements is a String value that contains a logical expression. A translating software MUST be able to process these expressions. CIDSS logical expressions MUST use operators "AND", "OR", and "NOT" (uppercase). The operators are interpreted as follows: Wierzbicki et al. Expires - April 2005 [Page 5] Common Intrusion Detection Signatures Standard October 2004 - AND - logical conjunction - OR - logical alternative - NOT - logical negation The operator precedence in CIDSS logical expressions MUST be interpreted as follows: NOT precedes AND precedes OR. CIDSS logical expressions MAY contain ordinary braces "(" or ")" that are interpreted as in logical expressions. Apart from braces and operators, CIDSS logical expressions MUST contain unique identifiers of other XML elements in the CIDSS signature definition that MAY be used in logical expressions. 2.5 XML elements and attributes used in CIDSS In this section, all XML elements defined by the CIDSS standard SHALL be introduced. Each element will be defined using a common template to simplify a presentation. This template is explained below: Element name Element description. Presence: [mandatory | optional, single | multiple] Location: element name Attributes: attribute name [type [, unique]] Contained elements: element names mandatory - means that the element MUST exist in the signature optional - the element MAY exist in the signature single - if the element exists in the signature, then this element MUST exist in exactly one instance multiple - if the element exists in the signature, then this element MAY exist many instances unique - value of the element MUST NOT be repeated as value of the same element in other place Signatures A root element of a CIDSS XML document. Presence: mandatory, single Location: root element Contained elements: Signature [multiple, mandatory] Example: where "" SHOULD be replaced by the filename of the XSD schema file (e.g. cidss.xsd) Wierzbicki et al. Expires - April 2005 [Page 6] Common Intrusion Detection Signatures Standard October 2004 Signature This element contains all information about a signature. Presence: mandatory Location: element Signatures Attributes: SID [type: integer; single, mandatory, unique] Contained elements: Enabled [single, mandatory], Sig_Source [single, optional], Description [single, optional], Action [single, optional], Protocols [multiple, mandatory], Sources [multiple, mandatory], Destinations [multiple, mandatory], Patterns [single, mandatory], Logged_Packets [single, optional], Message [single, optional], Comment [multiple, optional] Example: See Appendix A Enabled Defines a current signature state. Setting this to true, the signature will be analyzed by the IDS. Otherwise the signature SHOULD be skipped. Presence: mandatory Type: Boolean Default value: true Location: element Signature Example: true Sig_Source Optional element for use in translators. Specifies the IDS from which the signature was translated or ported. This element SHOULD contain string that identifies a signature source. Presence: optional Type: String Location: element Signature Example: Snort Description This element MAY contain a simple description of the signature. Presence: optional Type: String Location: element Signature Example: Try to get passwd file using ftp protocol Action MAY define actions performed by an IDS after intrusion detection Suggested values: drop, allow, alert, and warning. Wierzbicki et al. Expires - April 2005 [Page 7] Common Intrusion Detection Signatures Standard October 2004 Presence: optional, single Type: String Location: element Signature Example: alert Protocols This element contains description of multiple protocols used in potential attack. Location: Signature Presence: mandatory, multiple Attributes: ID[integer,unique] Protocol The element used to describe the network protocol. Options of the protocol used in this element depend on a protocol type. The Proto_ID attribute is used for identification in the Proto_Logic element - it is REQUIRED only when there is more than one Protocol in the Protocols element. Presence: mandatory, multiple. Type: String Attributes: Proto_ID [integer, unique], Type [enum: tcp, udp, ip, icmp, application] Location: element Signature Contained elements: TCP_Ack [single, optional], TCP_State [single, optional], TCP_Seq [single, optional], TCP_Dsize [single, optional], TCP_Flags [single, optional], TCP_Window [single, optional], UDP_Dsize [single, optional], ICMP_Dsize [single, optional], ICMP_Icmp_Id [single, optional], ICMP_Icmp_Seq [single, optional], ICMP_Icode [single, optional], ICMP_Itype [single, optional], IP_Ttl [single, optional], IP_Tos [single, optional], IP_Ipopts [single, optional], IP_Fragbits [single, optional], IP_Id [single, optional], IP_Ip_Proto [single, optional], IP_Dsize [single, optional], Isdataat [single, optional], Rpc [single, optional] Isdataat Checks that the data fields in the packet are in the specified offset. Allowed values: Integer or integer (more than a given value) Location: Protocol Presence: single, optional Example: <5 Wierzbicki et al. Expires - April 2005 [Page 8] Common Intrusion Detection Signatures Standard October 2004 Rpc This element specifies the RPC application, version, and procedure numbers in SUNRCP call requests. It MUST contain a string in the following format: Allowed format: , [|*], [|*]> Location: Protocol, Type=="Application" Presence: single, optional Type: String Example: 100000,*,3 TCP_Ack Checks the specific TCP ack number Location: Protocol, Type=="TCP" Presence: single, optional Type: integer Example: 0 TCP_Seq Checks the specific TCP seq number Location: Protocol, Type=="TCP" Presence: single, optional Type: integer Example: TCP_Seq>0 TCP_State Describes current protocol state e.g. established, stateless Location: Protocol, Type=="TCP" Allowed values: [established|stateless] Presence: single, optional Type: string Example: established TCP_Flags Check if the specific TCP Flags are present Location: Protocol, Type=="TCP" Allowed values: [!|*|+][FSRPAU120] Values description: F-FIN, S-SYN, R-RST, P-PSH, A-ACK, U-URG, 1- Reserved bit 1, 2-Reserved bit 2, 0-No Flags set. Modifiers description: + - match on the specific bits, plus any others, * - match if any of the specified bits are set, ! - match if specified bits are not set Wierzbicki et al. Expires - April 2005 [Page 9] Common Intrusion Detection Signatures Standard October 2004 Presence: multiple, optional Type: String Example: +SA TCP_Window Checks value of the TCP window size Location: Protocol, Type=="TCP" Presence: single, optional Type: integer Example: 34000 TCP_Dsize Checks the packet data field size in TCP protocol Allowed signs: <, >, <=, >=, number Location: Protocol, Type=="TCP" Presence: single, optional Type: String Example: <=40000 UDP_Dsize Checks packet data field size in UDP protocol Allowed signs: <, >, <=, >=, number Location: Protocol, Type=="UDP" Presence: single, optional Type: String Example: <=33400 ICMP_Dsize Checks the packet data field size in ICMP protocol Allowed signs: <, >, <=, >=, number Location: Protocol, Type=="ICMP" Presence: single, optional Type: String Example: >=64 ICMP_Icmp_Id Checks the value of specific ICMP ID Location: Protocol, Type=="ICMP" Presence: single, optional Type: integer Example: 0 Wierzbicki et al. Expires - April 2005 [Page 10] Common Intrusion Detection Signatures Standard October 2004 ICMP_Icmp_Seq Checks the value of ICMP sequence Location: Protocol, Type=="ICMP" Presence: single, optional Type: integer Example: 0 ICMP_Icode Checks the value of specific ICMP code Allowed signs: <, >, number Location: Protocol, Type=="ICMP" Presence: single, optional Type: String Example: >25 ICMP_Itype Checks the value of specified ICMP type Allowed signs: <, >, number Location: Protocol, Type=="ICMP" Presence: single, optional Type: String Example: >25 IP_Ttl Specifies IP time-to-live value Allowed signs: <, >, <=, >=,-, number Location: Protocol, Type=="IP" Presence: single, optional Type: string Example: 6-8 - values between 6 and 8 IP_Tos Check the IP ToS field for specified value Location: Protocol, Type=="IP" Presence: single, optional Type: integer Example: 2 IP_Fragbits Checks fragmentations bits for the specified value Wierzbicki et al. Expires - April 2005 [Page 11] Common Intrusion Detection Signatures Standard October 2004 Location: Protocol, Type=="IP" Presence: single, optional Type: String Example: DM+ IP_Id Checks ID field in IP protocol for the specified value Location: Protocol, Type=="IP" Presence: single, optional Type: integer Example: 34222 IP_Ipopts This element checks if the specified IP option is present. Allowed values: rr - Record route, eol - end of list, nop - no op, ts - Time Stamp, sec - IP security option, lsrr - Loose source routing, ssrr - Strict source routing, satid - Stream identifier, any - any IP options are set Location: Protocol, Type=="IP" Presence: single, optional Type: String Example: lsrr IP_Dsize Checks size of packet data field Allowed signs: <, >, <=, >=, number Location: Protocol, Type=="IP" Presence: single, optional Type: String Example: 34000 IP_Ip_Proto Checks IP protocol header for the specified value Allowed signs: <, >, <=, >=, number, name Location: Protocol, Type=="IP" Presence: single, optional Type: String Example: igmp Proto_Logic This element describes logical rules to combine the information in Protocol elements contained in one Protocols element. Logical operators in Proto Logic element are described in section 2.4. Wierzbicki et al. Expires - April 2005 [Page 12] Common Intrusion Detection Signatures Standard October 2004 Presence: optional, single Location: element Patterns Example: 1 OR (2 AND 3) Sources This element contains information that describes properties of a source of network communications. If Sources occurs more then once, then every Sourcs MUST have an unique id (attribute) used in Src_Logic that defines logical dependences between each of them. Presence: mandatory, multiple Location: element Signature Attributes: ID Contained elements: Source[multiple, mandatory], Src_Logic [single, optional] Example: See Appendix A Source This element contains descriptions of source hosts. Src_ID attribute is local (in one Sources element) id for use with the Src_Logic element. Presence: mandatory, multiple Location: element Sources Attributes: Src_ID [presence: mandatory if more than one Source_ in one Sources element, type: integer, unique] Contained elements: Source_IP[single, mandatory], Source_Port[single, optional] Example: See Appendix Destinations This element contains information that describes properties of a destination of network communications. If Destinations occurs more then once, then every Destination MUST have an unique id (attribute) used in Dst_Logic to define logical dependences between each of them. Presence: mandatory, multiple Location: element Signature Contained elements: Destination [multiple, mandatory] Example: See Appendix A Destination This element contains descriptions of destination hosts. Dst_ID attribute is local (in one Destinations element) id for use with the Dst_Logic element. Wierzbicki et al. Expires - April 2005 [Page 13] Common Intrusion Detection Signatures Standard October 2004 Presence: mandatory, multiple Location: element Destinations Attributes: Dst_ID [presence: mandatory if more than one Destination_ in one Destinations element, type: integer, unique] Contained elements: Destination_IP [single, mandatory], Destination_Port [single, optional] Example: See Appendix A Source_IP This element contains an IPv4 or IPv6 network address in any notation. The value "any" means that all addresses will be considered and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the value of Neg attribute is "true", then the values specified in the Source_IP element are interpreted as addresses that MUST NOT match the source address in order for the signature to apply. Mask attribute defines IP mask for current IP. Allowed values: Any string Attributes: Neg [presence: mandatory, type: boolean, allowed values: true|false, default: false], Mask [presence: mandatory, type: string, allowed values: mask in octet or bit notation] Presence: mandatory, single Type: String Location: element Source Example: $EXTERNAL_NET Variable $EXTERNAL_NET is defined in an IDS. (e.g. $EXTERNAL_NET=1.2.3.4) Destination_IP This element contains an IPv4 or IPv6 network address in any notation. The value "any" means that all addresses will be considered and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the value of Neg attribute is "true", then the values specified in the Destination_IP element are interpreted as addresses that MUST NOT match the source address in order for the signature to apply. Mask attribute defines IP mask for current IP. Allowed values: Any string Attributes: Neg [presence: mandatory, type: boolean, allowed values: true|false, default: false], Mask [presence: mandatory, type: string, allowed values: mask in octet or bit notation] Presence: mandatory, single Type: String Location: element Destination Example: Similar as in Source_IP element Wierzbicki et al. Expires - April 2005 [Page 14] Common Intrusion Detection Signatures Standard October 2004 Source_Port The value of this element is a port number or range of ports expressed by two port numbers divided with a ":" sign. The "135:139" expression means that all ports between 135 and 139 will be considered, accounting ports 135 and 139. The value "any" means that all ports will be considered. Presence: If Protocol Type is set to tcp, udp or ip then mandatory, if Protocol Type value is icmp then MUST NOT be set. Type: String Location: element Source Example: any Destination_Port The value of this element is a port number or range of ports expressed by two port numbers divided with a ":" sign. The "135:139" expression means that all ports between 135 and 139 will be considered, accounting ports 135 and 139. The value "any" means that all ports will be considered. Presence: If Protocol Type value is set to tcp, udp or ip then mandatory, if Protocol Type value is icmp then MUST NOT be set. Type: String Location: element Destination Example: 445 Src_Logic Defines logical dependences between each Source description. Logical operators: (, ), AND, OR Location: Sources Example: 2 OR (1 AND 3) Dst_Logic Defines logical dependences between each Destination description. Logical operators: (, ), AND, OR Location: Destinations Example: 1 AND 2 Patterns This element contains multiple Pattern elements. Presence: mandatory, if Protocol is to tcp, udp, ip or application than element is present. Wierzbicki et al. Expires - April 2005 [Page 15] Common Intrusion Detection Signatures Standard October 2004 Location: element Signature Contained elements: Pattern [multiple, optional] Attributes: ID[integer, unique] Example: See Appendix A Pattern This element contains information about the content of a packet that is considered as potentially dangerous. Attribute Pat_ID is used in Pat_Logic element to define logical expressions using multiple Pattern elements Presence: mandatory, multiple Location: element Patterns Contained elements: Pattern_Type [single, mandatory], Pattern_Content [single, optional], Pattern_Depth [single, optional], Pattern_Uricontent [single, optional], Pattern_Offset [single, optional], Pattern_Within [single, optional], Pattern_Distance [single, optional] Attributes: Pat_ID [integer, unique] Example: See Appendix A Pattern_Type Using CIDSS you can specify patterns in hexadecimal, decimal, or string Presence: mandatory Type: String Location: element Pattern Permitted values: "hex", "dec", "string" Default value: "string" Example: string Pattern_Content Defines packet content that is interpreted as an intrusion and considered dangerous. To define the content, regular expressions can be used in the Pattern_Content element. Regular expression MUST be in the PCRE format (Perl Compatible Regular Expressions) [13]. If Rawbytes attribute value is "true" it means pattern is searched in raw packets ignoring decoding that was done by preprocessors. Presence: mandatory, single Attributes: CaseSensitive [allowed values: true|false, default value: true], Rawbytes [allowed values: true|false, default value: false] Type: Same as value of Pattern_Type Location: element Pattern Example: RETR passwd Wierzbicki et al. Expires - April 2005 [Page 16] Common Intrusion Detection Signatures Standard October 2004 Pattern_Depth Defines how many bytes of the packet MUST be searched in order to find the content defined in the Pattern_Content element that is contained by the same Pattern element as this element. Presence: optional, single Location: element Pattern Type: Integer Example: 10 Pattern_Uricontent This element describes content of packet in URI format. If content is e.g. URL address it MAY be used in clear form in Pattern_Uricontent without special signs. Type: string Location: Pattern Presence: optional, single Example: local/apache/htdocs/ Pattern_Offset Specifies offset in bytes from beginning of packet to search for the pattern. Type: integer Location: Pattern Presence: optional, single Example: 5 Pattern_Within Used to describe how many packets are at most between two patterns. Type: integer Location: Pattern Presence: optional, single Example: 4 Pattern_Distance Defines how far the IDS SHOULD look into a packet for the specified pattern relative to last match. Type: integer Location: Pattern Presence: optional, single Example: 3 Wierzbicki et al. Expires - April 2005 [Page 17] Common Intrusion Detection Signatures Standard October 2004 Pat_Logic This element describes logical rules to combine the information in Pattern elements contained in one Patterns element. Logical operators in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in section 2.4). Presence: optional, single Location: element Patterns Example: (NOT 1 AND 2) OR 3 Logged_Packets Number of packets logged when the system detects an intrusion Presence: optional, single Location: element Signature Example: 0 Message Contains the message generated by the IDS when a packet described by this signature was detected. Presence: optional, single Location: element Signature Type: String Example: FTP password file GET request Comment This element MAY be used for additional comments and information about the signature. The element MAY contain additional information about signature vendor, vulnerability description, http links etc. Presence: optional, multiple Location: element Signature Example: Vendor: Arachnids Session Defines a session that could be identified by the signature if the state mechanisms of an IDS could be used. Otherwise, the information contained in this element describes the conditions that MUST be satisfied by the sensor data in order to trigger the signature. Location: Signature Presence: single, mandatory Contained elements: Session_Filter [single, optional], Session_Start [single, optional], Session_End [single, optional], Wierzbicki et al. Expires - April 2005 [Page 18] Common Intrusion Detection Signatures Standard October 2004 Session_Identification [single, optional], Session_Instructions [single, optional] Session_Filter Contains IDs of Source, Destination, Protocol and Pattern elements, combined using logical expressions in the format described in section 2.4. The information contained in this element specifies the conditions that MUST be met by sensor data so that the packet will be included in this session. Location: Session Presence: single, optional Allowed values: CIDSS logical expressions. Session_Start Contains IDs of Source, Destination, Protocol or Pattern elements, combined using logical expressions in the format described in section 2.4. The information contained in this element specifies the conditions that MUST be met by sensor data so that the packet will define the beginning of a new session. All session state MUST be reset by the IDS when a new session begins. Location: Session Presence: single, optional Allowed values: CIDSS logical expressions. Session_End Contains IDs of Source, Destination, Protocol or Pattern elements, combined using logical expressions in the format described in section 2.4. The information contained in this element specifies the conditions that MUST be met by sensor data so that the packet will define the beginning of a new session. Instead of or in addition to conditions for sensor data, this element MAY include the element Session_Timeout, that specifies a timeout for the session or MAY include Session_Pckt_Count, that defines maximum number of packets considered in current session. When both conditions are specified, then the one that is fulfilled first will terminate the session. Location: Session Presence: single, mandatory if the Session_Start attribute is present Contained elements: Session_Timeout [single, optional], Session_Pckt_Count [single, optional] Session_Pckt_Count Defines maximum number of packets that are considered during session. Presence: single, optional Location: Session_End Wierzbicki et al. Expires - April 2005 [Page 19] Common Intrusion Detection Signatures Standard October 2004 Type: Integer Example: 5 Session_Timeout Defines a timeout for the session. The time MUST be specified in the format: an integer and a single character (the character MUST be one of: ms,s,m,h - milliseconds, seconds, minutes, hours). Presence: optional, single Type: String Location: Session_End Example: 10s - the timeout for the session is 10 seconds. Session_Identification Defines additional conditions that MUST be met by sensor data so that a packet will be included in this session. These conditions apply after a session has started. For instance, a TCP session will include only the packets that have the same source and destination as the source and destination of packets that started the session. The conditions are specified by including special elements in this element. Location: Session Presence: single, mandatory if the Session_Start attribute is present Contained elements: Same_Source_IP [single, optional], Same_Source_Port [single, optional], Same_Destination_IP [single, optional], Same_Destination_Port [single, optional], Same_Protocol [single, optional], Same_Direction [single, optional] Same_Source_IP If this element is present in Session_Identification, packets that will be included in the session MUST have the same source IP address as the starting packet. Location: Session_Identification Same_Source_Port If this element is present in Session_Identification, packets that will be included in the session MUST have the same source port as the starting packet. Location: Session_Identification Same_Destination_IP If this element is present in Session_Identification, packets that will be included in the session MUST have the same destination IP address as the starting packet. Wierzbicki et al. Expires - April 2005 [Page 20] Common Intrusion Detection Signatures Standard October 2004 Location: Session_Identification Same_Destination_Port If this element is present in Session_Identification, packets that will be included in the session MUST have the same destination port as the starting packet. Location: Session_Identification Same_Protocol If this element is present in Session_Identification, packets that will be included in the session MUST be of the same protocol as the starting packet. Location: Session_Identification Same_Direction If this element is present in Session_Identification, packets that will be included in the session MUST have been sent in the same direction as the starting packet. Location: Session_Identification Session_Instructions This element works like a switch statement for the state mechanism of an IDS. The information contained in this element defines the statefull behavior of an IDS for this session. The element contains several Session_Case elements that include conditions for the case to apply, as well as instructions to be carried out if the case applies. For efficiency reasons, it is assumed that all conditions for state instructions will be brought down into a conjunctive normal form (a logical expression that includes alternatives only at the highest level). That means that in every case element, all case conditions are treated as a logical conjunction (logical AND). This ought to simplify the processing of these instructions. Location: Session Presence: single, optional Contained elements: Session_Case [multiple] Session_Case This element contains the conditions and instructions of a case in the switch statement that is defined by the containing Session_Instructions element. For readability, the conditions are split up into three groups: additional conditions for sensor data that MUST be satisfied so that the packet will apply to this case, Wierzbicki et al. Expires April - 2005 [Page 21] Common Intrusion Detection Signatures Standard October 2004 the direction of the packet, and the conditions that MUST be satisfied by the state variables of a session in order for the case to apply. The instructions of a case are contained in the mandatory Case_State_Instructions element. Location: Session_Instructions Presence: multiple Contained elements: Case_Filter [single, optional], Direction [single, optional], Case_State_Condition [single, optional], Case_State_Instructions [single, mandatory] Case_Filter Contains IDs of Source, Destination, Protocol or Pattern elements, combined using logical expressions in the format described in section 2.4. The information contained in this element specifies the conditions that MUST be met by sensor data so that the packet will apply to this case. Location: Session_Case Presence: single, optional Allowed values: CIDSS logical expressions. Direction Defines a direction of network traffic, once a source and destination of traffic are specified (e.g. after the start of a session). Allowed values are: "sd" and "ds". If direction value is "sd" it means that the packet has been sent from source to destination. If the value of this element is "ds" it means that traffic goes from destination to source. Allowed values: sd|ds Default value: sd Location: Session_Case Presence: single, optional Case_State_Condition This element contains conditional state expressions that MUST all be satisfied (evaluate to a boolean value of "true") in order for the case to apply. These instructions MAY check the values of state variables stored by the IDS for this session. Location: Session_Case Presence: single, optional Contained elements: Isset_Var, Compare_Var Case_State_Instructions This element contains state instructions that MUST all be sequentially carried out by the IDS if the case applies. These Wierzbicki et al. Expires - April 2005 [Page 22] Common Intrusion Detection Signatures Standard October 2004 instructions MAY set, unset or modify the values of state variables stored by the IDS for this session. Location: Session_Case Presence: single, optional Contained elements: Set_Var, Unset_Var Isset_Var A conditional state expression that evaluates to a boolean value of "true" if the variable of a name that is specified in the "var" attribute is set in the state of this session. Location: Case_State_Condition Presence: multiple, optional Attributes: var [type: string; single, mandatory] Compare_Var Location: Case_State_Condition Presence: multiple, optional Attributes: var [type: string; single, mandatory], value [type: string; single, mandatory] Set_Var Location: Case_State_Instructions Presence: multiple, optional Attributes: var [type: string; single, mandatory], value [type: string; single, mandatory] Unset_Var Location: Case_State_Instructions Presence: multiple, optional Attributes: var [type: string; single, mandatory] 3. Security Considerations This Internet Draft describes the CIDSS format for storing information about IDS signatures. The applications of this standard can raise security concerns, but there are no security concerns related strictly to the document format. It is RECOMMENDED that a system for storing CIDSS data SHOULD be protected against unauthorized access and unauthorized use. The means for achieving this protection are outside the scope of this document. Wierzbicki et al. Expires - April 2005 [Page 23] Common Intrusion Detection Signatures Standard October 2004 Copyright Notice Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Wierzbicki et al. Expires - April 2005 [Page 24] Common Intrusion Detection Signatures Standard October 2004 Appendix A XML CIDSS Document Example 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). true snort alert NETBIOS SMB-DS DCERPC Remote Activation bind attempt; sid=2252 NETBIOS SMB-DS DCERPC Remote Activation bind attempt reference:cve,CAN-2003-0528; reference:cve,CAN-2003-0605; reference:cve,CAN-2003-0715; reference:url,www.microsoft.com/technet/security/bulletin/MS03- 039.mspx; any any 10.0.0.0 any 192.168.1.0 any SRC_1 AND SRC_2 AND SRC_3 any 445 192.168.1.0 445 10.0.0.0 445 Wierzbicki et al. Expires - April 2005 [Page 25] Common Intrusion Detection Signatures Standard October 2004 DST_1 AND DST_2 AND DST_3 established PROTO_1 string |FF|SMB% 5 4 string &|00| 2 56 string |5C 00|P|00|I|00|P|00|E|00 5C 00| 12 5 hex 05 1 hex 0B 1 1 string |B8|J|9F|M|1C|}|CF 11 86 1E 00| |AF|n|7C|W 16 29 PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 AND PAT_5 AND PAT_6 Wierzbicki et al. Expires - April 2005 [Page 26] Common Intrusion Detection Signatures Standard October 2004 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 AND PAT_5 AND PAT_6) 5 Appendix B The schema of CIDSS - cidss.xsd Available at http://translator.b59.net/docs/cidss.xsd References [1] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Curry D., Lynch Merrill, Debar H., "The Intrusion Detection Message Exchange Format", Internet Draft draft-ietf-idwg-idmef-xml-11, January 2004, expires July 2004. [3] McLaughlin Brett, Java & XML, 2nd Edition, ISBN: 0-596-00197-5 [4] K. Miakisz, Translator i wspolny jezyk sygnatur systemow wykrywania wlaman (Translator and Common Intrusion Detection Systems Language), Bachelor thesis, Polish-Japanese Institute of Information Technology, 2003 [5] Roesch Martin, Green Chris, "Snort Users Manual", Snort Release 2.1.0, December 2003, http://www.snort.org [6] "Dragon. Intrusion Detection System. Topics on Writing Signatures" Enterasys Networks, 2002, http://dragon.enterasys.com [7] arachNIDS - Whitehats Network Security Resource, http://whitehats.com/ids/ [8] Shoki, "Shoki User's Guide", Release 0.3.0, http://shoki.sourceforge.net/ Wierzbicki et al. Expires - April 2005 [Page 27] Common Intrusion Detection Signatures Standard October 2004 [9] Extensible Markup Language (XML) 1.0, Third Edition, http://www.w3.org/TR/2004/REC-xml-20040204/ [10] XML Schema - Specifications and Development, http://www.w3.org/XML/Schema#dev [11] ISS - Internet Security Systems, Documentation, http://www.iss.net/support/documentation/ [12] Cisco - NetRanger, Documentation, http://www.cisco.com/univercd/cc/td/doc/product/iaabu/\ netrangr/ [13] PCRE - Perl Compatible Regular Expressions, http://www.pcre.org/ Author's Addresses dr Adam Wierzbicki Polish-Japanese Institute of Information Technology Koszykowa 86 02-008 Warsaw, Poland Email: adamw@pjwstk.edu.pl Jacek Kalinski Rechniewskiego 6/24 03-980 Warsaw, Poland Email: jacek@dyski.one.pl Tomasz Kruszona Garwolinska 9/83 04-348 Warsaw, Poland Email: t.kruszona@b59.net Comments to: dr Adam Wierzbicki Polish-Japanese Institute of Information Technology Koszykowa 86 02-008 Warsaw, Poland Email: adamw@pjwstk.edu.pl Wierzbicki et al. Expires - April 2005 [Page 28]