Internet DRAFT - draft-wierzbicki-cidss

draft-wierzbicki-cidss



Common Intrusion Detection Signatures                     A. Wierzbicki 
Standard (CIDSS)                                          J. Kalinski 
                                                          T. Kruszona 
Internet Draft                               Polish-Japanese Institute 
                                             of Information Technology 
Intended status: Informational                       September 4, 2008 
Expires: March 2009 
                                   
 
                                      
              Common Intrusion Detection Signatures Standard 
                       draft-wierzbicki-cidss-05.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   BCP 79. 

   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 obsoleted 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/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on March 4, 2009. 








 
 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 1] 

Internet-Draft                  CIDSS                   September 2008 
    

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.  

Table of Contents 

   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............................5 
      2.2. Structure of a CIDSS signature...........................5 
      2.3. Data types used by the Pattern_Content element...........6 
      2.4. Logical expressions used in CIDSS signature definitions..6 
      2.5. XML elements and attributes used in CIDSS................7 
         2.5.1. Signatures..........................................7 
         2.5.2. Signature...........................................8 
         2.5.3. Protocols...........................................9 
         2.5.4. Sources............................................15 
         2.5.5. Destinations.......................................17 
         2.5.6. Patterns...........................................18 
         2.5.7. Session............................................22 
   3. Conventions used in this document............................29 
   4. Security Considerations......................................29 
   5. IANA Considerations..........................................29 
   6. Acknowledgments..............................................29 
   7. References...................................................30 
      7.1. Normative References....................................30 
      7.2. Informative References..................................30 
   APPENDIX A: XML CIDSS Document Example..........................32 
   APPENDIX B: The schema of CIDSS - common.xsd....................35 
    
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 
 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 2] 

Internet-Draft                  CIDSS                   September 2008 
    

   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. 

   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.sourceforge.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 
   [4] and Dragon [6] IDS into the common format, and among the three 
   systems. It's also partially tested with: Shoki [7], ISS 
   RealSecure(TM) [8], and Cisco NetRanger(TM) [9]. 

   The IDS translator is developed under the GNU General Public License 
   and is available from http://sigtranslator.sourceforge.net. 

 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 3] 

Internet-Draft                  CIDSS                   September 2008 
    

   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. 

               +-----------------------------------+ 
               |     First part of a signature     | 
               |  <Sources>...</Sources>           |<----|--| 
               |  <Destinations>...</Destinations> |<----|--| 
               |  <Protocols>...</Protocols>       |<----|--| 
               |  <Patterns>...</Patterns>         |<----|--| 
               +-----------------------------------+     |  | 
            +-----------------------------------------+  |  | 
            |     Second part of a signature          |  |  | 
            |  <Session>                              |  |  | 
            |     <Session_Start>...</Session_Start>  |  |  | 
            |     <Session_End>...</Session_End>      |  |  | 
            |     <Session_Identification>            |  |  | 
            |        ...                              |  |  | 
            |     </Session_Identification>           |  |  | 
            |     <Session_Filter>...</Session_Filter>|--   | 
            |     <Session_Instructions>              |     | 
            |        ...                              |------ 
            |     </Session_Instructions>             | 
            |   </Session>                            | 
            +-----------------------------------------+ 
       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 [2]. CIDSS is defined as a 
   dialect of XML using the XML Schema Definition (XSD). The schema of 

 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 4] 

Internet-Draft                  CIDSS                   September 2008 
    

   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 
   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 
 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 5] 

