File: rfc3067.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (955 lines) | stat: -rw-r--r-- 36,836 bytes parent folder | download | duplicates (5)
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






Network Working Group                                       J. Arvidsson
Request for Comments: 3067                                    Telia CERT
Category: Informational                                       A. Cormack
                                                              JANET-CERT
                                                            Y. Demchenko
                                                                  TERENA
                                                               J. Meijer
                                                                 SURFnet
                                                           February 2001


 TERENA's Incident Object Description and Exchange Format Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The purpose of the Incident Object Description and Exchange Format is
   to define a common data format for the description, archiving and
   exchange of information about incidents between CSIRTs (Computer
   Security Incident Response Teams) (including alert, incident in
   investigation, archiving, statistics, reporting, etc.).  This
   document describes the high-level requirements for such a description
   and exchange format, including the reasons for those requirements.
   Examples are used to illustrate the requirements where necessary.

1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].












Arvidsson, et al.            Informational                      [Page 1]

RFC 3067                   IODEF Requirements              February 2001


2. Introduction

   This document defines requirements for the Incident object
   Description and Exchange Format (IODEF), which is the intended
   product of the Incident Taxonomy Working Group (ITDWG) at TERENA [2].
   IODEF is planned to be a standard format which allows CSIRTs to
   exchange operational and statistical information; it may also provide
   a basis for the development of compatible and inter-operable tools
   for Incident recording, tracking and exchange.

   Another aim is to extend the work of IETF IDWG (currently focused on
   Intrusion Detection exchange format and communication protocol) to
   the description of incidents as higher level elements in Network
   Security.  This will involve CSIRTs and their constituency related
   issues.

   The IODEF set of documents of which this document is the first will
   contain IODEF Data Model and XML DTD specification.  Further
   discussion of this document will take place in the ITDWG mailing
   lists <incident-taxonomy@terena.nl> or <iodef@terena.nl>, archives
   are available correspondently at
   http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and
   http://hypermail.terena.nl/iodef-list/mail-archive/

2.1. Rationale

   This work is based on attempts to establish cooperation and
   information exchange between leading/advanced CSIRTs in Europe and
   among the FIRST community.  These CSIRTs understand the advantages of
   information exchange and cooperation in processing, tracking and
   investigating security incidents.

   Computer Incidents are becoming distributed and International and
   involve many CSIRTs across borders, languages and cultures.  Post-
   Incident information and statistics exchange is important for future
   Incident prevention and Internet security improvement.  The key
   element for information exchange in all these cases is a common
   format for Incident (Object) description.

   It is probable that in further development or implementation the
   IODEF might be used for forensic purposes, and this means that
   Incident description must be unambiguous and allow for future custody
   (archiving/documentation) features.








Arvidsson, et al.            Informational                      [Page 2]

RFC 3067                   IODEF Requirements              February 2001


   Another issue that is targeted by developing IODEF is a need to have
   higher level Incident description and exchange format than will be
   provided by IDS (Intrusion Detection Systems) and the proposed IDEF
   (Intrusion Detection Exchange Format).  Compatibility with IDEF and
   other related standards will be satisfied by the IODEF requirement on
   modularity and extensibility.  IODEF should vertically be compatible
   with IDMEF, IODEF might be able to include or reference IDMEF Alert
   message as initial information about Incident.

2.2. Incident Description Terms

   A definition of the main terms used in the rest of document is given
   for clarity.

   Where possible, existing definitions will be used; some definitions
   will need additional detail and further consideration.

   Taxonomy of the Computer Security Incident related terminology made
   by TERENA's ITDWG [2] is presented in [12].

2.2.1. Attack

   An assault on system security that derives from an intelligent
   threat, i.e., an intelligent act that is a deliberate attempt
   (especially in the sense of a method or technique) to evade security
   services and violate the security policy of a system.

   Attack can be active or passive, by insider or by outsider, or via
   attack mediator.

