idnits 2.17.1
draft-wierzbicki-cidss-02.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 3978, Section 5.1 on line 34.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1536.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1547.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1554.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1560.
** 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.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
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 2005) is 6768 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)
== Missing Reference: 'FSRPAU120' is mentioned on line 481, but not defined
== Unused Reference: 'RFC2119' is defined on line 1473, but no explicit
reference was found in the text
== Unused Reference: 'IDWG11' is defined on line 1476, but no explicit
reference was found in the text
== Unused Reference: 'JAVAXML' is defined on line 1481, but no explicit
reference was found in the text
== Unused Reference: 'CIDSL' is defined on line 1484, but no explicit
reference was found in the text
== Unused Reference: 'ARACH' is defined on line 1490, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'SNORTman'
-- Possible downref: Non-RFC (?) normative reference: ref. 'DRAGON'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SHOKIug'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML10'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XSD'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ISSdoc'
-- Possible downref: Non-RFC (?) normative reference: ref. 'CISCOdoc'
-- Possible downref: Non-RFC (?) normative reference: ref. 'PCRE'
== Outdated reference: A later version (-16) exists of
draft-ietf-idwg-idmef-xml-11
Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 16 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-02.txt Polish-Japanese
6 Institute of
7 Information
8 Technology
9 Expires: April 2006 October 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 obsoleted 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, each author represents that any
32 applicable patent or other IPR claims of which he or she is aware
33 have been or will be disclosed, and any of which he or she becomes
34 aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Common Intrusion Detection Signatures Standard October 2005
52 Conventions used in this document
54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
56 document are to be interpreted as described in RFC 2119.
58 Table of Contents
60 Status of this Memo...............................................1
61 Abstract..........................................................1
62 Conventions used in this document.................................2
63 Table of Contents.................................................2
64 1. Introduction...................................................2
65 1.1 About CIDSS................................................2
66 1.2 Potential Applications of CIDSS............................3
67 2. XML CIDSS Signatures...........................................4
68 2.1 Structure of a CIDSS document..............................4
69 2.2 Structure of a CIDSS signature.............................5
70 2.3 Data types used by the Pattern_Content element.............6
71 2.4 Logical expressions used in CIDSS signature definitions....6
72 2.5 XML elements and attributes used in CIDSS..................6
73 2.5.1 Signatures...........................................7
74 2.5.2 Signature............................................7
75 2.5.3 Protocols............................................8
76 2.5.4 Sources.............................................14
77 2.5.5 Destinations........................................14
78 2.5.6 Patterns............................................16
79 2.5.7 Session.............................................20
80 3. Security Considerations.......................................25
81 Appendix A.......................................................27
82 Appendix B.......................................................29
83 References.......................................................29
84 Normative references.............................................29
85 Informative references...........................................30
86 Author's Addresses...............................................30
87 Comments to:.....................................................30
88 Copyright Notice.................................................31
89 Disclaimer of Validity...........................................31
90 Intellectual Property Statement..................................31
91 IANA Considerations..............................................31
93 1. Introduction
95 1.1 About CIDSS
97 Common Intrusion Detection Signatures Standard is intended to be a
98 standard format of signatures used widely in Network Intrusion
99 Detection Systems (NIDS). An IDS is controlled by a set of decision
100 rules. A decision rule of an IDS is composed of two components: a
101 description of specific characteristics of an intrusion attempt (a
102 signature) and an action that has to be carried out when the data
103 Common Intrusion Detection Signatures Standard October 2005
105 provided by IDS sensors matches the signature. This document focuses
106 on the remaining part of an IDS decision rule: the IDS signature.
108 Currently, every IDS uses a different format of signatures. CIDSS
109 defines a common format of signatures that attempts to express all
110 information contained in signatures of various IDS. The CIDSS
111 signature format is based on XML to facilitate the adaptation and
112 applications of the proposed standard. The CIDSS signature format is
113 designed to be extensible, and therefore it SHOULD be simple to
114 incorporate features of future and current IDS systems that have not
115 been taken into account in the first design.
117 The main goal of CIDSS is to enable administrators of IDS systems to
118 share, compare, evaluate and criticize signatures used to detect
119 intrusion events. The increasingly dynamic, global, and frequent
120 nature of intrusion attempts is a trend that forces administrators to
121 greater efforts to protect increasingly valuable information. The
122 possibility to disseminate knowledge and experience about IDS
123 systems' operation would be enhanced by the introduction of a common
124 signature format. Therefore the use of a common IDS signature format
125 SHOULD lead to a greater security of information. Other possible
126 applications of CIDSS will be discussed in the next section.
128 CIDSS Homepage: http://cidss.b59.net
130 1.2 Potential Applications of CIDSS
132 One of the main applications of CIDSS is the translation of
133 signatures between various IDS. The ability to translate a signature
134 of an IDS into the common data format and to carry out a reverse
135 translation implies that it SHOULD be possible to translate
136 signatures of different IDS using the common data format as an
137 intermediate form. The development of this standard has been carried
138 out in parallel with the development of an IDS signature translator.
139 Currently, the translator is able to translate signatures of Snort
140 [SNORTman] and Dragon [DRAGON] IDS into the common format, and among
141 the three systems. It's also partially tested with: Shoki [SHOKIug],
142 ISS RealSecure(TM) [ISSdoc], and Cisco NetRanger(TM) [CISCOdoc]. The
143 IDS translator is developed under the GNU General Public License and
144 is available from http://translator.b59.net.
146 Another possible application of CIDSS would be the creation and
147 maintenance of signature databases by independent providers of IDS
148 signatures. The use of XML as a base for the common signature format
149 enables a simple integration of collections of signatures into a
150 database. This SHOULD improve the searching and management of a
151 signature collection. The business model of an independent signature
152 provider could be the delivery of up-to-date, comprehensive signature
153 collections to increase security of specific services, systems and
154 platforms.
156 Common Intrusion Detection Signatures Standard October 2005
158 -------------------------------------
159 | First part of a signature |
160 | ... |<-------|--|
161 | ... |<-------|--|
162 | ... |<-------|--|
163 | ... |<-------|--|
164 ------------------------------------- | |
165 ------------------------------------------- | |
166 | Second part of a signature | | |
167 | | | |
168 | ... | | |
169 | ... | | |
170 | | | |
171 | ... | | |
172 | | | |
173 | ...|----- |
174 | | |
175 | ... |---------
176 | |
177 | |
178 -------------------------------------------
180 Figure 1. The main components and logical structure of a CIDSS
181 signature
183 2. XML CIDSS Signatures
185 This section describes the logical and structural rules for creating
186 signatures in CIDSS format. Each XML element and attribute used in
187 the CIDSS format are described and explained on examples. In appendix
188 A, a full CIDSS signature is provided that has been used to provide
189 the examples used in this section.
190 CIDSS meets XML ver. 1.0 requirements [XML10]. CIDSS is defined as a
191 dialect of XML using the XML Schema Definition (XSD). The schema of
192 CIDSS is an appendix to this document (see appendix B: CIDSS XSD
193 schema. cidss.xsd)
195 2.1 Structure of a CIDSS document
197 A CIDSS document is a collection of signatures. Each signature is
198 independent, and can be stored in a separate CIDSS document or
199 Common Intrusion Detection Signatures Standard October 2005
201 together with other signatures. The main XML element of a CIDS
202 document is the "Signatures" element.
204 2.2 Structure of a CIDSS signature
206 A CIDSS signature is composed of several XML elements, contained in a
207 common "Signature" element. A signature can be divided into two
208 basic, logical parts. The first part, that includes (among others)
209 the elements "Sources", "Destinations", "Protocols" and "Patterns",
210 is used to define building blocks of a signature definition. These
211 blocks are combined in the second part of a signature, and are kept
212 separate in order to shorten the signature definition and avoid
213 redundancy. For instance, the definition of relevant information
214 about the TCP protocol might be kept inside the "Protocols" element
215 and might be later combined with several patterns (defined inside the
216 "Patterns" element). Rather than repeat the definition of the TCP
217 protocol each time a new pattern is used, the signature definition
218 will refer to the information kept inside the "Protocols" element.
219 The second part of a signature contains information on how to use the
220 building blocks defined in the first part. The main XML element of
221 the second part of a signature is the "Session" element. A "Session"
222 element defines the main signature behavior. A signature MAY use
223 state managed by the IDS for a certain flow of packets (or session).
224 However, it is possible to create stateless signatures, by omitting
225 information REQUIRED for the state mechanisms to work. Then, the
226 information contained in a "Session" element defines the conditions
227 that MUST be fulfilled by sensor data in order to trigger the
228 signature.
229 In the second part of a signature, the information contained in the
230 first part is combined using logical expressions. Each element in the
231 first part of a signature that contains a "building block" for the
232 signature definition MUST have an identifier that is unique in the
233 signature (not necessarily in the CIDSS document that contains the
234 signature). This identifier can be used in the second part of a
235 signature to refer to the "building block" defined by this element.
236 The building blocks MAY be combined using logical expressions that
237 are constructed by the "AND" and "OR" operators. The logical
238 expressions are contained in special tags, and are treated as strings
239 by the XML parser. CIDSS logical expressions are described in section
240 2.4.
242 When the content of element contain "<" (less then), ">" (greater
243 then), "&" (ampersand), "'" (apostrophe) or """ (quotation mark)
244 signs, it MUST be put into CDATA section. A CDATA section starts with
245 "".
246 Only the characters "<" and "&" are strictly illegal in XML.
247 Apostrophes, quotation marks and greater than signs are legal, but it
248 is a good habit to replace them.
249 Note: A CDATA section cannot contain the string "]]>"
250 Common Intrusion Detection Signatures Standard October 2005
252 2.3 Data types used by the Pattern_Content element
254 The data types used in CIDSS signatures are compatible with the
255 XML[XML10] and XML Schema (XSD) [XSD] specification. The following
256 data types are supported:
258 - String values
259 You MUST use encoding defined by "encoding" attribute (e.g. ). UTF-8 RECOMMENDED. Refer to
261 Appendix A and Appendix B
262 - Hexadecimal values
263 - Decimal values
265 2.4 Logical expressions used in CIDSS signature definitions
267 Some elements in the CIDSS signature contain information that
268 describes how other elements MUST be combined in the signature
269 definitions. The content of these elements is a String value that
270 contains a logical expression. A translating software MUST be able to
271 process these expressions.
272 CIDSS logical expressions MUST use operators "AND", "OR", and "NOT"
273 (uppercase). The operators are interpreted as follows:
275 - AND - logical conjunction
276 - OR - logical alternative
277 - NOT - logical negation
279 The operator precedence in CIDSS logical expressions MUST be
280 interpreted as follows: NOT precedes AND precedes OR.
281 CIDSS logical expressions MAY contain ordinary braces "(" or ")" that
282 are interpreted as in logical expressions.
283 Apart from braces and operators, CIDSS logical expressions MUST
284 contain unique identifiers of other XML elements in the CIDSS
285 signature definition that MAY be used in logical expressions.
287 2.5 XML elements and attributes used in CIDSS
289 In this section, all XML elements defined by the CIDSS standard SHALL
290 be introduced. Each element will be defined using a common template
291 to simplify a presentation. This template is explained below:
293 Element name
295 Element description.
296 Presence: [mandatory | optional, single | multiple]
297 Location: element name
298 Attributes: attribute name [type [, unique]]
299 Contained elements: element names
301 mandatory - means that the element MUST exist in the signature
302 optional - the element MAY exist in the signature
303 Common Intrusion Detection Signatures Standard October 2005
305 single - if the element exists in the signature, then this element
306 MUST exist in exactly one instance
307 multiple - if the element exists in the signature, then this element
308 MAY exist many instances
309 unique - value of the element MUST NOT be repeated as value of the
310 same element in other place
312 2.5.1 Signatures
314 A root element of a CIDSS XML document.
316 Presence: mandatory, single
317 Location: root element
318 Contained elements: Signature [multiple, mandatory]
319 Example:
320
322 where "" SHOULD be replaced by the filename of the
323 XSD schema file (e.g. cidss.xsd)
325 2.5.2 Signature
327 This element contains all information about a signature. Describes
328 conditions required to identify traffic as suspicious and to take an
329 action.
331 Presence: mandatory
332 Location: element Signatures
333 Attributes: SID [type: integer, single, mandatory, unique]
334 Contained elements: Enabled [single, mandatory], Sig_Source [single,
335 optional], Description [single, optional], Action [single, optional],
336 Protocols [multiple, mandatory], Sources [multiple, mandatory],
337 Destinations [multiple, mandatory], Patterns [single, mandatory],
338 Logged_Packets [single, optional], Message [single,
339 optionalmandatory], Comment [multiple, optional], Session [single,
340 mandatory]
341 Example: See Appendix A
343 Enabled
345 Defines a current signature state. Setting this to true, the
346 signature will be analyzed by the IDS. Otherwise the signature SHOULD
347 be skipped.
349 Presence: mandatory
350 Type: Boolean
351 Default value: true
352 Location: element Signature
353 Example: true
354 Common Intrusion Detection Signatures Standard October 2005
356 Sig_Source
358 Optional element for use in translators. Specifies the IDS from which
359 the signature was translated or ported. This element SHOULD contain
360 string that identifies a signature source.
362 Presence: optional, single
363 Type: String
364 Location: element Signature
365 Example: Snort
367 Description
369 This element MAY contain a simple description of the signature.
371 Presence: optional
372 Type: String
373 Location: element Signature
374 Example: Try to get passwd file using ftp
376 Action
378 This MAY define actions performed by an IDS after intrusion detection
379 Suggested values: drop, allow, alert, and warning
381 Presence: optional, single
382 Type: String
383 Location: element Signature
384 Example: alert
386 2.5.3 Protocols
388 This element contains description of multiple protocols used in
389 potential attack.
391 Location: Signature
392 Presence: mandatory, multiple
393 Attributes: ID[integer,unique]
395 Protocol
397 The element used to describe the network protocol. Options of the
398 protocol used in this element depend on a protocol type.
399 The Proto_ID attribute is used for identification in the Proto_Logic
400 element - it is REQUIRED only when there is more than one Protocol in
401 the Protocols element.
403 Presence: mandatory, multiple.
404 Type: String
405 Attributes: Proto_ID [integer, unique], Type [enum: tcp, udp, ip,
406 icmp, application]
407 Common Intrusion Detection Signatures Standard October 2005
409 Location: element Signature
410 Contained elements: TCP_Ack [single, optional], TCP_State [single,
411 optional], TCP_Seq [single, optional], TCP_Dsize [single, optional],
412 TCP_Flags [single, optional], TCP_Window [single, optional],
413 UDP_Dsize [single, optional], ICMP_Dsize [single, optional],
414 ICMP_Icmp_Id [single, optional], ICMP_Icmp_Seq [single, optional],
415 ICMP_Icode [single, optional], ICMP_Itype [single, optional], IP_Ttl
416 [single, optional], IP_Tos [single, optional], IP_Ipopts [single,
417 optional], IP_Fragbits [single, optional], IP_Id [single, optional],
418 IP_Ip_Proto [single, optional], IP_Dsize [single, optional], Isdataat
419 [single, optional], Rpc [single, optional]
421 Isdataat
423 Checks that the data fields in the packet are in the specified
424 offset. When the content of this element contain "<" and ">" signs,
425 it MUST be put into section. In other way it MAY
426 contain CDATA section, but it is not REQUIRED.
428 Allowed values: Integer or integer (more than a given value)
430 Location: Protocol
431 Presence: single, optional
432 Example:
434 Rpc
436 This element specifies the RPC application, version, and procedure
437 numbers in SUNRCP call requests. It MUST contain a string in the
438 following format:
440 Allowed format: , [|*],
441 [|*]>
442 Location: Protocol, Type=="Application"
443 Presence: single, optional
444 Type: String
445 Example: 100000,*,3
447 TCP_Ack
449 Checks the specific TCP ack number
451 Location: Protocol, Type=="TCP"
452 Presence: single, optional
453 Type: integer
454 Example: 0
456 TCP_Seq
458 Checks the specific TCP seq number
459 Common Intrusion Detection Signatures Standard October 2005
461 Location: Protocol, Type=="TCP"
462 Presence: single, optional
463 Type: integer
464 Example: TCP_Seq>0
466 TCP_State
468 Describes current protocol state e.g. established, stateless
470 Location: Protocol, Type=="TCP"
471 Allowed values: [established|stateless]
472 Presence: single, optional
473 Type: string
474 Example: established
476 TCP_Flags
478 Check if the specific TCP Flags are present
480 Location: Protocol, Type=="TCP"
481 Allowed values: [!|*|+][FSRPAU120]
482 Values description: F-FIN, S-SYN, R-RST, P-PSH, A-ACK, U-URG, 1-
483 Reserved bit 1, 2-Reserved bit 2, 0-No Flags set.
484 Modifiers description: + - match on the specific bits, plus any
485 others, * - match if any of the specified bits are set, ! - match if
486 specified bits are not set
487 Presence: multiplesingle, optional
488 Type: String
489 Example: +SA
491 TCP_Window
493 Checks value of the TCP window size
495 Location: Protocol, Type=="TCP"
496 Presence: single, optional
497 Type: integer
498 Example: 34000
500 TCP_Dsize
502 Checks the packet data field size in TCP protocol. When the content
503 of this element contain "<" and ">" signs, it MUST be put into
504 section. In other way it MAY contain CDATA section,
505 but it is not REQUIRED.
507 Allowed signs: <, >, <=, >=, number
508 Location: Protocol, Type=="TCP"
509 Presence: single, optional
510 Type: String
511 Example:
512 Common Intrusion Detection Signatures Standard October 2005
514 UDP_Dsize
516 Checks packet data field size in UDP protocol. When the content of
517 this element contain "<" and ">" signs, it MUST be put into
518 section. In other way it MAY contain CDATA section,
519 but it is not REQUIRED.
521 Allowed signs: <, >, <=, >=, number
522 Location: Protocol, Type=="UDP"
523 Presence: single, optional
524 Type: String
525 Example:
527 ICMP_Dsize
529 Checks the packet data field size in ICMP protocol. When the content
530 of this element contain "<" and ">" signs, it MUST be put into
531 section. In other way it MAY contain CDATA section,
532 but it is not REQUIRED.
534 Allowed signs: <, >, <=, >=, number
535 Location: Protocol, Type=="ICMP"
536 Presence: single, optional
537 Type: String
538 Example: =64]]>
540 ICMP_Icmp_Id
542 Checks the value of specific ICMP ID
544 Location: Protocol, Type=="ICMP"
545 Presence: single, optional
546 Type: integer
547 Example: 0
549 ICMP_Icmp_Seq
551 Checks the value of ICMP sequence
553 Location: Protocol, Type=="ICMP"
554 Presence: single, optional
555 Type: integer
556 Example: 0
558 ICMP_Icode
560 Checks the value of specific ICMP code. When the content of this
561 element contain "<" and ">" signs, it MUST be put into
562 section. In other way it MAY contain CDATA section,
563 but it is not REQUIRED.
565 Common Intrusion Detection Signatures Standard October 2005
567 Allowed signs: <, >, number
568 Location: Protocol, Type=="ICMP"
569 Presence: single, optional
570 Type: String
571 Example: 25]]>
573 ICMP_Itype
575 Checks the value of specified ICMP type. When the content of this
576 element contain "<" and ">" signs, it MUST be put into
577 section. In other way it MAY contain CDATA section,
578 but it is not REQUIRED.
580 Allowed signs: <, >, number
581 Location: Protocol, Type=="ICMP"
582 Presence: single, optional
583 Type: String
584 Example: 25]]>
586 IP_Ttl
588 Specifies IP time-to-live value. When the content of this element
589 contain "<" and ">" signs, it MUST be put into
590 section. In other way it MAY contain CDATA section, but it is not
591 REQUIRED.
593 Allowed signs: <, >, <=, >=,-, number
594 Location: Protocol, Type=="IP"
595 Presence: single, optional
596 Type: string
597 Example: 6-8 - values between 6 and 8
599 IP_Tos
601 Check the IP ToS field for specified value
602 Location: Protocol, Type=="IP"
604 Presence: single, optional
605 Type: integer
606 Example: 2
608 IP_Fragbits
610 Checks fragmentations bits for the specified value
612 Location: Protocol, Type=="IP"
613 Presence: single, optional
614 Type: String
615 Example: DM+
617 IP_Id
618 Common Intrusion Detection Signatures Standard October 2005
620 Checks ID field in IP protocol for the specified value
622 Location: Protocol, Type=="IP"
623 Presence: single, optional
624 Type: integer
625 Example: 34222
627 IP_Ipopts
629 This element checks if the specified IP option is present.
631 Allowed values: rr - Record route, eol - end of list, nop - no op, ts
632 - Time Stamp, sec - IP security option, lsrr - Loose source routing,
633 ssrr - Strict source routing, satid - Stream identifier, any - any IP
634 options are set
635 Location: Protocol, Type=="IP"
636 Presence: single, optional
637 Type: String
638 Example: lsrr
640 IP_Dsize
642 Checks size of packet data field. When the content of this element
643 contain "<" and ">" signs, it MUST be put into
644 section. In other way it MAY contain CDATA section, but it is not
645 REQUIRED.
647 Allowed signs: <, >, <=, >=, number
648 Location: Protocol, Type=="IP"
649 Presence: single, optional
650 Type: String
651 Example: 34000
653 IP_Ip_Proto
655 Checks IP protocol header for the specified value. When the content
656 of this element contain "<" and ">" signs, it MUST be put into
657 section. In other way it MAY contain CDATA section,
658 but it is not REQUIRED.
660 Allowed signs: <, >, <=, >=, number, name
661 Location: Protocol, Type=="IP"
662 Presence: single, optional
663 Type: String
664 Example: igmp
666 Proto_Logic
668 This element describes logical rules to combine the information in
669 Protocol elements contained in one Protocols element. Logical
670 operators in Proto Logic element are described in section 2.4.
672 Common Intrusion Detection Signatures Standard October 2005
674 Presence: optional, single
675 Location: element Patterns Protocols
676 Example: 1 OR (2 AND 3)
678 2.5.4 Sources
680 This element contains information that describes properties of a
681 source of network communications. If Sources occurs more then once,
682 then every Sourcs MUST have an unique id (attribute) used in
683 Src_Logic that defines logical dependences between each of them.
685 Presence: mandatory, multiple
686 Location: element Signature
687 Attributes: ID
688 Contained elements: Source[multiple, mandatory], Src_Logic [single,
689 optional]
690 Example: See Appendix A
692 Source
694 This element contains descriptions of source hosts. Src_ID attribute
695 is local (in one Sources element) id for use with the Src_Logic
696 element.
698 Presence: mandatory, multiple
699 Location: element Sources
700 Attributes: Src_ID [presence: mandatory if more than one Source_ in
701 one Sources element, type: integer, unique]
702 Contained elements: Source_IP[single, mandatory], Source_Port[single,
703 optional]
704 Example: See Appendix A
706 2.5.5 Destinations
708 This element contains information that describes properties of a
709 destination of network communications. If Destinations occurs more
710 then once, then every Destination MUST have an unique id (attribute)
711 used in Dst_Logic to define logical dependences between each of them.
713 Presence: mandatory, multiple
714 Location: element Signature
715 Contained elements: Destination [multiple, mandatory]
716 Example: See Appendix A
718 Destination
720 This element contains descriptions of destination hosts. Dst_ID
721 attribute is local (in one Destinations element) id for use with the
722 Dst_Logic element.
724 Common Intrusion Detection Signatures Standard October 2005
726 Presence: mandatory, multiple
727 Location: element Destinations
728 Attributes: Dst_ID [presence: mandatory if more than one Destination_
729 in one Destinations element, type: integer, unique]
730 Contained elements: Destination_IP [single, mandatory],
731 Destination_Port [single, optional]
732 Example: See Appendix A
734 Source_IP
736 This element contains an IPv4 or IPv6 network address in any
737 notation. The value "any" means that all addresses will be considered
738 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the
739 value of Neg attribute is "true", then the values specified in the
740 Source_IP element are interpreted as addresses that MUST NOT match
741 the source address in order for the signature to apply. Mask
742 attribute defines IP mask for current IP.
744 Allowed values: Any string
745 Attributes: Neg [presence: mandatory, type: boolean, allowed values:
746 true|false, default: false], Mask [presence: mandatory, type: string,
747 allowed values: mask in octet or bit notation]
748 Presence: mandatory, single
749 Type: String
750 Location: element Source
751 Example: $EXTERNAL_NET
752 Variable $EXTERNAL_NET is defined in an IDS. (e.g.
753 $EXTERNAL_NET=1.2.3.4)
755 Destination_IP
757 This element contains an IPv4 or IPv6 network address in any
758 notation. The value "any" means that all addresses will be considered
759 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the
760 value of Neg attribute is "true", then the values specified in the
761 Destination_IP element are interpreted as addresses that MUST NOT
762 match the source address in order for the signature to apply. Mask
763 attribute defines IP mask for current IP.
765 Allowed values: Any string
766 Attributes: Neg [presence: mandatory, type: boolean, allowed values:
767 true|false, default: false], Mask [presence: mandatory, type: string,
768 allowed values: mask in octet or bit notation]
769 Presence: mandatory, single
770 Type: String
771 Location: element Destination
772 Example: Similar as in Source_IP element
773 Common Intrusion Detection Signatures Standard October 2005
775 Source_Port
777 The value of this element is a port number or range of ports
778 expressed by two port numbers divided with a ":" sign. The "135:139"
779 expression means that all ports between 135 and 139 will be
780 considered, accounting ports 135 and 139. The value "any" means that
781 all ports will be considered.
782 Presence: If Protocol Type is set to tcp, udp or ip then mandatory,
783 if Protocol Type value is icmp then MUST NOT be set.
785 Type: String
786 Location: element Source
787 Example: any
789 Destination_Port
791 The value of this element is a port number or range of ports
792 expressed by two port numbers divided with a ":" sign. The "135:139"
793 expression means that all ports between 135 and 139 will be
794 considered, accounting ports 135 and 139. The value "any" means that
795 all ports will be considered.
797 Presence: If Protocol Type value is set to tcp, udp or ip then
798 mandatory, if Protocol Type value is icmp then MUST NOT be set.
799 Type: String
800 Location: element Destination
801 Example: 445
803 Src_Logic
805 Defines logical dependences between each Source description. Logical
806 operators: (, ), AND, OR
808 Location: Sources
809 Example: 2 OR (1 AND 3)
811 Dst_Logic
813 Defines logical dependences between each Destination description.
814 Logical operators: (, ), AND, OR
816 Location: Destinations
817 Example: 1 AND 2
819 2.5.6 Patterns
821 This element contains multiple Pattern elements.
823 Presence: mandatory, if Protocol is to tcp, udp, ip or application
824 than element is present.
826 Common Intrusion Detection Signatures Standard October 2005
828 Location: element Signature
829 Contained elements: Pattern [multiple, optional]
830 Attributes: ID[integer, unique]
831 Example: See Appendix A
833 Pattern
835 This element contains information about the content of a packet that
836 is considered as potentially dangerous. Attribute Pat_ID is used in
837 Pat_Logic element to define logical expressions using multiple
838 Pattern elements
840 Presence: mandatory, multiple
841 Location: element Patterns
842 Contained elements: Pattern_Type [single, mandatory], Pattern_Content
843 [single, optional], Pattern_Depth [single, optional],
844 Pattern_Uricontent [single, optional], Pattern_Offset [single,
845 optional], Pattern_Within [single, optional], Pattern_Distance
846 [single, optional]
847 Attributes: Pat_ID [integer, unique]
848 Example: See Appendix A
850 Pattern_Type
852 Using CIDSS you can specify patterns in hexadecimal, decimal, or
853 string
855 Presence: mandatory
856 Type: String
857 Location: element Pattern
858 Permitted values: "hex", "dec", "string"
859 Default value: "string"
860 Example: string
862 Pattern_Content
864 Defines packet content that is interpreted as an intrusion and
865 considered dangerous. To define the content, regular expressions can
866 be used in the Pattern_Content element. Regular expression MUST be in
867 the PCRE format (Perl Compatible Regular Expressions) [PCRE]. If
868 Rawbytes attribute value is "true" it means pattern is searched in
869 raw packets ignoring decoding that was done by preprocessors. If Neg
870 attribute is true, it means pattern MUST NOT contain specified value.
871 If the content of this element contain "<" and ">" signs, it MUST be
872 put into section. In other way it MAY contain CDATA
873 section, but it is not REQUIRED.
875 Presence: mandatory, single
876 Attributes: CaseSensitive [allowed values: true|false, default value:
877 true], Rawbytes [allowed values: true|false, default value: false],
878 Neg [allowed values: true|false, default: false]
879 Type: Same as value of Pattern_Type
880 Common Intrusion Detection Signatures Standard October 2005
882 Location: element Pattern
883 Example: RETR
884 passwd
886 Pattern_Depth
888 Defines how many bytes of the packet MUST be searched in order to
889 find the content defined in the Pattern_Content element that is
890 contained by the same Pattern element as this element.
892 Presence: optional, single
893 Location: element Pattern
894 Type: Integer
895 Example: 10
897 Pattern_Uricontent
899 This element describes content of packet in URI format. If content is
900 e.g. URL address it MAY be used in clear form in Pattern_Uricontent
901 without special signs. When the content of this element contain "<"
902 and ">" signs, it MUST be put into section. In other
903 way it MAY contain CDATA section, but it is not REQUIRED.
905 Type: string
906 Location: Pattern
907 Presence: optional, single
908 Example:
909
912 Pattern_Offset
914 Specifies offset in bytes from beginning of packet to search for the
915 pattern.
917 Type: integer
918 Location: Pattern
919 Presence: optional, single
920 Example: 5
922 Pattern_Within
924 Used to describe how many packets MUST be at most between two
925 patterns.
927 Type: integer
928 Location: Pattern
929 Presence: optional, single
930 Example: 4
931 Common Intrusion Detection Signatures Standard October 2005
933 Pattern_Distance
935 Defines how far the IDS SHOULD look into a packet for the specified
936 pattern relative to last match.
938 Type: integer
939 Location: Pattern
940 Presence: optional, single
941 Example: 3
943 Pat_Logic
945 This element describes logical rules to combine the information in
946 Pattern elements contained in one Patterns element. Logical operators
947 in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in
948 section 2.4).
950 Presence: optional, single
951 Location: element Patterns
952 Example: (NOT 1 AND 2) OR 3
954 Logged_Packets
956 Number of packets logged when the system detects an intrusion
958 Presence: optional, single
959 Location: element Signature
960 Type: Integer
961 Example: 0
963 Message
965 Contains the message generated by the IDS when a packet described by
966 this signature was detected. If the content of this element contain
967 "<" and ">" signs, it MUST be put into section. In
968 other way it MAY contain CDATA section, but it is not REQUIRED.
970 Presence: optionalmandatory, single
971 Location: element Signature
972 Type: String
973 Example: FTP password file GET request
975 Comment
977 This element MAY be used for additional comments and information
978 about the signature. The element MAY contain additional information
979 about signature vendor, vulnerability description, http links etc. If
980 the content of this element contain "<" and ">" signs, it MUST be put
981 into section. In other way it MAY contain CDATA
982 section, but it is not REQUIRED.
984 Presence: optional, multiple
985 Common Intrusion Detection Signatures Standard October 2005
987 Location: element Signature
988 Type: String
989 Example: Vendor: Arachnids
991 2.5.7 Session
993 Defines a session that could be identified by the signature if the
994 state mechanisms of an IDS could be used. Otherwise, the information
995 contained in this element describes the conditions that MUST be
996 satisfied by the sensor data in order to trigger the signature.
998 Location: Signature
999 Presence: single, mandatory
1000 Contained elements: Session_Filter [single, optional], Session_Start
1001 [single, optional], Session_End [single, optional],
1002 Session_Identification [single, optional], Session_Instructions
1003 [single, optional]
1005 Session_Filter
1007 Contains IDs of Source, Destination, Protocol and Pattern elements,
1008 combined using logical expressions in the format described in section
1009 2.4. The information contained in this element specifies the
1010 conditions that MUST be met by sensor data so that the packet will be
1011 included in this session.
1013 Location: Session
1014 Presence: single, optional
1015 Allowed values: CIDSS logical expressions.
1017 Session_Start
1019 Contains IDs of Source, Destination, Protocol or Pattern elements,
1020 combined using logical expressions in the format described in section
1021 2.4. The information contained in this element specifies the
1022 conditions that MUST be met by sensor data so that the packet will
1023 define the beginning of a new session. All session state MUST be
1024 reset by the IDS when a new session begins.
1026 Location: Session
1027 Presence: single, optional
1028 Allowed values: CIDSS logical expressions.
1030 Session_End
1032 Contains IDs of Source, Destination, Protocol or Pattern elements,
1033 combined using logical expressions in the format described in section
1034 2.4. The information contained in this element specifies the
1035 conditions that MUST be met by sensor data so that the packet will
1036 define the beginning of a new session.
1037 Instead of or in addition to conditions for sensor data, this element
1038 MAY include the element Session_Timeout, that specifies a timeout for
1039 Common Intrusion Detection Signatures Standard October 2005
1041 the session or MAY include Session_Pckt_Count, that defines maximum
1042 number of packets considered in current session. When both conditions
1043 are specified, then the one that is fulfilled first will terminate
1044 the session.
1046 Location: Session
1047 Presence: single, mandatory if the Session_Start attribute element is
1048 present
1049 Contained elements: Session_Timeout [single, optional],
1050 Session_Pckt_Count [single, optional]
1052 Session_Pckt_Count
1054 Defines maximum number of packets that are considered during session.
1056 Presence: single, optional
1057 Location: Session_End
1058 Type: Integer
1059 Example: 5
1061 Session_Timeout
1063 Defines a timeout for the session. The time MUST be specified in the
1064 format: an integer and a single character (the character MUST be one
1065 of: ms,s,m,h - milliseconds, seconds, minutes, hours).
1067 Presence: optional, single
1068 Type: String
1069 Location: Session_End
1070 Example: 10s
1071 Example description: The timeout for the session is 10 seconds.
1073 Session_Identification
1075 Defines additional conditions that MUST be met by sensor data so that
1076 a packet will be included in this session. These conditions apply
1077 after a session has started. For instance, a TCP session will include
1078 only the packets that have the same source and destination as the
1079 source and destination of packets that started the session. The
1080 conditions are specified by including special elements in this
1081 element.
1083 Location: Session
1084 Presence: single, mandatory if the Session_Start attribute is present
1085 Contained elements: Same_Source_IP [single, optional],
1086 Same_Source_Port [single, optional], Same_Destination_IP [single,
1087 optional], Same_Destination_Port [single, optional], Same_Protocol
1088 [single, optional], Same_Direction [single, optional]
1090 Same_Source_IP
1091 Common Intrusion Detection Signatures Standard October 2005
1093 If this element is present in Session_Identification, packets that
1094 will be included in the session MUST have the same source IP address
1095 as the starting packet.
1097 Type: boolean
1098 Presence: single, optional
1099 Location: Session_Identification
1101 Same_Source_Port
1103 If this element is present in Session_Identification, packets that
1104 will be included in the session MUST have the same source port as the
1105 starting packet.
1107 Type: boolean
1108 Presence: single, optional
1109 Location: Session_Identification
1111 Same_Destination_IP
1113 If this element is present in Session_Identification, packets that
1114 will be included in the session MUST have the same destination IP
1115 address as the starting packet.
1117 Type: boolean
1118 Presence: single, optional
1119 Location: Session_Identification
1121 Same_Destination_Port
1123 If this element is present in Session_Identification, packets that
1124 will be included in the session MUST have the same destination port
1125 as the starting packet.
1127 Type: boolean
1128 Presence: single, optional
1129 Location: Session_Identification
1131 Same_Protocol
1133 If this element is present in Session_Identification, packets that
1134 will be included in the session MUST be of the same protocol as the
1135 starting packet.
1137 Type: boolean
1138 Presence: single, optional
1139 Location: Session_Identification
1141 Same_Direction
1142 Common Intrusion Detection Signatures Standard October 2005
1144 If this element is present in Session_Identification, packets that
1145 will be included in the session MUST have been sent in the same
1146 direction as the starting packet.
1148 Type: boolean
1149 Presence: single, optional
1150 Location: Session_Identification
1152 Session_Instructions
1154 This element works like a switch statement for the state mechanism of
1155 an IDS. The information contained in this element defines the
1156 statefull behavior of an IDS for this session. The element contains
1157 several Session_Case elements that include conditions for the case to
1158 apply, as well as instructions to be carried out if the case applies.
1159 For efficiency reasons, it is assumed that all conditions for state
1160 instructions will be brought down into a conjunctive normal form (a
1161 logical expression that includes alternatives only at the highest
1162 level). That means that in every case element, all case conditions
1163 are treated as a logical conjunction (logical AND). This ought to
1164 simplify the processing of these instructions.
1166 Location: Session
1167 Presence: single, optional
1168 Contained elements: Session_Case [multiple]
1170 Session_Case
1172 This element contains the conditions and instructions of a case in
1173 the switch statement that is defined by the containing
1174 Session_Instructions element. For readability, the conditions are
1175 split up into three groups: additional conditions for sensor data
1176 that MUST be satisfied so that the packet will apply to this case,
1177 the direction of the packet, and the conditions that MUST be
1178 satisfied by the state variables of a session in order for the case
1179 to apply. The instructions of a case are contained in the mandatory
1180 Case_State_Instructions element.
1182 Location: Session_Instructions
1183 Presence: multiple
1184 Contained elements: Case_Filter [single, optional], Direction
1185 [single, optional], Case_State_Condition [single, optional],
1186 Case_State_Instructions [single, mandatory]
1188 Case_Filter
1190 Contains IDs of Source, Destination, Protocol or Pattern elements,
1191 combined using logical expressions in the format described in section
1192 2.4. The information contained in this element specifies the
1193 conditions that MUST be met by sensor data so that the packet will
1194 apply to this case.
1196 Common Intrusion Detection Signatures Standard October 2005
1198 Location: Session_Case
1199 Presence: single, optional
1200 Allowed values: CIDSS logical expressions.
1202 Direction
1204 Defines a direction of network traffic, once a source and destination
1205 of traffic are specified (e.g. after the start of a session). Allowed
1206 values are: "sd" and "ds". If direction value is "sd" it means that
1207 the packet has been sent from source to destination. If the value of
1208 this element is "ds" it means that traffic goes from destination to
1209 source.
1211 Allowed values: sd|ds
1212 Default value: sd
1213 Location: Session_Case
1214 Presence: single, optional
1216 Case_State_Condition
1218 This element contains conditional state expressions that MUST all be
1219 satisfied (evaluate to a boolean value of "true") in order for the
1220 case to apply. These instructions MAY check the values of state
1221 variables stored by the IDS for this session.
1223 Location: Session_Case
1224 Presence: single, optional
1225 Contained elements: Isset_Var, Compare_Var
1227 Case_State_Instructions
1229 This element contains state instructions that MUST all be
1230 sequentially carried out by the IDS if the case applies. These
1231 instructions MAY set, unset or modify the values of state variables
1232 stored by the IDS for this session.
1234 Location: Session_Case
1235 Presence: single, optional
1236 Contained elements: Set_Var, Unset_Var, Isset_Var, Isnotset_Var,
1237 Compare_Var, Toggle_Var
1239 Isset_Var
1241 A conditional state expression that evaluates to a boolean value of
1242 "true" if the variable of a name that is specified in the "var"
1243 attribute is set in the state of this session.
1245 Location: Case_State_Condition
1246 Presence: multiple, optional
1247 Attributes: var [type: string; single, mandatory]
1249 Isnotset_Var
1250 Common Intrusion Detection Signatures Standard October 2005
1252 A conditional state expression that evaluates to a boolean value of
1253 "true" if the variable of a name that is specified in the "var"
1254 attribute is not set in the state of this session.
1256 Location: Case_State_Condition
1257 Presence: multiple, optional
1258 Attributes: var [type: string; single, mandatory]
1260 Compare_Var
1262 Location: Case_State_Condition
1263 Presence: multiple, optional
1264 Attributes: var [type: string; single, mandatory], value [type:
1265 string; single, mandatory]
1267 Set_Var
1269 Sets value of "var" attribute in state of particular session.
1271 Location: Case_State_Instructions
1272 Presence: multiple, optional
1273 Attributes: var [type: string; single, mandatory], value [type:
1274 string; single, mandatory]
1276 Unset_Var
1278 Nullifies value of "var" used in this session.
1280 Location: Case_State_Instructions
1281 Presence: multiple, optional
1282 Attributes: var [type: string; single, mandatory]
1284 Toggle_Var
1286 Toggle value of "var" attribute in state of particular session. Set
1287 the specified state if the state is unset, otherwise unsets the state
1288 if the state is set.
1290 Location: Case_State_Instructions
1291 Presence: multiple, optional
1292 Attributes: var [type: string; single, mandatory], value [type:
1293 string; single, mandatory]
1295 3. Security Considerations
1297 This Internet Draft describes the CIDSS format for storing
1298 information about IDS signatures. The applications of this standard
1299 can raise security concerns, but there areis no security concerns
1300 related strictly to the document format.
1302 Common Intrusion Detection Signatures Standard October 2005
1304 It is RECOMMENDED that a system for storing CIDSS data SHOULD be
1305 protected against unauthorized access and unauthorized use. The means
1306 for achieving this protection are outside the scope of this document.
1308 Common Intrusion Detection Signatures Standard October 2005
1310 Appendix A
1311 XML CIDSS Document Example
1313 Here we present a sample signature in CIDSS format. Elements of this
1314 signature have been used as examples in the previous sections. (This
1315 appendix MAY NOT be compatible with Internet Draft formatting).
1317
1318
1320
1321 true
1322 snort
1323 alert
1324 NETBIOS SMB-DS DCERPC Remote Activation bind attempt;
1325 sid=2252
1326 NETBIOS SMB-DS DCERPC Remote Activation bind
1327 attempt
1328 reference: cve,CAN-2003-0528
1329 reference: cve,CAN-2003-0605
1330 reference: cve,CAN-2003-0715
1331 reference:
1332 url,www.microsoft.com/technet/security/bulletin/MS03-
1333 039.mspx
1334 reference:cve,CAN-2003-0528; reference:cve,CAN-2003-0605;
1335 reference:cve,CAN-2003-0715;
1336 reference:url,www.microsoft.com/technet/security/bulletin/MS03-
1337 039.mspx;
1338
1339
1340 any
1341 any
1342
1343
1344 10.0.0.0
1345 any
1346
1347
1348 192.168.1.0
1349 any
1350
1351 SRC_1 AND SRC_2 AND SRC_3
1352
1353
1354
1355 any
1356 445
1357
1358
1359 192.168.1.0
1361 Common Intrusion Detection Signatures Standard October 2005
1363 445
1364
1365
1366 10.0.0.0
1368 445
1369
1370 DST_1 AND DST_2 AND DST_3
1371
1372
1373
1374 established
1375
1376 PROTO_1
1377
1378
1379
1380 string
1381 |FF|SMB%
1383 5
1384 4
1385
1386
1387 string
1388
1390 2
1391 56
1392
1393
1394 string
1395 |5C
1396 00|P|00|I|00|P|00|E|00 5C 00|
1397 12
1398 5
1399
1400
1401 hex
1402 05
1403 1
1404
1405
1406 hex
1407 0B
1408 1
1409 1
1410
1411
1412 string
1413 |B8|J|9F|M|1C|}|CF 11
1414 86 1E 00| |AF|n|7C|W
1415 Common Intrusion Detection Signatures Standard October 2005
1417 16
1418 29
1419
1420 PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 AND PAT_5 AND
1421 PAT_6
1422
1423
1424 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND
1425 DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4
1426 AND PAT_5 AND PAT_6)
1427
1428 5
1429
1430
1431
1432
1434 Appendix B
1435 The schema of CIDSS - cidss.xsd
1437 Available at http://translator.b59.net/docs/cidss.xsd
1439 References
1441 Normative references
1443 [SNORTman] Roesch Martin, Green Chris, "Snort Users Manual", 2.3.0
1444 January 2005, http://www.snort.org
1446 [DRAGON] "Dragon. Intrusion Detection System. Topics on Writing
1447 Signatures" Enterasys Networks, 2002,
1448 http://dragon.enterasys.com
1450 [SHOKIug] Shoki, "Shoki User's Guide", Release 0.3.0,
1451 http://shoki.sourceforge.net/
1453 [XML10] Extensible Markup Language (XML) 1.0, Third Edition,
1454 http://www.w3.org/TR/2004/REC-xml-20040204/
1456 [XSD] XML Schema - Specifications and Development,
1457 http://www.w3.org/XML/Schema#dev
1459 [ISSdoc] ISS - Internet Security Systems, Documentation,
1460 http://www.iss.net/support/documentation/
1462 [CISCOdoc] Cisco - NetRanger, Documentation,
1463 http://www.cisco.com/univercd/cc/td/doc/product/iaabu/\
1464 netrangr/
1466 Common Intrusion Detection Signatures Standard October 2005
1468 [PCRE] PCRE - Perl Compatible Regular Expressions,
1469 http://www.pcre.org/
1471 Informative references
1473 [RFC2119] Bradner S., "Key words for use in RFCs to Indicate
1474 Requirement Levels", BCP 14, RFC 2119, March 1997.
1476 [IDWG11] Curry D., Lynch Merrill, Debar H., "The Intrusion
1477 Detection Message Exchange Format", Internet Draft
1478 draft-ietf-idwg-idmef-xml-11, January 2004,
1479 expires July 2004.
1481 [JAVAXML] McLaughlin Brett, Java & XML, 2nd Edition,
1482 ISBN: 0-596-00197-5
1484 [CIDSL] K. Miakisz, Translator i wspolny jezyk sygnatur
1485 systemow wykrywania wlaman (Translator and Common
1486 Intrusion Detection Systems Language), Bachelor thesis,
1487 Polish-Japanese Institute of Information Technology,
1488 2003
1490 [ARACH] arachNIDS - Whitehats Network Security Resource,
1491 http://whitehats.com/ids/
1493 Author's Addresses
1495 dr Adam Wierzbicki
1496 Polish-Japanese Institute of Information Technology
1497 Koszykowa 86
1498 02-008 Warsaw, Poland
1499 Email: adamw@pjwstk.edu.pl
1501 Jacek Kalinski
1502 Rechniewskiego 6/24
1503 03-980 Warsaw, Poland
1504 Email: jacek@dyski.one.pl
1506 Tomasz Kruszona
1507 Garwolinska 9/83
1508 04-348 Warsaw, Poland
1509 Email: t.kruszona@b59.net
1511 Comments to:
1512 dr Adam Wierzbicki
1513 Polish-Japanese Institute of Information Technology
1514 Koszykowa 86
1515 02-008 Warsaw, Poland
1516 Common Intrusion Detection Signatures Standard October 2005
1518 Email: adamw@pjwstk.edu.pl
1520 Copyright Notice
1522 Copyright (C) The Internet Society (2005).
1524 This document is subject to the rights, licenses and restrictions
1525 contained in BCP 78, and except as set forth therein, the authors
1526 retain all their rights.
1528 Disclaimer of Validity
1530 This document and the information contained herein are provided on an
1531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1533 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1534 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1535 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1538 Intellectual Property Statement
1540 The IETF takes no position regarding the validity or scope of any
1541 Intellectual Property Rights or other rights that might be claimed to
1542 pertain to the implementation or use of the technology described in
1543 this document or the extent to which any license under such rights
1544 might or might not be available; nor does it represent that it has
1545 made any independent effort to identify any such rights. Information
1546 on the procedures with respect to rights in RFC documents can be
1547 found in BCP 78 and BCP 79.
1549 Copies of IPR disclosures made to the IETF Secretariat and any
1550 assurances of licenses to be made available, or the result of an
1551 attempt made to obtain a general license or permission for the use of
1552 such proprietary rights by implementers or users of this
1553 specification can be obtained from the IETF on-line IPR repository at
1554 http://www.ietf.org/ipr.
1556 The IETF invites any interested party to bring to its attention any
1557 copyrights, patents or patent applications, or other proprietary
1558 rights that may cover technology that may be required to implement
1559 this standard. Please address the information to the IETF at
1560 ietf-ipr@ietf.org.
1562 IANA Considerations
1564 This document does not introduce any IANA considerations.