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