2.2.2. Attacker

   Attacker is individual who attempts one or more attacks in order to
   achieve an objective(s).

   For the purpose of IODEF attacker is described by its network ID,
   organisation which network/computer attack was originated and
   physical location information (optional).

2.2.3. CSIRT

   CSIRT (Computer Security Incident Response Team) is used in IODEF to
   refer to the authority handling the Incident and creating Incident
   Object Description.  The CSIRT is also likely to be involved in
   evidence collection and custody, incident remedy, etc.

   In IODEF CSIRT represented by its ID, constituency, public key, etc.




Arvidsson, et al.            Informational                      [Page 3]

RFC 3067                   IODEF Requirements              February 2001


2.2.4. Damage

   An intended or unintended consequence of an attack which affects the
   normal operation of the targeted system or service.  Description of
   damage may include free text description of actual result of attack,
   and, where possible, structured information about the particular
   damaged system, subsystem or service.

2.2.5. Event

   An action directed at a target which is intended to result in a
   change of state (status) of the target.  From the point of view of
   event origination, it can be defined as any observable occurrence in
   a system or network which resulted in an alert being generated.  For
   example, three failed logins in 10 seconds might indicate a brute-
   force login attack.

2.2.6. Evidence

   Evidence is information relating to an event that proves or supports
   a conclusion about the event. With respect to security incidents (the
   events), it may include but is not limited to: data dump created by
   Intrusion Detection System (IDS), data from syslog file, kernel
   statistics, cache, memory, temporary file system, or other data that
   caused the alert or were collected after the incident happened.

   Special rules and care must be taken when storing and archiving
   evidence, particularly to preserve its integrity.  When necessary
   evidence should be stored encrypted.

   According to the Guidelines for Evidence Collection and Archiving
   (Evidence) evidence must be strictly secured.  The chain of evidence
   custody needs to be clearly documented.

   It is essential that evidence should be collected, archived and
   preserved according to local legislation.

2.2.7. Incident

   An Incident is a security event that involves a security violation.
   An incident can be defined as a single attack or a group of attacks
   that can be distinguished from other attacks by the method of attack,
   identity of attackers, victims, sites, objectives or timing, etc.

   An incident is a root element of the IODEF. In the context of IODEF,
   the term Incident is used to mean a Computer Security Incident or an
   IT Security Incident.




Arvidsson, et al.            Informational                      [Page 4]

RFC 3067                   IODEF Requirements              February 2001


   However we should distinguish between the generic definition of
   'Incident' which is an event that might lead to damage or damage
   which is not too serious, and 'Security Incident' and 'IT Security
   Incident' which are defined below:

   a) Security incident is an event that involves a security violation.
      This may be an event that violates a security policy, UAP, laws
      and jurisdictions, etc. A security incident may also be an
      incident that has been escalated to a security incident.

      A security incident is worse than an incident as it affects the
      security of or in the organisation. A security incident may be
      logical, physical or organisational, for example a computer
      intrusion, loss of secrecy, information theft, fire or an alarm
      that doesn't work properly.  A security incident may be caused on
      purpose or by accident.  The latter may be if somebody forgets to
      lock a door or forgets to activate an access list in a router.

   b) An IT security incident is defined according to [9] as any real or
      suspected adverse event in relation to the security of a computer
      or computer network.  Typical security incidents within the IT
      area are: a computer intrusion, a denial-of-service attack,
      information theft or data manipulation, etc.

2.2.8. Impact

   Impact describes result of attack expressed in terms of user
   community, for example the cost in terms of financial or other
   disruption

2.2.9. Target

   A computer or network logical entity (account, process or data) or
   physical entity (component, computer, network or internetwork).

2.2.10. Victim

   Victim is individual or organisation which suffered the attack which
   is described in incident report.

   For the purpose of IODEF victim is described by its network ID,
   organisation and location information.

