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

2. Incident object Description and Exchange Format
Agenda
IETF IDWG IDMEF Documents
IODEF Documents
Discussion of IODEF Requirements Draft
IODEF Model
How to proceed?
Evidence Collection and Archiving
Draft-ietf-grip-prot-evidence-01.txt
TF-CSIRT interest?
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

3. Incident object Description and Exchange Format
IDMEF Documents
Currently on the IETF IDWG std process
IDMEF Requirements
IDMEF Data Model
IDMEF XML DTD
IMDEF ANS.1 MIBII format
Intrusion Alert Protocol
IDMEF is for Intrusion Detection Systems
Root element – Alert
Short life history
Data collected automatically
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

4. Incident Taxonomy and Classification WG at TF-CSIRT - History
BoF and Seminar at 3rd CERT-COORD meeting in Vienna
mailing list
IODEF BoF at 12th FIRST
30 attendees
established
Talks to IETF GRIP and IDWG at IETF-48
Under discussion
IODEF documents – to be finalised
Discussion, contribution
Implementations
New or coordinated
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

5. Incident object Description and Exchange Format
IODEF Documents
Best Current Practice on Incident classification and reporting schemes.
Version 1.
Incident Object Description and Exchange Format Requirements
Draft Version 02.
Incident Object Data Model
To be drafted
Incident Object Elements Description and XML Data Type Description (XML DTD)
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

6. Incident object Description and Exchange Format
Incident Object Description and Exchange Format Requirements - Draft Version 02
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. Incident Identifiers and Incident Identifiers Definition Process
9. Reference
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

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

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

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

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

11. Incident object Description and Exchange Format
7. Message Contents
7.1. The root element of the IO description should contain a unique identification number, IO purpose and default permission level
 7.2. The content of 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.
7.4. IODEF may include a detailed description of 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.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

12. 7. Message Contents - Continue
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.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

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.
7.10. The IODEF must be able to state the degree of confidence which the originator has 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
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

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.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

15. 7. Message Contents - Continue
7.16. The IODEF should support confidentiality of the message 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 message 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.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

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

17. Incident Object Data Model
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

18. IODEF std process – How to proceed?
Best Current Practice on Incident classification and reporting schemes.
Version 1
Go to std/i-d?
Incident Object Description and Exchange Format Requirements
Draft Version 02
Ready to submit to IETF – GRIP or IDWG or new WG?
Incident Object Data Model
To be drafted – currently just chart
Incident Object Elements Description and XML Data Type Description (XML DTD)
To be drafted
Evidence Collection and Archiving Format
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

19. Evidence Collection and Archiving draft-ietf-grip-prot-evidence-01.txt
2. Guiding Principles during Evidence Collection
2.1. Order or volatility
2.2. Things to avoid
3. The collection procedure
3.1. Transparency
3.2. Collection steps
4. The Archiving Procedure
4.1. Chain of Custody
4.2. The Archive
5. Tools you’ll need
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

20. Evidence Collection and Archiving The collection procedure
Collection steps
Where is the evidence?
Establish what is likely to be relevant and admissable
For each system obtain the relevant list of volatility
Remove the external avenue for change
Collect the evidence
Document each step
Consider cryptographically signing
Keep not changing Evidence
Have a forensic CD with necessary SW
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

21. Evidence Collection and Archiving The Archiving Procedure
Chain of custody – what need to be documented
Where, when and by whom was the evidence discovered
Where, when and by whom was the evidence handled or examined
Who had custody of the evidence, during what period. How was it stored
When the evidence changed custody, when and how did the transfer occur (include shipping number, etc.)
Access to evidence should extremely limited, and should be clearly documented.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format

22. Evidence Collection and Archiving draft-ietf-grip-prot-evidence-01.txt
Problems of current I-D
No common format defined
Needs some study of local legislation
Privacy and re-enforcement
How can we contribute
Comment on I-D
Propose Evidence description format
New document?
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format