forked from Moutix/idmef_parser
-
Notifications
You must be signed in to change notification settings - Fork 0
/
rfc4765.txt
8795 lines (6019 loc) · 301 KB
/
rfc4765.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group H. Debar
Request for Comments: 4765 France Telecom
Category: Experimental D. Curry
Guardian
B. Feinstein
SecureWorks, Inc.
March 2007
The Intrusion Detection Message Exchange Format (IDMEF)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
IESG Note
The content of this RFC was at one time considered by the IETF, but
the working group concluded before this work was approved as a
standards-track protocol. This RFC is not a candidate for any level
of Internet Standard. The IETF disclaims any knowledge of the
fitness of this RFC for any purpose and in particular notes that the
decision to publish is not based on complete IETF review for such
things as security, congestion control, or inappropriate interaction
with deployed protocols. The IESG has chosen to publish this
document in order to document the work as it was when the working
group concluded and to encourage experimentation and development of
the technology. Readers of this RFC should exercise caution in
evaluating its value for implementation and deployment.
Abstract
The purpose of the Intrusion Detection Message Exchange Format
(IDMEF) is to define data formats and exchange procedures for sharing
information of interest to intrusion detection and response systems
and to the management systems that may need to interact with them.
This document describes a data model to represent information
exported by intrusion detection systems and explains the rationale
for using this model. An implementation of the data model in the
Extensible Markup Language (XML) is presented, an XML Document Type
Definition is developed, and examples are provided.
Debar, et al. Experimental [Page 1]
RFC 4765 The IDMEF March 2007
Table of Contents
1. Introduction ....................................................4
1.1. About the IDMEF Data Model .................................4
1.1.1. Problems Addressed by the Data Model ................5
1.1.2. Data Model Design Goals .............................6
1.2. About the IDMEF XML Implementation .........................7
1.2.1. The Extensible Markup Language ......................7
1.2.2. Rationale for Implementing IDMEF in XML .............8
2. Notices and Conventions Used in This Document ..................10
3. Notational Conventions and Formatting Issues ...................10
3.1. IDMEF XML Documents .......................................10
3.1.1. The Document Prolog ................................10
3.1.2. Character Data Processing in IDMEF .................11
3.1.3. Languages in IDMEF .................................12
3.2. IDMEF Data Types ..........................................12
3.2.1. Integers ...........................................12
3.2.2. Real Numbers .......................................12
3.2.3. Characters and Strings .............................13
3.2.4. Bytes ..............................................14
3.2.5. Enumerated Types ...................................14
3.2.6. Date-Time Strings ..................................14
3.2.7. NTP Timestamps .....................................16
3.2.8. Port Lists .........................................16
3.2.9. Unique Identifiers .................................17
4. The IDMEF Data Model and DTD ...................................18
4.1. Data Model Overview .......................................18
4.2. The Message Classes .......................................20
4.2.1. The IDMEF-Message Class ............................20
4.2.2. The Alert Class ....................................20
4.2.3. The Heartbeat Class ................................27
4.2.4. The Core Classes ...................................29
4.2.5. The Time Classes ...................................41
4.2.6. The Assessment Classes .............................42
4.2.7. The Support Classes ................................47
5. Extending the IDMEF ............................................79
5.1. Extending the Data Model ..................................79
5.2. Extending the IDMEF DTD ...................................80
6. Special Considerations .........................................81
6.1. XML Validity and Well-Formedness ..........................81
6.2. Unrecognized XML Tags .....................................82
6.3. Analyzer-Manager Time Synchronization .....................82
6.4. NTP Timestamp Wrap-Around .................................84
6.5. Digital Signatures ........................................85
7. Examples .......................................................85
7.1. Denial-of-Service Attacks .................................86
7.1.1. The "teardrop" Attack ..............................86
7.1.2. The "ping of death" Attack .........................87
Debar, et al. Experimental [Page 2]
RFC 4765 The IDMEF March 2007
7.2. Port Scanning Attacks .....................................88
7.2.1. Connection to a Disallowed Service .................88
7.2.2. Simple Port Scanning ...............................89
7.3. Local Attacks .............................................90
7.3.1. The "loadmodule" Attack ............................90
7.3.2. The "phf" Attack ...................................93
7.3.3. File Modification ..................................94
7.4. System Policy Violation ...................................96
7.5. Correlated Alerts .........................................98
7.6. Analyzer Assessments ......................................99
7.7. Heartbeat ................................................100
7.8. XML Extension ............................................101
8. The IDMEF Document Type Definition (Normative) ................104
9. Security Considerations .......................................117
10. IANA Considerations ..........................................118
10.1. Adding Values to Existing Attributes ....................118
10.1.1. Attribute Registrations ..........................119
10.1.2. Registration Template ............................130
10.2. Adding New Attributes and Classes .......................131
11. References ...................................................131
11.1. Normative References ....................................131
11.2. Informative References ..................................132
Appendix A. Acknowledgements ....................................134
Appendix B. The IDMEF Schema Definition (Non-normative) .........135
Debar, et al. Experimental [Page 3]
RFC 4765 The IDMEF March 2007
1. Introduction
The Intrusion Detection Message Exchange Format (IDMEF) [2] is
intended to be a standard data format that automated intrusion
detection systems can use to report alerts about events that they
deem suspicious. The development of this standard format will enable
interoperability among commercial, open source, and research systems,
allowing users to mix-and-match the deployment of these systems
according to their strong and weak points to obtain an optimal
implementation.
The most obvious place to implement the IDMEF is in the data channel
between an intrusion detection analyzer (or "sensor") and the manager
(or "console") to which it sends alarms. But there are other places
where the IDMEF can be useful:
o a single database system that could store the results from a
variety of intrusion detection products would make it possible for
data analysis and reporting activities to be performed on "the
whole picture" instead of just a part of it;
o an event correlation system that could accept alerts from a
variety of intrusion detection products would be capable of
performing more sophisticated cross-correlation and cross-
confirmation calculations than one that is limited to a single
product;
o a graphical user interface that could display alerts from a
variety of intrusion detection products would enable the user to
monitor all of the products from a single screen, and require him
or her to learn only one interface, instead of several; and
o a common data exchange format would make it easier for different
organizations (users, vendors, response teams, law enforcement) to
not only exchange data, but also communicate about it.
The diversity of uses for the IDMEF needs to be considered when
selecting its method of implementation.
1.1. About the IDMEF Data Model
The IDMEF data model is an object-oriented representation of the
alert data sent to intrusion detection managers by intrusion
detection analyzers.
Debar, et al. Experimental [Page 4]
RFC 4765 The IDMEF March 2007
1.1.1. Problems Addressed by the Data Model
The data model addresses several problems associated with
representing intrusion detection alert data:
o Alert information is inherently heterogeneous. Some alerts are
defined with very little information, such as origin, destination,
name, and time of the event. Other alerts provide much more
information, such as ports or services, processes, user
information, and so on. The data model that represents this
information must be flexible to accommodate different needs.
An object-oriented model is naturally extensible via aggregation
and subclassing. If an implementation of the data model extends
it with new classes, either by aggregation or subclassing, an
implementation that does not understand these extensions will
still be able to understand the subset of information that is
defined by the data model. Subclassing and aggregation provide
extensibility while preserving the consistency of the model.
o Intrusion detection environments are different. Some analyzers
detect attacks by analyzing network traffic; others use operating
system logs or application audit trail information. Alerts for
the same attack, sent by analyzers with different information
sources, will not contain the same information.
The data model defines support classes that accommodate the
differences in data sources among analyzers. In particular, the
notions of source and target for the alert are represented by the
combination of Node, Process, Service, and User classes.
o Analyzer capabilities are different. Depending on the
environment, one may install a lightweight analyzer that provides
little information in its alerts, or a more complex analyzer that
will have a greater impact on the running system but provide more
detailed alert information. The data model must allow for
conversion to formats used by tools other than intrusion detection
analyzers, for the purpose of further processing the alert
information.
The data model defines extensions to the basic Document Type
Definition (DTD) that allow carrying both simple and complex
alerts. Extensions are accomplished through subclassing or
association of new classes.
Debar, et al. Experimental [Page 5]
RFC 4765 The IDMEF March 2007
o Operating environments are different. Depending on the kind of
network or operating system used, attacks will be observed and
reported with different characteristics. The data model should
accommodate these differences.
Significant flexibility in reporting is provided by the Node and
Service support classes. If additional information must be
reported, subclasses may be defined that extend the data model
with additional attributes.
o Commercial vendor objectives are different. For various reasons,
vendors may wish to deliver more or less information about certain
types of attacks.
The object-oriented approach allows this flexibility while the
subclassing rules preserve the integrity of the model.
1.1.2. Data Model Design Goals
The data model was designed to provide a standard representation of
alerts in an unambiguous fashion, and to permit the relationship
between simple and complex alerts to be described.
1.1.2.1. Representing Events
The goal of the data model is to provide a standard representation of
the information that an intrusion detection analyzer reports when it
detects an occurrence of some unusual event(s). These alerts may be
simple or complex, depending on the capabilities of the analyzer that
creates them.
1.1.2.2. Content-Driven
The design of the data model is content-driven. This means that new
objects are introduced to accommodate additional content, not
semantic differences between alerts. This is an important goal, as
the task of classifying and naming computer vulnerabilities is both
extremely difficult and very subjective.
The data model must be unambiguous. This means that while we allow
analyzers to be more or less precise than one another (i.e., one
analyzer may report more information about an event than another), we
do not allow them to produce contradictory information in two alerts
describing the same event (i.e., the common subset of information
reported by both analyzers must be identical and inserted in the same
placeholders within the alert data structure). Of course, it is
always possible to insert all "interesting" information about an
Debar, et al. Experimental [Page 6]
RFC 4765 The IDMEF March 2007
event in extension fields of the alert instead of in the fields where
it belongs; however, such practice reduces interoperability and
should be avoided whenever possible.
1.1.2.3. Relationship between Alerts
Intrusion detection alerts can be transmitted at several levels.
This document applies to the entire range, from very simple alerts
(e.g., those alerts that are the result of a single action or
operation in the system, such as a failed login report) to very
complex ones (e.g., the aggregation of several events causing an
alert to be generated).
As such, the data model must provide a way for complex alerts that
aggregate several simple alerts to identify those simple alerts in
the complex alert's content.
1.2. About the IDMEF XML Implementation
Two implementations of the IDMEF were originally proposed to the
Intrusion Detection Working Group (IDWG): one using the Structure of
Management Information (SMI) to describe a Simple Network Management
Protocol (SNMP) MIB, and the other using a DTD to describe XML
documents.
These proposed implementations were reviewed by the IDWG at its
September 1999 and February 2000 meetings; it was decided at the
February meeting that the XML solution was best at fulfilling the
IDWG requirements.
1.2.1. The Extensible Markup Language
The Extensible Markup Language (XML) [3] is a simplified version of
the Standard Generalized Markup Language (SGML), a syntax for
specifying text markup defined by the ISO 8879 standard. XML is
gaining widespread attention as a language for representing and
exchanging documents and data on the Internet, and as the solution to
most of the problems inherent in HyperText Markup Language (HTML).
XML was published as a recommendation by the World Wide Web
Consortium (W3C) on February 10, 1998.
XML is a metalanguage -- a language for describing other languages --
that enables an application to define its own markup. XML allows the
definition of customized markup languages for different types of
documents and different applications. This differs from HTML, in
which there is a fixed set of identifiers with preset meanings that
must be "adapted" for specialized uses. Both XML and HTML use
elements (tags) (identifiers delimited by '<' and '>') and attributes
Debar, et al. Experimental [Page 7]
RFC 4765 The IDMEF March 2007
(of the form "name='value'"). But where "<p>" always means
"paragraph" in HTML, it may mean "paragraph", "person", "price", or
"platypus" in XML, or it might have no meaning at all, depending on
the particular application.
NOTE: XML provides both a syntax for declaring document markup and
structure (i.e., defining elements and attributes, specifying the
order in which they appear, and so on) and a syntax for using that
markup in documents. Because markup declarations look radically
different from markup, many people are confused as to which syntax
is called XML. The answer is that they both are, because they are
actually both part of the same language.
For clarity in this document, we will use the terms "XML" and "XML
documents" when speaking in the general case, and the term "IDMEF
markup" when speaking specifically of the elements (tags) and
attributes that describe IDMEF messages.
The publication of XML was followed by the publication of a second
recommendation [4] by the World Wide Web Consortium, defining the use
of namespaces in XML documents. An XML namespace is a collection of
names, identified by a Uniform Resource Identifier (URI) [5]. When
using namespaces, each tag is identified with the namespace it comes
from, allowing tags from different namespaces with the same names to
occur in the same document. For example, a single document could
contain both "usa:football" and "europe:football" tags, each with
different meanings.
In anticipation of the widespread use of XML namespaces, this memo
includes the definition of the URI to be used to identify the IDMEF
namespace.
1.2.2. Rationale for Implementing IDMEF in XML
XML-based applications are being used or developed for a wide variety
of purposes, including electronic data interchange in a variety of
fields, financial data interchange, electronic business cards,
calendar and scheduling, enterprise software distribution, web "push"
technology, and markup languages for chemistry, mathematics, music,
molecular dynamics, astronomy, book and periodical publishing, web
publishing, weather observations, real estate transactions, and many
others.
XML's flexibility makes it a good choice for these applications; that
same flexibility makes it a good choice for implementing the IDMEF as
well. Other, more specific reasons for choosing XML to implement the
IDMEF are:
Debar, et al. Experimental [Page 8]
RFC 4765 The IDMEF March 2007
o XML allows a custom language to be developed specifically for the
purpose of describing intrusion detection alerts. It also defines
a standard way to extend this language, either for later revisions
of this document ("standard" extensions) or for vendor-specific
use ("non-standard" extensions).
o Software tools for processing XML documents are widely available,
in both commercial and open source forms. Numerous tools and APIs
for parsing and/or validating XML are available in a variety of
languages, including Java, C, C++, Tcl, Perl, Python, and GNU
Emacs Lisp. Widespread access to tools will make adoption of the
IDMEF by product developers easier, and hopefully, faster.
o XML meets IDMEF Requirement 5.1 [2], that message formats support
full internationalization and localization. The XML standard
requires support for both the UTF-8 and UTF-16 encodings of ISO/
IEC 10646 (Universal Multiple-Octet Coded Character Set, "UCS")
and Unicode, making all XML applications (and therefore all IDMEF-
compliant applications) compatible with these common character
encodings.
XML also provides support for specifying, on a per-element basis,
the language in which the element's content is written, making
IDMEF easy to adapt to "Natural Language Support" versions of a
product.
o XML meets IDMEF Requirement 5.2 [2], that message formats must
support filtering and aggregation. XML's integration with XSL, a
style language, allows messages to be combined, discarded, and
rearranged.
o Ongoing XML development projects, in the W3C and elsewhere, will
provide object-oriented extensions, database support, and other
useful features. If implemented in XML, the IDMEF immediately
gains these features as well.
o XML is free, with no license, no license fees, and no royalties.
Debar, et al. Experimental [Page 9]
RFC 4765 The IDMEF March 2007
2. Notices and Conventions Used in This Document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
An "IDMEF-compliant application" is a program or program component,
such as an analyzer or manager, that reads and/or writes messages in
the format specified by this memo.
An "IDMEF document" is a message that adheres to the requirements
specified by this memo and that is exchanged by two or more IDMEF
applications. "IDMEF message" is another term for an "IDMEF
document".
3. Notational Conventions and Formatting Issues
This document uses three notations: Unified Modeling Language to
describe the data model [14], XML to describe the markup used in
IDMEF documents, and IDMEF markup to represent the documents
themselves.
3.1. IDMEF XML Documents
This section describes IDMEF XML document formatting rules. Most of
these rules are "inherited" from the rules for formatting XML
documents.
3.1.1. The Document Prolog
The format of an IDMEF XML document prolog is described in the
following sections.
3.1.1.1. XML Declaration
IDMEF documents being exchanged between IDMEF-compliant applications
MUST begin with an XML declaration, and MUST specify the XML version
in use. Specification of the encoding in use is RECOMMENDED.
An IDMEF message SHOULD therefore start with:
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef"/>
Debar, et al. Experimental [Page 10]
RFC 4765 The IDMEF March 2007
IDMEF-compliant applications MAY choose to omit the XML declaration
internally to conserve space, adding it only when the message is sent
to another destination (e.g., a web browser). This practice is NOT
RECOMMENDED unless it can be accomplished without loss of each
message's version and encoding information.
In order to be valid (see Section 6.1), an XML document must contain
a document type definition. However, this represents significant
overhead to an IDMEF-compliant application, both in the bandwidth it
consumes as well as the requirements it places on the XML processor
(not only to parse the declaration itself, but also to parse the DTD
it references).
Implementors MAY decide, therefore, to have analyzers and managers
agree out-of-band on the particular document type definition they
will be using to exchange messages (the standard one as defined here,
or one with extensions), and then omit the document type definition
from IDMEF messages. The method for negotiating this agreement is
outside the scope of this document. Note that great care must be
taken in negotiating any such agreements, as the manager may have to
accept messages from many different analyzers, each using a DTD with
a different set of extensions.
3.1.2. Character Data Processing in IDMEF
For portability reasons, IDMEF-compliant applications SHOULD NOT use,
and IDMEF messages SHOULD NOT be encoded in, character encodings
other than UTF-8 and UTF-16. Consistent with the XML standard, if no
encoding is specified for an IDMEF message, UTF-8 is assumed.
NOTE: The ASCII character set is a subset of the UTF-8 encoding, and
therefore may be used to encode IDMEF messages.
Per the XML standard, IDMEF documents encoded in UTF-16 MUST begin
with the Byte Order Mark described by ISO/IEC 10646 Annex E and
Unicode Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character,
#xFEFF).
3.1.2.1. Character Entity References
It is RECOMMENDED that IDMEF-compliant applications use the entity
reference form (see Section 3.2.3.1) of the characters '&', ,'<',
'>', '"', and ''' (single-quote) whenever writing these characters in
data, to avoid any possibility of misinterpretation.
3.1.2.2. White Space Processing
All IDMEF elements MUST support the "xml:space" attribute.
Debar, et al. Experimental [Page 11]
RFC 4765 The IDMEF March 2007
3.1.3. Languages in IDMEF
IDMEF-compliant applications MUST specify the language in which their
contents are encoded; in general this can be done by specifying the
"xml:lang" attribute for the top-level element and letting all other
elements "inherit" that definition [10].
3.2. IDMEF Data Types
Within an XML IDMEF message, all data will be expressed as "text" (as
opposed to "binary"), since XML is a text formatting language. We
provide typing information for the attributes of the classes in the
data model, however, to convey to the reader the type of data that
the model expects for each attribute.
Each data type in the model has specific formatting requirements in
an XML IDMEF message; these requirements are set forth in this
section.
3.2.1. Integers
Integer attributes are represented by the INTEGER data type. Integer
data MUST be encoded in Base 10 or Base 16.
Base 10 integer encoding uses the digits '0' through '9' and an
optional sign ('+' or '-'). For example, "123", "-456".
Base 16 integer encoding uses the digits '0' through '9' and 'a'
through 'f' (or their uppercase equivalents), and is preceded by the
characters "0x". For example, "0x1a2b".
3.2.2. Real Numbers
Real (floating-point) attributes are represented by the REAL data
type. Real data MUST be encoded in Base 10.
Real encoding is that of the POSIX 1003.1 "strtod" library function:
an optional sign ('+' or '-') followed by a non-empty string of
decimal digits, optionally containing a radix character, then an
optional exponent part. An exponent part consists of an 'e' or 'E',
followed by an optional sign, followed by one or more decimal digits.
For example, "123.45e02", "-567,89e-03".
IDMEF-compliant applications MUST support both the '.' and ',' radix
characters.
Debar, et al. Experimental [Page 12]
RFC 4765 The IDMEF March 2007
3.2.3. Characters and Strings
Single-character attributes are represented by the CHARACTER data
type. Multi-character attributes of known length are represented by
the STRING data type.
Character and string data have no special formatting requirements,
other than the need to occasionally use character references (see
Section 3.2.3.1 and Section 3.2.3.2) to represent special characters.
3.2.3.1. Character Entity References
Within XML documents, certain characters have special meanings in
some contexts. To include the actual character itself in one of
these contexts, a special escape sequence, called an entity
reference, must be used.
The characters that sometimes need to be escaped, and their entity
references, are:
+-----------+------------------+
| Character | Entity Reference |
+-----------+------------------+
| & | & |
| | |
| < | < |
| | |
| > | > |
| | |
| " | " |
| | |
| ' | ' |
+-----------+------------------+
3.2.3.2. Character Code References
Any character defined by the ISO/IEC 10646 and Unicode standards may
be included in an XML document by the use of a character reference.
A character reference is started with the characters '&' and '#', and
ended with the character ';'. Between these characters, the
character code for the character is inserted.
If the character code is preceded by an 'x' it is interpreted in
hexadecimal (base 16); otherwise, it is interpreted in decimal (base
10). For instance, the ampersand (&) is encoded as & or &
and the less-than sign (<) is encoded as < or <.
Debar, et al. Experimental [Page 13]
RFC 4765 The IDMEF March 2007
Any one-, two-, or four-byte character specified in the ISO/IEC 10646
and Unicode standards can be included in a document using this
technique.
3.2.4. Bytes
Binary data is represented by the BYTE (and BYTE[]) data type.
Binary data MUST be encoded in its entirety using base64.
3.2.5. Enumerated Types
Enumerated types are represented by the ENUM data type, and consist
of an ordered list of acceptable values.
3.2.6. Date-Time Strings
Date-time strings are represented by the DATETIME data type. Each
date-time string identifies a particular instant in time; ranges are
not supported.
Date-time strings are formatted according to a subset of ISO 8601:
2000 [6], as show below. Section references in parentheses refer to
sections of the ISO 8601:2000 standard [6].
1. Dates MUST be formatted as follows:
YYYY-MM-DD
where YYYY is the four-digit year, MM is the two-digit month
(01-12), and DD is the two-digit day (01-31). (Section 5.2.1.1,
"Complete representation -- Extended format".)
2. Times MUST be formatted as follows:
hh:mm:ss
where hh is the two-digit hour (00-24), mm is the two-digit
minute (00-59), and ss is the two-digit second (00-60). (Section
5.3.1.1, "Complete representation -- Extended format".)
Note that midnight has two representations, 00:00:00 and
24:00:00. Both representations MUST be supported by IDMEF-
compliant applications; however, the 00:00:00 representation
SHOULD be used whenever possible.
Debar, et al. Experimental [Page 14]
RFC 4765 The IDMEF March 2007
Note also that this format accounts for leap seconds. Positive
leap seconds are inserted between 23:59:59Z and 24:00:00Z and are
represented as 23:59:60Z. Negative leap seconds are achieved by
the omission of 23:59:59Z. IDMEF-compliant applications MUST
support leap seconds.
3. Times MAY be formatted to include a decimal fraction of seconds,
as follows:
hh:mm:ss.ss or
hh:mm:ss,ss
As many digits as necessary may follow the decimal sign (at least
one digit must follow the decimal sign). Decimal fractions of
hours and minutes are not supported. (Section 5.3.1.3,
"Representation of decimal fractions".)
IDMEF-compliant applications MUST support the use of both decimal
signs ('.' and ',').
Note that the number of digits in the fraction part does not
imply anything about accuracy -- i.e., "00.100000", "00,1000",
and "00.1" are all equivalent.
4. Times MUST be formatted to include (a) an indication that the
time is in Coordinated Universal Time (UTC) or (b) an indication
of the difference between the specified time and Coordinated
Universal Time.
* Times in UTC MUST be formatted by appending the letter 'Z' to
the time string as follows:
hh:mm:ssZ
hh:mm:ss.ssZ
hh:mm:ss,ssZ
(Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended
format".)
* If the time is ahead of or equal to UTC, a '+' sign is
appended to the time string; if the time is behind UTC, a '-'
sign is appended. Following the sign, the number of hours and
minutes representing the different from UTC is appended, as
follows:
hh:mm:ss+hh:mm
hh:mm:ss-hh:mm
hh:mm:ss.ss+hh:mm
Debar, et al. Experimental [Page 15]
RFC 4765 The IDMEF March 2007
hh:mm:ss.ss-hh:mm
hh:mm:ss,ss+hh:mm
hh:mm:ss,ss-hh:mm
The difference from UTC MUST be specified in both hours and
minutes, even if the minutes component is 0. A "difference"
of "+00:00" is equivalent to UTC. (Section 5.3.4.2, "Local
time and the difference with Coordinated Universal Time --
Extended Format".)
5. Date-time strings are created by joining the date and time
strings with the letter 'T', as shown below:
YYYY-MM-DDThh:mm:ssZ
YYYY-MM-DDThh:mm:ss.ssZ
YYYY-MM-DDThh:mm:ss,ssZ
YYYY-MM-DDThh:mm:ss+hh:mm
YYYY-MM-DDThh:mm:ss-hh:mm
YYYY-MM-DDThh:mm:ss.ss+hh:mm
YYYY-MM-DDThh:mm:ss.ss-hh:mm
YYYY-MM-DDThh:mm:ss,ss+hh:mm
YYYY-MM-DDThh:mm:ss,ss-hh:mm
(Section 5.4.1, "Complete representation -- Extended format".)
In summary, IDMEF date-time strings MUST adhere to one of the nine
templates identified in Paragraph 5, above.
3.2.7. NTP Timestamps
NTP timestamps are represented by the NTPSTAMP data type and are
described in detail in [7] and [8]. An NTP timestamp is a 64-bit
unsigned fixed-point number. The integer part is in the first 32
bits, and the fraction part is in the last 32 bits.
Within IDMEF messages, NTP timestamps MUST be encoded as two 32-bit
hexadecimal values, separated by a period ('.'). For example,
"0x12345678.0x87654321".
See also Section 6.4 for more information on NTP timestamps.
3.2.8. Port Lists
Port lists are represented by the PORTLIST data type and consist of a
comma-separated list of numbers (individual integers) and ranges (N-M
means ports N through M, inclusive). Any combination of numbers and
ranges may be used in a single list. For example,
"5-25,37,42,43,53,69-119,123-514".
Debar, et al. Experimental [Page 16]
RFC 4765 The IDMEF March 2007
3.2.9. Unique Identifiers
There are two types of unique identifiers used in this specification.
Both types are represented by STRING data types.
These identifiers are implemented as attributes on the relevant XML
elements, and they must have unique values as follows:
1. The Analyzer class' (Section 4.2.4.1) "analyzerid" attribute, if
specified, MUST have a value that is unique across all analyzers
in the intrusion detection environment.
The "analyzerid" attribute is not required to be globally unique,
only unique within the intrusion detection environment of which
the analyzer is a member. It is permissible for two analyzers,
in different intrusion detection environments, to have the same
value for "analyzerid".
The default value is "0", which indicates that the analyzer
cannot generate unique identifiers.
2. The Alert and Heartbeat messages (Sections 4.2.2, 4.2.3) must be
uniquely identified by the couple (analyzerid,messageid), if the
analyzer supports the generation of message identifiers.
3. The Classification, Source, Target, Node, User, Process, Service,
File, Address, and UserId classes' (Sections 4.2.4.2, 4.2.4.3,
4.2.4.4, 4.2.7.2, 4.2.7.3, 4.2.7.4, 4.2.7.5, 4.2.7.6, 4.2.7.2.1,
and 4.2.7.3.1) "ident" attribute, if specified, MUST have a value
that is unique across all messages sent by the individual
analyzer.
The "ident" attribute value MUST be unique for each particular
combination of data identifying an object, not for each object.
Objects may have more than one "ident" value associated with
them. For example, an identification of a host by name would
have one value, while an identification of that host by address
would have another value, and an identification of that host by
both name and address would have still another value.
Furthermore, different analyzers may produce different values for
the same information.
The "ident" attribute by itself provides a unique identifier only
among all the "ident" values sent by a particular analyzer. But
when combined with the "analyzerid" value for the analyzer, a
value that is unique across the intrusion detection environment
is created. Again, there is no requirement for global
uniqueness.
Debar, et al. Experimental [Page 17]
RFC 4765 The IDMEF March 2007
The default value is "0", which indicates that the analyzer
cannot generate unique identifiers.
The specification of methods for creating the unique values contained
in these attributes is outside the scope of this document.
4. The IDMEF Data Model and DTD
In this section, the individual components of the IDMEF data model
are explained in detail. Unified Modeling Language (UML) diagrams of
the model are provided to show how the components are related to each
other, and relevant sections of the IDMEF DTD are presented to show
how the model is translated into XML.
4.1. Data Model Overview
The relationship between the principal components of the data model
is shown in Figure 1 (occurrence indicators and attributes are
omitted).
The top-level class for all IDMEF messages is IDMEF-Message; each
type of message is a subclass of this top-level class. There are
presently two types of messages defined: Alerts and Heartbeats.
Within each message, subclasses of the message class are used to
provide the detailed information carried in the message.
It is important to note that the data model does not specify how an
alert should be classified or identified. For example, a port scan
may be identified by one analyzer as a single attack against multiple
targets, while another analyzer might identify it as multiple attacks
from a single source. However, once an analyzer has determined the
type of alert it plans to send, the data model dictates how that
alert should be formatted.