2.2.11. Vulnerability

   A flaw or weakness in a system's design, implementation, or operation
   and management that could be exploited to violate the system's
   security policy.



Arvidsson, et al.            Informational                      [Page 5]

RFC 3067                   IODEF Requirements              February 2001


   Most systems have vulnerabilities of some sort, but this does not
   mean that the systems are too flawed to use.  Not every threat
   results in an attack, and not every attack succeeds.  Success depends
   on the degree of vulnerability, the strength of attacks, and the
   effectiveness of any countermeasures in use.  If the attacks needed
   to exploit a vulnerability are very difficult to carry out, then the
   vulnerability may be tolerable.  If the perceived benefit to an
   attacker is small, then even an easily exploited vulnerability may be
   tolerable.  However, if the attacks are well understood and easily
   made, and if the vulnerable system is employed by a wide range of
   users, then it is likely that there will be enough benefit for
   someone to make an attack.

2.2.12. Other terms

   Other terms used: alert, activity, IDS, Security Policy, etc. - are
   defined in related I-Ds, RFCs and standards [3, 6, 7, 8, 9, 10].

3. General Requirements

3.1. The IODEF shall reference and use previously published RFCs
     where possible.

   Comment:
   The IETF has already developed a number of standards in the areas of
   networks and security that are actually deployed in present Internet.
   Current standards provide framework for compatibility of IODEF with
   other related technologies necessary to operate /implement IODEF in
   practice.  Another issue of compatibility for the IODEF is its
   general compatibility with IDEF currently being developed by IETF
   IDEWG.  In the interest of time and compatibility, defined and
   accepted standards should be used wherever possible.

   In particularly, IODEF specification proposals SHOULD rely heavily on
   existing communications, encryption and language standards, where
   possible.

4. Description Format

4.1. IODEF shall support full internationalization and localization.

   Comment:
   Since some Incidents need involvement of CSIRTs from different
   countries, cultural and geographic regions, the IODEF description
   must be formatted such that they can be presented to an operator in a
   local language and adhering to local presentation formats.





Arvidsson, et al.            Informational                      [Page 6]

RFC 3067                   IODEF Requirements              February 2001


   Although metalanguage for IODEF identifiers and labels is considered
   to be English, a local IODEF implementation might be capable to
   translate metalanguage identifiers and labels into local language and
   presentations if necessary.

   Localized presentation of dates, time and names may also be required.
   In cases where the messages contain text strings and names that need
   characters other than Latin-1 (or ISO 8859-1), the information
   preferably should be represented using the ISO/IEC IS 10646-1
   character set and encoded using the UTF-8 transformation format, and
   optionally using local character sets and encodings [13].

4.2. The IODEF must support modularity in Incident description to
     allow aggregation and filtering of data.

   Comment:
   It is suggested that Incident description with IODEF might include
   external information, e.g., from IDS, or reference externally stored
   evidence custody data, or such information might be removed from
   current IODEF description, e.g., in purposes of privacy or security.
   Another practical/real life motivation for this requirement is to
   give possibility for some CSIRTs/managers to perform filtering and/or
   data aggregation functions on IODEF descriptions for the purposes of
   statistics, reporting and high level Incident information exchange
   between CSIRTs and/or their constituency and sponsors.

   Therefore the IODEF descriptions MUST be structured to facilitate
   these operations.  This also implies to strong IODEF semantics.

4.3. IODEF must support the application of an access restriction
     policy attribute to every element.

   Comment:
   IODEF Incident descriptions potentially contain sensitive or private
   information (such as passwords, persons/organisations identifiers or
   forensic information (evidence data)) and in some cases may be
   exposed to non-authorised persons.  Such situations may arise
   particularly in case of Incident information exchange between CSIRTs
   or other involved bodies.  Some cases may be addressed by encrypting
   IODEF elements, however this will not always be possible.

   Therefore, to prevent accidental disclosure of sensitive data, parts
   of the IODEF object must be marked with access restriction
   attributes.  These markings will be particularly useful when used
   with automated processing systems.






