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

implementing the iodef at the cert cc
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

Implementing the IODEF at the CERT/CC

Roman Danyliw

<rdd@cert.org>

INCH – IETF 55

slide-2
SLIDE 2

November 22. 2002 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)
slide-3
SLIDE 3

November 22. 2002 IETF 55 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

slide-4
SLIDE 4

November 22. 2002 IETF 55 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

slide-5
SLIDE 5

November 22. 2002 IETF 55 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

slide-6
SLIDE 6

November 22. 2002 IETF 55 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

slide-7
SLIDE 7

November 22. 2002 IETF 55 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

slide-8
SLIDE 8

November 22. 2002 IETF 55 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

slide-9
SLIDE 9

November 22. 2002 IETF 55 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