Internet-Draft                  CIDSS                   September 2008 
    

   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. 

   When the content of element contain "<" (less then), ">" (greater 
   then), "&" (ampersand), "'" (apostrophe) or """ (quotation mark) 
   signs, it MUST be put into CDATA section. A CDATA section starts with 
   "<![CDATA[" and ends with "]]>". 

   Only the characters "<" and "&" are strictly illegal in XML. 
   Apostrophes, quotation marks and greater than signs are legal, but it 
   is a good habit to replace them. 

   Note: A CDATA section cannot contain the string "]]>" 

    

2.3. Data types used by the Pattern_Content element 

   The data types used in CIDSS signatures are compatible with the XML 
   [2] and XML Schema (XSD) [3] specification. The following data types 
   are supported: 
   - String value 

   You MUST use encoding defined by "encoding" attribute (e.g. <?xml 
   version="1.0" encoding="UTF-8" ?>). 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: 
   - AND  -  logical conjunction 

 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 6] 

Internet-Draft                  CIDSS                   September 2008 
    

   - 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 

    

2.5.1. Signatures 

   A root element of a CIDSS XML document. 

 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 7] 

Internet-Draft                  CIDSS                   September 2008 
    

   Presence: mandatory, single 
   Location: root element 
   Contained elements: Signature [multiple, mandatory] 

   Example: 

   <Signatures xsi:noNamespaceSchemaLocation="<schema_file.xsd>" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 

   where "<schema_file.xsd>" SHOULD be replaced by the filename of the 
   XSD schema file (e.g. cidss.xsd) 

    

2.5.2. Signature 

   This element contains all information about a signature. Describes 
   conditions required to identify traffic as suspicious and to take an 
   action.  

   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 [single, mandatory], Sources [single, mandatory], 
   Destinations [single, mandatory], Patterns [single, mandatory], 
   Logged_Packets [single, optional], Message [single, mandatory], 
   Comment [multiple, optional], Session [single, mandatory] 
   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: <Enabled>true</Enabled> 

   Sig_Source 



 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 8] 

Internet-Draft                  CIDSS                   September 2008 
    

   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, single 
   Type: String 
   Location: element Signature 
   Example: <Sig_Source>Snort</Sig_Source> 

   Description 

   This element MAY contain a simple description of the signature. 

   Presence: optional 
   Type: String 
   Location: element Signature 
   Example: <Description>Try to get passwd file using ftp</Description> 

   Action 

   This MAY define actions performed by an IDS after intrusion 
   detection. 
   Suggested values: drop, allow, alert, and warning 

   Presence: optional, single 
   Type: String 
   Location: element Signature 
   Example: <Action>alert</Action> 

    

2.5.3. 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. 



 
 
Wierzbicki et al.       Expires March 4, 2009                 [Page 9] 

Internet-Draft                  CIDSS                   September 2008 
    

   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. When the content of this element contain "<" and ">" signs, 
   it MUST be put into <![CDATA[...]]> section. In other way it MAY 
   contain CDATA section, but it is not REQUIRED. 

   Allowed values: Integer or <integer (less than a given value) or 
   >integer (more than a given value) 
   Location: Protocol 
   Presence: single, optional 
   Example: <Isdataat><![CDATA[<5]]></Isdataat> 

   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: <Rpc><application number>, [<version number>|*], 
   [<procedure number>|*]></Rpc> 
   Location: Protocol, Type=="Application" 
   Presence: single, optional 
   Type: String 
   Example: <Rpc>100000,*,3</Rpc> 

   TCP_Ack 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 10] 

Internet-Draft                  CIDSS                   September 2008 
    

   Checks the specific TCP ack number 

   Location: Protocol, Type=="TCP" 
   Presence: single, optional 
   Type: integer 
   Example: <TCP_Ack>0</TCP_Ack> 

   TCP_Seq 

   Checks the specific TCP seq number 

   Location: Protocol, Type=="TCP" 
   Presence: single, optional 
   Type: integer 
   Example: TCP_Seq>0</TCP_Seq> 

   TCP_State  

   Describes current protocol state e.g. established, stateless 

   Location: Protocol, Type=="TCP" 
   Allowed values: [established|stateless] 
   Presence: single, optional 
   Type: string 
   Example: <TCP_State>established</TCP_State> 

   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 

   Presence: single, optional 
   Type: String 
   Example: <TCP_Flags>+SA</TCP_Flags> 

   TCP_Window 

   Checks value of the TCP window size 

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 11] 

Internet-Draft                  CIDSS                   September 2008 
    

   Location: Protocol, Type=="TCP" 
   Presence: single, optional 
   Type: integer 
   Example: <TCP_Window>34000</TCP_Window> 

   TCP_Dsize  

   Checks the packet data field size in TCP protocol. When the content 
   of this element contain "<" and ">" signs, it MUST be put into 
   <![CDATA[...]]> section. In other way it MAY contain CDATA section, 
   but it is not REQUIRED. 

   Allowed signs: <, >, <=, >=, number 
   Location: Protocol, Type=="TCP" 
   Presence: single, optional 
   Type: String 
   Example: <TCP_Dsize><![CDATA[<=40000]]></TCP_Dsize> 

   UDP_Dsize  

   Checks packet data field size in UDP protocol. When the content of 
   this element contain "<" and ">" signs, it MUST be put into 
   <![CDATA[...]]> section. In other way it MAY contain CDATA section, 
   but it is not REQUIRED. 

   Allowed signs: <, >, <=, >=, number 
   Location: Protocol, Type=="UDP" 
   Presence: single, optional 
   Type: String 
   Example: <UDP_Dsize><![CDATA[<=33400]]></UDP_Dsize> 

   ICMP_Dsize  

   Checks the packet data field size in ICMP protocol. When the content 
   of this element contain "<" and ">" signs, it MUST be put into 
   <![CDATA[...]]> section. In other way it MAY contain CDATA section, 
   but it is not REQUIRED. 

   Allowed signs: <, >, <=, >=, number 
   Location: Protocol, Type=="ICMP" 
   Presence: single, optional 
   Type: String 
   Example: <ICMP_Dsize><![CDATA[>=64]]></ICMP_Dsize> 

   ICMP_Icmp_Id 

   Checks the value of specific ICMP ID 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 12] 

Internet-Draft                  CIDSS                   September 2008 
    

   Location: Protocol, Type=="ICMP" 
   Presence: single, optional 
   Type: integer 
   Example: <ICMP_Icmp_Id>0</ICMP_Icmp_Id> 

   ICMP_Icmp_Seq  

   Checks the value of ICMP sequence 

   Location: Protocol, Type=="ICMP" 
   Presence: single, optional 
   Type: integer 
   Example: <ICMP_Icmp_Seq>0</ICMP_Icmp_Seq> 

   ICMP_Icode  

   Checks the value of specific ICMP code. When the content of this 
   element contain "<" and ">" signs, it MUST be put into 
   <![CDATA[...]]> section. In other way it MAY contain CDATA section, 
   but it is not REQUIRED. 

   Allowed signs: <, >, number 
   Location: Protocol, Type=="ICMP" 
   Presence: single, optional 
   Type: String 
   Example: <ICMP_Icode><![CDATA[>25]]></ICMP_Icode> 

   ICMP_Itype  

   Checks the value of specified ICMP type. When the content of this 
   element contain "<" and ">" signs, it MUST be put into 
   <![CDATA[...]]> section. In other way it MAY contain CDATA section, 
   but it is not REQUIRED. 

   Allowed signs: <, >, number 
   Location: Protocol, Type=="ICMP" 
   Presence: single, optional 
   Type: String 
   Example: <ICMP_Itype><![CDATA[>25]]></ICMP_Itype> 

   IP_Ttl 

   Specifies IP time-to-live value. When the content of this element 
   contain "<" and ">" signs, it MUST be put into <![CDATA[...]]> 
   section. In other way it MAY contain CDATA section, but it is not 
   REQUIRED. 

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 13] 

Internet-Draft                  CIDSS                   September 2008 
    

   Allowed signs: <, >, <=, >=,-, number  
   Location: Protocol, Type=="IP" 
   Presence: single, optional 
   Type: string 
   Example: <IP_Ttl>6-8<IP_Ttl> - 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: <IP_Tos>2</IP_Tos> 

   IP_Fragbits 

   Checks fragmentations bits for the specified value 

   Location: Protocol, Type=="IP" 
   Presence: single, optional 
   Type: String 
   Example: <IP_Fragbits>DM+</IP_Fragbits> 

   IP_Id 

   Checks ID field in IP protocol for the specified value 

   Location: Protocol, Type=="IP" 
   Presence: single, optional 
   Type: integer 
   Example: <IP_Id>34222</IP_Id> 

   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: <IP_Ipopts>lsrr</IP_Ipopts> 

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 14] 

Internet-Draft                  CIDSS                   September 2008 
    

   IP_Dsize  

   Checks size of packet data field. When the content of this element 
   contain "<" and ">" signs, it MUST be put into <![CDATA[...]]> 
   section. In other way it MAY contain CDATA section, but it is not 
   REQUIRED. 

   Allowed signs: <, >, <=, >=, number 
   Location: Protocol, Type=="IP" 
   Presence: single, optional 
   Type: String 
   Example: <IP_Dsize>34000</IP_Dsize> 

   IP_Ip_Proto 

   Checks IP protocol header for the specified value. When the content 
   of this element contain "<" and ">" signs, it MUST be put into 
   <![CDATA[...]]> section. In other way it MAY contain CDATA section, 
   but it is not REQUIRED. 

   Allowed signs: <, >, <=, >=, number, name 
   Location: Protocol, Type=="IP" 
   Presence: single, optional 
   Type: String 
   Example: <IP_Ip_Proto>igmp</IP_Ip_Proto> 

   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.  

   Presence: optional, single 
   Location: element Protocols  
   Example: <Proto_Logic>1 OR (2 AND 3)<Proto_Logic> 

    

2.5.4. Sources 

   This element contains information that describes properties of a 
   source of network communications. If Sources occurs more then once, 
   then every Sources MUST have an unique id (attribute) used in 
   Src_Logic that defines logical dependences between each of them.  

   Presence: mandatory, single 
   Location: element Signature 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 15] 

Internet-Draft                  CIDSS                   September 2008 
    

   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 A 

   Source_IP 

   This element MUST contain 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 IPv4 or IPv6 mask for the specified IP address. 

   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: <Source_IP Neg="false" Mask="8">$EXTERNAL_NET</Source_IP> 
   Variable $EXTERNAL_NET is defined in an IDS. (e.g. 
   $EXTERNAL_NET=1.2.3.4) 

   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. 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 16] 

Internet-Draft                  CIDSS                   September 2008 
    

   Attributes: Neg [presence: optional, type: boolean, allowed values: 
   true|false, default: false] 
   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: <Source_Port>any</Source_Port> 

   Src_Logic 

   Defines logical dependences between each Source description. Logical 
   operators: (, ), AND, OR 

   Location: Sources 
   Example: 2 OR (1 AND 3) 

    

2.5.5. 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, single 
   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. 

   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 

   Destination_IP 


 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 17] 

Internet-Draft                  CIDSS                   September 2008 
    

   This element MUST contain 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 destination address in order for the signature to apply. 
   Mask attribute defines IPv4 or IPv6 mask for the specified IP 
   address. 

   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 

   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. 

   Attributes: Neg [presence: optional, type: boolean, allowed values: 
   true|false, default: false] 
   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: <Destination_Port>445</Destination_Port> 

   Dst_Logic 

   Defines logical dependences between each Destination description. 
   Logical operators: (, ), AND, OR 

   Location: Destinations 
   Example: 1 AND 2 

    

2.5.6. Patterns 

   This element contains multiple Pattern elements.  
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 18] 

Internet-Draft                  CIDSS                   September 2008 
    

   Presence: single, mandatory (if Protocol is to tcp, udp, ip or 
   application than element is present) 
   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, string, 
   or using PCRE [5] expressions. 

   Presence: mandatory 
   Type: String 
   Location: element Pattern 
   Permitted values: "hex", "dec", "string", "pcre" 
   Default value: "string" 
   Example: <Pattern_Type>string</Pattern_Type> 

   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) [5]. If 
   Rawbytes attribute value is "true" it means pattern is searched in 
   raw packets ignoring decoding that was done by preprocessors. If Neg 
   attribute is true, it means pattern MUST NOT contain specified value. 


 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 19] 

Internet-Draft                  CIDSS                   September 2008 
    

   If the content of this element contain "<" and ">" signs, it MUST be 
   put into <![CDATA[...]]> section. In other way it MAY contain CDATA 
   section, but it is not REQUIRED. 

   Presence: mandatory, single 
   Attributes: CaseSensitive [allowed values: true|false, default value: 
   true], Rawbytes [allowed values: true|false, default value: false], 
   Neg [allowed values: true|false, default: false] 
   Type: Same as value of Pattern_Type 
   Location: element Pattern 
   Example: <Pattern_Content CaseSensitive="false">RETR 
   passwd</Pattern_Content> 

   Pattern_Pcre_Flags 

   Contains standard Perl Compatible_Regular_Expressions modifiers and 
   Perl compatible modifiers or Snort modifiers (used for Snort 
   compatibility) 

   Presence: optional, single 
   Location: element Pattern 
   Type: string 
   Example: <Pattern_Pcre_Flags>iRm</Pattern_Pcre_Flags> 

   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: <Pattern_Depth>10</Pattern_Depth> 

   Pattern_Uricontent 

   This element describes content of packet in URI format. If this 
   element contains restricted characters (as described in section 2.2) 
   it MUST be put into <![CDATA[...]]> section. In other way it MAY 
   contain CDATA section, but it is not REQUIRED. 

   Type: string 
   Location: Pattern 
   Presence: optional, single 
   Example: 

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 20] 

Internet-Draft                  CIDSS                   September 2008 
    

   <Pattern_Uricontent><![CDATA[local/apache/htdocs/]]></Pattern_Uricont
   ent> 

   Pattern_Offset 

   Specifies offset in bytes from beginning of packet to search for the 
   pattern.  

   Type: integer 
   Location: Pattern 
   Presence: optional, single 
   Example: <Pattern_Offset>5</Pattern_Offset> 

   Pattern_Within 

   Used to describe how many packets MUST be at most between two 
   patterns. 

   Type: integer 
   Location: Pattern 
   Presence: optional, single 
   Example: <Pattern_Within>4</Pattern_Within> 

   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: <Pattern_Distance>3</Pattern_Distance> 

   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: <Pat_Logic>(NOT 1 AND 2) OR 3<Pat_Logic> 

   Logged_Packets 

   Number of packets logged when the system detects an intrusion 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 21] 

Internet-Draft                  CIDSS                   September 2008 
    

   Presence: optional, single 
   Location: element Signature 
   Type: Integer 
   Example: <Logged_Packets>0</Logged_Packets> 

   Message 

   Contains the message generated by the IDS when a packet described by 
   this signature was detected. If the content of this element contain 
   "<" and ">" signs, it MUST be put into <![CDATA[...]]> section. In 
   other way it MAY contain CDATA section, but it is not REQUIRED. 

   Presence: mandatory, single 
   Location: element Signature 
   Type: String 
   Example: <Message>FTP password file GET request</Message> 

   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. If 
   the content of this element contains "<" and ">" signs, it MUST be 
   put into <![CDATA[...]]> section. In other way it MAY contain CDATA 
   section, but it is not REQUIRED. 

   Presence: optional, multiple 
   Location: element Signature 
   Type: String 
   Example: <Comment>Vendor: Arachnids</Comment> 

    

2.5.7. 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], 
   Session_Identification [single, optional], Session_Instructions 
   [single, optional] 

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 22] 

Internet-Draft                  CIDSS                   September 2008 
    

   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 element is present 
   Contained elements: Session_Timeout [single, optional], 
   Session_Pckt_Count [single, optional] 

   Session_Pckt_Count 

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 23] 

Internet-Draft                  CIDSS                   September 2008 
    

   Defines maximum number of packets that are considered during session. 

   Presence: single, optional 
   Location: Session_End 
   Type: Integer 
   Example: <Session_Pckt_Count>5</Session_Pckt_Count> 

   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: <Session_Timeout>10s</Session_Timeout> 
   Example description: 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. 

   Type: Boolean 
   Presence: single, optional 
   Location:  Session_Identification 

   Same_Source_Port 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 24] 

Internet-Draft                  CIDSS                   September 2008 
    

   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. 

   Type: Boolean 
   Presence: single, optional 
   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. 

   Type: Boolean 
   Presence: single, optional 
   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. 

   Type: Boolean 
   Presence: single, optional 
   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. 

   Type: Boolean 
   Presence: single, optional 
   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. 

   Type: Boolean 
   Presence: single, optional 
   Location:  Session_Identification 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 25] 

Internet-Draft                  CIDSS                   September 2008 
    

   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, 
   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. 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 26] 

Internet-Draft                  CIDSS                   September 2008 
    

   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 
   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, Isnotset_Var, 
   Compare_Var, Toggle_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] 

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 27] 

Internet-Draft                  CIDSS                   September 2008 
    

   Isnotset_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 not 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 

   Sets value of "var" attribute in state of particular session. 

   Location: Case_State_Instructions 
   Presence: multiple, optional 
   Attributes: var [type: string; single, mandatory], value [type: 
   string; single, mandatory] 

   Unset_Var 

   Nullifies value of "var" used in this session. 

   Location: Case_State_Instructions 
   Presence: multiple, optional 
   Attributes: var [type: string; single, mandatory] 

   Toggle_Var 

   Toggle value of "var" attribute in state of particular session. Set 
   the specified state if the state is unset, otherwise unsets the state 
   if the state is set. 

   Location: Case_State_Instructions 
   Presence: multiple, optional 
   Attributes: var [type: string; single, mandatory], value [type: 
   string; single, mandatory] 

    

 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 28] 

Internet-Draft                  CIDSS                   September 2008 
    

3. Conventions used in this document 

   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 

   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 [1]. 

4. 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 is 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. 

5. IANA Considerations 

   There are no IANA issues in this document. 

   The RFC Editor may remove this section prior to publication. 

6. Acknowledgments 

   This document was prepared using 2-Word-v2.0.template.dot. 

















 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 29] 

Internet-Draft                  CIDSS                   September 2008 
    

7. References 

7.1. Normative References 

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
         Levels", BCP 14, RFC 2119, March 1997. 

   [2]  Markup Language (XML) 1.0, Third Edition, 
         http://www.w3.org/TR/2004/REC-xml-20040204/ 

   [3]  XML Schema - Specifications and Development, 
         http://www.w3.org/XML/Schema#dev 

   [4]  Roesch Martin, Green Chris, "Snort Users Manual", 2.3.0, 
         January 2005, http://www.snort.org 

   [5]  PCRE - Perl Compatible Regular Expressions, 
         http://www.pcre.org/ 

7.2. Informative References 

   [6]  Dragon. Intrusion Detection System. Topics on Writing 
         Signatures" Enterasys Networks, 2002, 
         http://dragon.enterasys.com 

   [7]  Shoki, "Shoki User's Guide", Release 0.3.0, 
         http://shoki.sourceforge.net/ 

   [8]  ISS - Internet Security Systems, Documentation, 
         http://www.iss.net/support/documentation/ 

   [9]  Cisco - NetRanger, Documentation, 
         http://www.cisco.com/univercd/cc/td/doc/product/iaabu/netrangr/ 

   [10] 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 

   [11] McLaughlin Brett, Java & XML, 2nd Edition,  
         ISBN: 0-596-00197-5 

   [12] 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 


 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 30] 

Internet-Draft                  CIDSS                   September 2008 
    

   [13] arachNIDS - Whitehats Network Security Resource, 
         http://whitehats.com/ids/ 











































 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 31] 

Internet-Draft                  CIDSS                   September 2008 
    

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. 
    
   <?xml version="1.0" encoding="utf-8" ?> 
   <Signatures xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:noNamespaceSchemaLocation="cidss.xsd"> 
      <Signature SID="1"> 
      <Enabled>true</Enabled> 
      <Sig_Source>snort</Sig_Source> 
      <Action>alert</Action> 
      <Description>NETBIOS SMB-DS DCERPC Remote Activation bind attempt; 
   sid=2252</Description> 
      <Message>NETBIOS SMB-DS DCERPC Remote Activation bind 
   attempt</Message> 
      <Comment>reference: cve,CAN-2003-0528</Comment> 
      <Comment>reference: cve,CAN-2003-0605</Comment> 
      <Comment>reference: cve,CAN-2003-0715</Comment> 
      <Comment>reference: 
   url,www.microsoft.com/technet/security/bulletin/MS03-
   039.mspx</Comment> 
      <Sources ID="1"> 
         <Source Src_ID="1"> 
            <Source_IP neg="false" mask="0">any</Source_IP> 
            <Source_Port>any</Source_Port> 
         </Source> 
         <Source Src_ID="2"> 
            <Source_IP neg="true" mask="8">10.0.0.0</Source_IP> 
            <Source_Port>any</Source_Port> 
         </Source> 
         <Source Src_ID="3"> 
            <Source_IP neg="true" mask="24">192.168.1.0</Source_IP> 
            <Source_Port>any</Source_Port> 
         </Source> 
         <Src_Logic>1 AND 2 AND 3</Src_Logic> 
      </Sources> 
      <Destinations ID="2"> 
         <Destination Dst_ID="1"> 
            <Destination_IP neg="false" mask="0">any</Destination_IP> 
            <Destination_Port>445</Destination_Port> 
         </Destination> 
         <Destination Dst_ID="2"> 
            <Destination_IP neg="true" 
   mask="24">192.168.1.0</Destination_IP> 
            <Destination_Port>445</Destination_Port> 
         </Destination> 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 32] 

Internet-Draft                  CIDSS                   September 2008 
    

         <Destination Dst_ID="3"> 
            <Destination_IP neg="true" 
   mask="8">10.0.0.0</Destination_IP> 
            <Destination_Port>445</Destination_Port> 
         </Destination> 
         <Dst_Logic>1 AND 2 AND 3</Dst_Logic> 
      </Destinations> 
      <Protocols ID="3"> 
         <Protocol Proto_ID="1" Type="tcp"> 
            <TCP_State>established</TCP_State> 
         </Protocol> 
         <Proto_Logic>1</Proto_Logic> 
      </Protocols> 
      <Patterns ID="4"> 
         <Pattern Pat_ID="1"> 
          <Pattern_Type>string</Pattern_Type> 
            <Pattern_Content 
   CaseSensitive="false"><![CDATA[|FF|SMB%]]></Pattern_Content> 
            <Pattern_Depth>5</Pattern_Depth> 
            <Pattern_Offset>4</Pattern_Offset> 
         </Pattern> 
         <Pattern Pat_ID="2"> 
          <Pattern_Type>string</Pattern_Type> 
            <Pattern_Content 
   CaseSensitive="true"><![CDATA[&|00|]]></Pattern_Content> 
            <Pattern_Within>2</Pattern_Within> 
            <Pattern_Distance>56</Pattern_Distance> 
         </Pattern> 
         <Pattern Pat_ID="3"> 
          <Pattern_Type>string</Pattern_Type> 
            <Pattern_Content CaseSensitive="false">|5C 
   00|P|00|I|00|P|00|E|00 5C 00|</Pattern_Content> 
            <Pattern_Within>12</Pattern_Within> 
            <Pattern_Distance>5</Pattern_Distance> 
         </Pattern> 
         <Pattern Pat_ID="4"> 
          <Pattern_Type>hex</Pattern_Type> 
            <Pattern_Content CaseSensitive="true">05</Pattern_Content> 
            <Pattern_Within>1</Pattern_Within> 
         </Pattern> 
         <Pattern Pat_ID="5"> 
          <Pattern_Type>hex</Pattern_Type> 
            <Pattern_Content CaseSensitive="true">0B</Pattern_Content> 
            <Pattern_Within>1</Pattern_Within> 
            <Pattern_Distance>1</Pattern_Distance> 
         </Pattern> 
         <Pattern Pat_ID="6"> 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 33] 

Internet-Draft                  CIDSS                   September 2008 
    

          <Pattern_Type>string</Pattern_Type> 
            <Pattern_Content CaseSensitive="true">|B8|J|9F|M|1C|}|CF 11 
   86 1E 00| |AF|n|7C|W</Pattern_Content> 
            <Pattern_Within>16</Pattern_Within> 
            <Pattern_Distance>29</Pattern_Distance> 
         </Pattern> 
         <Pat_Logic>1 AND 2 AND 3 AND 4 AND 5 AND 6</Pat_Logic> 
      </Patterns> 
      <Session> 
         <Session_Filter>(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)</Session_Filter> 
         <Session_End> 
            <Session_Pckt_Count>5</Session_Pckt_Count> 
         </Session_End> 
      </Session> 
      </Signature> 
   </Signatures> 
    



























 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 34] 

Internet-Draft                  CIDSS                   September 2008 
    

APPENDIX B: The schema of CIDSS - common.xsd 

   Available at http://cidss.sourceforge.net/down/common_v2.3.xsd 

 









































 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 35] 

Internet-Draft                  CIDSS                   September 2008 
    

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 
    

Full Copyright Statement 

   Copyright (C) The IETF Trust (2008). 

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Disclaimer of Validity 

    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
 
Wierzbicki et al.       Expires March 4, 2009                [Page 36] 

Internet-Draft                  CIDSS                   September 2008 
    

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 March 4, 2009                [Page 37]