Arvidsson, et al.            Informational                      [Page 7]

RFC 3067                   IODEF Requirements              February 2001


5. Communications Mechanisms Requirements

5.1. IODEF exchange will normally be initiated by humans using
     standard communication protocols, for example, e-mail, WWW/HTTP,
     LDAP.

   Comment:
   IODEF description is normally created by a human using special or
   standard text editors.  The IODEF is targeted to be processed by
   automated Incident handling systems but still must be human readable,
   able to be viewed and browsed with standard tools (e.g., browsers or
   electronic table processors or database tools like MS Excel or
   Access).  Incident information exchange will normally require
   authorisation by  an operator or CSIRT manager so is not expected to
   be initiated automatically.  The role of Incident handling system is
   to provide assistance and tools for performing the exchange.

   It is important to distinguish the purposes of the machine readable
   and exchangeable IDEF Intrusion message format and the human oriented
   and created IODEF Incident description.

   Communications security requirements will be applied separately
   according to local policy so are not defined by this document.

6. Message Contents

6.1. The root element of the IO description should contain a unique
     identification number (or identifier), IO purpose and default
     permission level

   Comment:
   Unique identification number (or identifier) is necessary to
   distinguish one Incident from another.  It is suggested that unique
   identification number will contain information at least about IO
   creator, i.e. CSIRT or related body.  The classification of the
   Incident may also be used to form a unique identification number.  IO
   purpose will actually control which elements are included in the
   IODEF object Purposes may include incident alert/registration,
   handling, archiving, reporting or statistics.  The purpose, incident
   type or status of Incident investigation may require different levels
   of access permission for the Incident information.

   It is considered that root element of the IODEF will be <INCIDENT>
   and additional information will be treated as attributes of the root
   element.






Arvidsson, et al.            Informational                      [Page 8]

RFC 3067                   IODEF Requirements              February 2001


6.2. The content of the IODEF description should contain the type of
     the attack if it is known.

   It is expected that this type will be drawn from a standardized list
   of events; a new type of event may use a temporary implementation-
   specific type if the event type has not yet been standardized.

   Comment:
   Incident handling may involve many different staff members and teams.
   It is therefore essential that common terms are used to describe
   incidents.

   If the event type has not yet been standardized, temporary type
   definition might be given by team created IO.  It is expected that
   new type name will be self-explanatory and derived from a similar,
   existing type definition.

6.3. The IODEF description must be structured such that any relevant
     advisories, such as those from CERT/CC, CVE, can be referenced.

   Comment:
   Using standard Advisories and lists of known Attacks and
   Vulnerabilities will allow the use of their recommendations on
   Incident handling/prevention.  Such information might be included as
   an attribute to the attack or vulnerability type definition.

6.4. IODEF may include a detailed description of the attack that
     caused the current Incident.

   Comment:
   Description of attack includes information about attacker and victim,
   the appearance of the attack and possible impact.  At the early stage
   of Intrusion alert and Incident handling there is likely to be
   minimal information, during handling of the Incident this will grow
   to be sufficient for Incident investigation and remedy. Element
   <ATTACK> should be one of the main elements of Incident description.

6.5. The IODEF description must include or be able to reference
     additional detailed data related to this specific underlying
     event(s)/activity, often referred as evidence.

   Comment:
   For many purposes Incident description does not need many details on
   specific event(s)/activity that caused the Incident; this information
   may be referenced as external information (by means of URL).  In some
   cases it might be convenient to store separately evidence that has
   different access permissions.  It is foreseen that another standard
   will be proposed for evidence custody [5].



Arvidsson, et al.            Informational                      [Page 9]

RFC 3067                   IODEF Requirements              February 2001


6.6. The IODEF description MUST contain the description of the
     attacker and victim.

   Comment:
   This information is necessary to identify the source and target of
   the attack.  The minimum information about attacker and victim is
   their IP or Internet addresses, extended information will identify
   their organisations allowing CSIRTs to take appropriate measures for
   their particular constituency.

6.7. The IODEF description must support the representation of
     different types of device addresses, e.g., IP address (version 4 or
     6) and Internet name.

   Comment:
   The sites from which attack is launched might have addresses in
   various levels of the network protocol hierarchy (e.g., Data layer 2
   MAC addresses or Network layer 3 IP addresses).  Additionally, the
   devices involved in an intrusion event might use addresses that are
   not IP-centric, e.g., ATM-addresses.  It is also understood that
   information about the source and target of the attack might be
   obtained from IDS and include the IP address, MAC address or both.

6.8. IODEF must include the Identity of the creator of the Incident
     Object (CSIRT or other authority).  This may be the sender in an
     information exchange or the team currently handling the incident.

   Comment:
   The identity of Incident description creator is often valuable
   information for Incident response.  In one possible scenario the
   attack may progress through the network, comparison of corresponding
   incidents reported by different authorities might provide some
   additional information about the origin of the attack.  This is also
   useful information at post-incident information handling/exchange
   stage.

6.9. The IODEF description must contain an indication of the
     possible impact of this event on the target.  The value of this
     field should be drawn from a standardized list of values if the
     attack is recognized as known, or expressed in a free language by
     responsible CSIRT team member.

   Comment:
   Information concerning the possible impact of the event on the target
   system provides an indication of what the attacker is attempting to
   do and is critical data for the CSIRTs to take actions and perform





Arvidsson, et al.            Informational                     [Page 10]

RFC 3067                   IODEF Requirements              February 2001


   damage assessment.  If no reference information (Advisories) is
   available, this field may be filled in based on CSIRT team
   experience.

   It is expected that most CSIRTs will develop Incident handling
   support systems, based on existing Advisories (such as those from
   CERT/CC, CVE, etc.) that usually contain list of possible impacts for
   identified attacks.

   This also relates to the development of IDEF which will be
   implemented in intelligent IDS, able to retrieve information from
   standard databases of attacks and vulnerabilities [3].

6.10. The IODEF must be able to state the degree of confidence in
      the report information.

   Comment:
   Including this information is essential at the stage of Incident
   creation, particularly in cases when intelligent automatic IDS or
   expert systems are used.  These normally use statistical engines to
   estimate the event probability.

6.11. The IODEF description must provide information about the
      actions taken in the course of this incident by previous CSIRTs.

   Comment:
   The IODEF describes an Incident throughout its life-time from Alert
   to closing and archiving.  It is essential to track all actions taken
   by all involved parties.  This will help determine what further
   action needs to be taken, if any.  This is especially important in
   case of Incident information exchange between CSIRTs in process of
   investigation.

6.12. The IODEF must support reporting of the time of all stages
      along Incident life-time.

   Comment:
   Time is important from both a reporting and correlation point of
   view.  Time is one of main components that can identify the same
   Incident or attack if launched from many sites or distributed over
   the network.  Time is also essential to be able to track the life of
   an Incident including Incident exchange between CSIRTs in process of
   investigating.








Arvidsson, et al.            Informational                     [Page 11]

RFC 3067                   IODEF Requirements              February 2001


6.13. Time shall be reported as the local time and time zone offset
      from UTC.  (Note: See RFC 1902 for guidelines on reporting time.)

   Comment:
   For event correlation purposes, it is important that the manager be
   able to normalize the time information reported in the IODEF
   descriptions.

6.14. The format for reporting the date must be compliant with all
      current standards for Year 2000 rollover, and it must have
      sufficient capability to continue reporting date values past the
      year 2038.

   Comment:
   It is stated in the purposes of the IODEF that the IODEF shall
   describe the Incident throughout its life-time.  In the case of
   archiving this duration might be unlimited.  Therefore,
   implementations that limit expression of time value (such as 2038
   date representation limitation in "Unix time") MUST be avoided.

