implementing the iodef at the cert cc
play

Implementing the IODEF at the CERT/CC Roman Danyliw - PowerPoint PPT Presentation

Implementing the IODEF at the CERT/CC Roman Danyliw <rdd@cert.org> INCH IETF 55 Incident Reporting Forms CERT Coordination Center (CERT/CC) Federal Computer Incident Response Capability (FedCIRC) National


  1. Implementing the IODEF at the CERT/CC Roman Danyliw <rdd@cert.org> INCH – IETF 55

  2. Incident Reporting Forms • CERT Coordination Center (CERT/CC) • Federal Computer Incident Response Capability (FedCIRC) • National Infrastructure Protection Center (NIPC) • Defence Information System Agency (DISA) November 22. 2002 IETF 55 2

  3. Contact Information is too hard • There are 3 to contact classes, each represents a subset of the same information – Organization class – Contact class – IRTContact class • Propose : a unified class to represent contact information November 22. 2002 IETF 55 3

  4. Incomplete Contact Representation • Need additional information for contacts: – Point of Contact, – title, – phone, – email, – fax, – country, – timezone • Propose : adding this data to the Contact classes November 22. 2002 IETF 55 4

  5. Using Extensions • All data cannot be represented in IODEF – Extend schema using AdditionalData class • Human readability of AdditionalData diminishes quickly after a few elements • Propose : “Schema Locality” – Add AdditionalData to certain top-level IODEF container classes November 22. 2002 IETF 55 5

  6. Action Annotation not Machine-readable • Difficult to quickly (and in a machine readable way) to separate the elements from the History class – Who was contacted? – What actions were taken? • Propose : Separating the “communication log” in the History class to another class November 22. 2002 IETF 55 6

  7. Incomplete Impact Assessment • Quantifying Cost and Time of recovery – Recovery time (staff hours) – Recovery time (wall-clock) – Cost – Number of customer affected • Operational Impact – Did the attack disrupt core services? – Has the attack stopped? • Propose : Expanding the flexibility of the Impact class November 22. 2002 IETF 55 7

  8. Attack Tools Represenation • Difficult to represent information about the attack tool or technique used – Source.Program class – Method class • Propose : Expanding the flexibility of the Method class November 22. 2002 IETF 55 8

  9. Complex Incident Representation • Need resolution to Attacker/Source and Victim/Target class relationships http://listserv.surfnet.nl/scripts/wa.exe?A2=ind02&L =inch&O=D&P=6599 November 22. 2002 IETF 55 9

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend