1. Incident Object Description and Exchange Format TF-CSIRT at TERENA IODEF Editorial Group Jimmy Arvidsson Andrew Cormack Yuri Demchenko Jan Meijer

2. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _2 Outlines  TERENA TF-CSIRT and Incident Taxonomy and Description WG - History  IODEF Documents u Discussion of IODEF Requirements Draft – draft-terena-itdwg-iodef-requirements-00.txt u IODEF Model u IODEF XML DTD  How to proceed? u Relation to IDWG u Pilot implementation between CSIRTs (primarily European)  Other documents/areas of interest u Evidence Collection and Archiving (currently - d raft-ietf-grip-prot-evidence- 01.txt) and further standardisation

3. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _3 Incident Taxonomy and Description WG at TERENA TF-CSIRT - History  Incident Taxonomy and Description WG u Established at BoF and Seminar at 3 rd CERT-COORD meeting on May 11- 12, 2000 in Vienna –Webpage and charter - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/ –mailing list - i-taxonomy@terena.nli-taxonomy@terena.nl –Archive - http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ u Seminar on IODEF – September 28, 2000, Paris u Next meeting – January 18-19, 2001, Barcelona  IODEF BoF at 12 th FIRST Conference in Chicago u 30 attendees u established mailing list iodef@terena.nliodef@terena.nl u Archive - http://hypermail.terena.nl/iodef-list/mail-archive/http://hypermail.terena.nl/iodef-list/mail-archive/

4. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _4 IODEF purposes A uniform incident classification enables applications such as:  uniform statistic generation and exchange, for both domestic use and exchange of data between teams. Over time a distributed incident statistics infrastructure can evolve  trend-analyses for reoccurrence of incidents, victims, attackers, etc.  trend-analyses for relations between scans and attacks and thus begin working on pro-active incident response  uniform internal incident storage  incident handling between teams made easier (only one team needs to classify and analyze the complete incident, the other team can re-use this data)  uniform incident reporting by victims to CSIRTs Main IODEF actors are CSIRTs – not IDS

5. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _5 IODEF Documents Best Current Practice on Incident classification and reporting schemes.  Version 1 http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/BCPreport1.rtf http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/BCPreport1.rtf Incident Object Description and Exchange Format Requirements  Submitted as Internet-Draft http://www.ietf.org/internet-drafts/draft-terena-itdwg-iodef-requirements-00.txthttp://www.ietf.org/internet-drafts/draft-terena-itdwg-iodef-requirements-00.txt Incident Object Data Model  To be drafted before January 18, 2001 Incident Object Elements Description and XML Data Type Description (XML DTD)  To be drafted before January 18, 2001

6. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _6 Incident Object Description and Exchange Format Requirements - draft-terena-itdwg-iodef-requirements-00.txt 1. Abstracts 2. Conventions used in this document 3. Introduction 3.1. Rationale 3.2. Incident Description Terms 4. General Requirements 5. Description Format 6. Communications Mechanisms Requirements 7. Message Contents 8. IODEF extensibility 9. Security considerations 10. Reference

7. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _7 3.2. Incident Description Terms Attack Attacker CSIRT Damage Event Evidence Incident Impact Target Victim Vulnerability Other terms: alert, activity, IDS, Security Policy, etc.

8. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _8 4. General Requirements 4.1. The IODEF shall reference and use previously published RFCs where possible.

9. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _9 5. Description Format 5.1. IODEF format shall support full internationalization and localization. 5.2. The format of IODEF must support modularity in Incident description to allow aggregation and filtering of data 5.3. IODEF must support the application of an access restriction policy attribute to every element.

10. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _10 6. Communications Mechanisms Requirements 6.1. IODEF exchange will normally be initiated by humans using standard communication protocols, for example, e-mail, WWW/HTTP, LDAP.

11. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _11 7. Message Contents 7.1. The root element of the IO description should contain a unique identification number (or identifier), IO purpose and default permission level 7.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. 7.3. The IODEF description must be structured such that any relevant advisories, such as those from CERT/CC, CVE, can be referenced.

12. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _12 7. Message Contents - Continue 7.4. IODEF may include a detailed description of the attack that caused the current Incident. 7.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. 7.6. The IODEF description MUST contain the description of the attacker and victim. 7.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.

13. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _13 7. Message Contents - Continue 7.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. 7.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. 7.10. The IODEF must be able to state the degree of confidence in the report information. 7.11. The IODEF description must provide information about the actions taken in the course of this incident by previous CSIRTs.

14. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _14 7. Message Contents - Continue 7.12. The IODEF must support reporting of the time of all stages along Incident life-time. 7.13. Time shall be reported as the local time and time zone offset from UTC. (Note: See RFC 1902 for guidelines on reporting time.) 7.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. 7.15. Time granularity in IO time parameters shall not be specified by the IODEF.

15. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _15 7. Message Contents - Continue 7.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. 7.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. 7.18. The IODEF should ensure the authenticity and non-repudiation of the message content.

16. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _16 7. Message Contents - Continue 7.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. 7.20. The semantics of the IODEF description must be well defined.

17. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _17 8. IODEF extensibility 8.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.

18. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _18 Incident Object Data Model http://www.terena.nl/task- forces/tf-csirt/i- taxonomy/docs/iodef- datamodelv01.html

19. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _19 IODEF XML Description Example http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/iodef- xmldtdv01example.html <incident incid=# msgid=# status={alert, handling/processing, communication/exchange, archive, closed, statistics} permission={public, restricted, internal, ???}> data modification information server $$$$ $$$Time block$$$$ password list compromised all users advised to change passwords

20. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _20 IODEF XML Description Example - Continue $$$ $$$$ $$$$$ $$$$$ $$$ $$$$ ######### ###########

21. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _21 IODEF std process – How to proceed further? Best Current Practice on Incident classification and reporting schemes. - Version 1  May be updated as TF-CSIRT internal document 3 documents on Incident Object Description and Exchange Format  To be developed and submitted to IETF u Which WG – IDWG O.K.? Evidence Collection and Archiving at GRIP WG  Problems of current I-D - draft-ietf-grip-prot-evidence-01.txt u No common format defined –No commitment from GRIP  Needs some study of local legislation u Privacy and re-enforcement Implementation  Planned between few European CSIRTs

22. ©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format Slide2 _22 IDMEF Documents  Currently on the IETF IDWG std process u IDMEF Requirements – withdrawn from I-D ??? u IDMEF Data Model u IDMEF XML DTD u IMDEF ANS.1 MIBII format u Intrusion Alert Protocol  IDMEF is for Intrusion Detection Systems u Main actors - IDS u Root element – Alert –Short life history u Data collected automatically