6.15. Time granularity in IO time parameters shall not be specified
      by the IODEF.

   Comment:
   The time data may be included into IODEF description by existing
   information systems, retrieved from incident reporting messages or
   taken from IDS data or other event registration tools.  Each of these
   cases may have its own different time granularity.  For the purposes
   of implementation, it should be possible to handle time at different
   stages according to the local system capabilities.

6.16. The IODEF should support confidentiality of the description
      content.

   The selected design should be capable of supporting a variety of
   encryption algorithms and must be adaptable to a wide variety of
   environments.

   Comment:
   IODEF Incident descriptions potentially contain sensitive or private
   information (such as forensic data (evidence data), passwords, or
   persons/organisations identifiers) which would be of great interest
   to an attacker or malefactor.  Incident information normally will be
   stored on a networked computer, which potentially may be exposed to
   attacks (or compromised).  Incident information may be transmitted
   across uncontrolled network segments.  Therefore, it is important
   that the content be protected from unauthorised access and
   modification.  Furthermore, since the legal environment for privacy



Arvidsson, et al.            Informational                     [Page 12]

RFC 3067                   IODEF Requirements              February 2001


   and encryption technologies are varied from regions and countries and
   change often, it is important that the design selected be capable of
   supporting a number of different encryption options and be adaptable
   by the user to a variety of environments. Additional measures may be
   undertaken for securing the Incident during communication but this
   issue is outside of IODEF scope as it implies more strict rules for
   IO archiving and storing in general.

6.17. The IODEF should ensure the integrity of the description
      content.

   The selected design should be capable of supporting a variety of
   integrity mechanisms and must be adaptable to a wide variety of
   environments.

   Comment:
   Special measures should be undertaken to prevent malicious IO
   changes.

   Additional measures may be undertaken for securing the Incident
   during communication but this issue is outside of IODEF scope.

6.18. The IODEF should ensure the authenticity and non-repudiation
      of the message content.

   Comment:
   Authenticity and accountability is needed by many teams, especially
   given the desire to automatically handle IOs, therefore it MUST be
   included in the IODEF.  Because of the importance of IO authenticity
   and non-repudiation to many teams and especially in case of
   communication between them, the implementation of these requirements
   is strongly RECOMMENDED.

6.19. The IODEF description must support an extension mechanism
      which may be used by implementers.  This allows future
      implementation-specific or experimental data.  The implementer
      MUST indicate how to interpret any included extensions.

   Comment:
   Implementers might wish to supply extra data such as information for
   internal purposes or necessary for the particular implementation of
   their Incident handling system.  These data may be removed or not in
   external communications but it is essential to mark them as
   additional to prevent wrong interpretation by different systems.







Arvidsson, et al.            Informational                     [Page 13]

RFC 3067                   IODEF Requirements              February 2001


6.20. The semantics of the IODEF description must be well defined.

   Comment:
   IODEF is a human oriented format for Incident description, and IODEF
   description should be capable of being read by humans.  The use of
   automatic parsing tools is foreseen but should not be critically
   necessary.  Therefore, IODEF must provide  good semantics, which will
   be  key to understanding what the description contains.  In some
   cases the IODEF description will be used for  automatic decision
   making, so it is important that the description be interpreted
   correctly.  This is an argument for using language-based semantics.
   The metalanguage for IODEF identifiers and labels is proposed to be
   English, a local IODEF implementation might be able to translate
   metalanguage identifiers and labels into local language and
   presentations if necessary.

7. IODEF extensibility

7.1. The IODEF itself MUST be extensible.  It is essential that when
     the use of new technologies and development of automated Incident
     handling system demands extension of IODEF, the IODEF will be
     capable to include new information.

   Comment:
   In addition to the need to extend IODEF to support new Incident
   handling tools, it is also suggested that IODEF will incorporate new
   developments from related standardisation areas such as IDEF for IDS
   or the development of special format for evidence custody.  The
   procedure for extension should be based on CSIRT/IODEF community
   acceptance/approval.

