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