8. Security Considerations

   This memo describes requirements to an Incident Object Description
   and Exchange Format, which intends to define a common data format for
   the description, archiving and exchange of information about
   incidents between CSIRTs (including alert, incident in investigation,
   archiving, statistics, reporting, etc.).  In that respect the
   implementation of the IODEF is a subject to security considerations.
   Particular security requirement to access restriction indication is
   discussed in section 4.3, requirements to Incident description
   confidentiality, integrity, authenticity and non-repudiation are
   described in sections 6.16, 6.17, 6.18.








Arvidsson, et al.            Informational                     [Page 14]

RFC 3067                   IODEF Requirements              February 2001


9. References

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

   [2]  Incident Taxonomy and Description Working Group Charter -
        http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/

   [3]  Intrusion Detection Exchange Format Requirements by Wood, M. -
        December 2000, Work in Progress.

   [4]  Intrusion Detection Message Exchange Format Extensible Markup
        Language (XML) Document Type Definition by D. Curry, H. Debar -
        February 2001, Work in Progress.

   [5]  Guidelines for Evidence Collection and Archiving by Dominique
        Brezinski, Tom Killalea - July 2000, Work in Progress.

   [6]  Brownlee, N. and E. Guttman, "Expectations for Computer Security
        Incident Response", BCP 21, RFC 2350, June 1998.

   [7]  Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
        2000.

   [8]  Establishing a Computer Security Incident Response Capability
        (CSIRC). NIST Special Publication 800-3, November, 1991

   [9]  Handbook for Computer Security Incident Response Teams (CSIRTs),
        Moira J. West-Brown, Don Stikvoort, Klaus-Peter Kossakowski. -
        CMU/SEI-98-HB-001. - Pittsburgh, PA: Carnegie Mellon University,
        1998.

   [10] A Common Language for Computer Security Incidents by John D.
        Howard and Thomas A. Longstaff. -  Sandia Report: SAND98-8667,
        Sandia National Laboratories -
        http://www.cert.org/research/taxonomy_988667.pdf

   [11] Best Current Practice of incident classification and reporting
        schemes currently used by active CSIRTs. -
        http://www.terena.nl/task-forces/tf-csirt/i-
        taxonomy/docs/BCPreport1.rtf

   [12] Taxonomy of the Computer Security Incident related terminology -
        http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/i-
        taxonomy_terms.html

   [13] Multilingual Support in Internet/IT Applications. -
        http://www.terena.nl/projects/multiling/



Arvidsson, et al.            Informational                     [Page 15]

RFC 3067                   IODEF Requirements              February 2001


Acknowledgements:

   This document was discussed at the Incident Taxonomy and Description
   Working Group seminars (http://www.terena.nl/task-forces/tf-
   csirt/tf-csirt000929prg.html#itdwg) in the frame of TERENA Task Force
   TF-CSIRT (http://www.terena.nl/task-forces/tf-csirt/).  Incident
   Taxonomy and Description Working Group at TERENA can be contacted via
   the mailing lists <incident-taxonomy@terena.nl> or <iodef@terena.nl>,
   archives are available correspondently at
   http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and
   http://hypermail.terena.nl/iodef-list/mail-archive/

Authors' Addresses

   Jimmy Arvidsson
   Telia CERT

   EMail: Jimmy.J.Arvidsson@telia.se


   Andrew Cormack
   JANET-CERT

   EMail: Andrew.Cormack@ukerna.ac.uk


   Yuri Demchenko
   TERENA

   EMail: demch@terena.nl


   Jan Meijer
   SURFnet

   EMail: jan.meijer@surfnet.nl















Arvidsson, et al.            Informational                     [Page 16]

RFC 3067                   IODEF Requirements              February 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Arvidsson, et al.            Informational                     [Page 17]