IODEF Data Model Status (changes from 02 to 03) - - PowerPoint PPT Presentation

iodef data model status
SMART_READER_LITE
LIVE PREVIEW

IODEF Data Model Status (changes from 02 to 03) - - PowerPoint PPT Presentation

IODEF Data Model Status (changes from 02 to 03) <draft-ietf-inch-iodef-03> tracked @ https://rt.psg.com : inch-dm queue Roman Danyliw <rdd@cert.org> Thursday, November 11. 2004 IETF 61, Washington DC, USA Outline Changes from v02


slide-1
SLIDE 1

IODEF Data Model Status

(changes from 02 to 03)

<draft-ietf-inch-iodef-03>

tracked @ https://rt.psg.com : inch-dm queue

Roman Danyliw <rdd@cert.org> Thursday, November 11. 2004 IETF 61, Washington DC, USA

slide-2
SLIDE 2

November 11. 2004 IETF 61 2

Outline

Changes from v02 to v03

slide-3
SLIDE 3

November 11. 2004 IETF 61 3

Editorial Changes

  • Compressed the ASCII-art pictures for the classes
  • Made UML diagrams, text description, and the DTD

consistent

  • Re-wrote introduction (Section 1)
  • Simplified XML section (Section 2.1)
  • Simplified the Processing considerations (Section 5)
  • Simplified the Security considerations (Section 9)
  • Reference IDMEF specification for <Impact> and

<Confidence>

  • Dropped all legacy normative references
  • More polished text for many of the class descriptions
slide-4
SLIDE 4

November 11. 2004 IETF 61 4

Simplify the Data Model (#472)

https://rt.psg.com/Ticket/Display.html?id=472

  • Removed legacy (IDMEF) classes

– File system classes: <FileList>, <File>, <inode>, etc. – Layer 7 classes: <SNMPService>, <HTTPService> – User classes: <User>, <UserId>

  • Removed unused classes

– <number> – <LifeImpact>

  • Removed redundant classes

– Removed <History> from <EventData> (already in <Incident>)

slide-5
SLIDE 5

November 11. 2004 IETF 61 5

Simplify the Data Model (#472) 2

https://rt.psg.com/Ticket/Display.html?id=472

  • Simplify representations when possible

– Merged <IncidentData> into <Incident> – Simplified <Address> to not use <address> and <netmask>

  • <!ELEMENT Address (address, netmask?)>

+ <!ELEMENT Address (#PCDATA)>

– Simplified <Service> to no longer redundantly

  • <!ELEMENT Service (((name?, port), portlist, protocol?)>

+ <!ELEMENT Service ((port | portlist), Application?)> + <!ATTLIST Service + ip_version CDATA "4" + ip_protocol CDATA #REQUIRED >

– Removed NTPSTAMP (ntpstamp attribute) representation from the Time classes – Removed @restriction attribute from <Impact>, <TimeImpact>, and <MonetaryImpact>

slide-6
SLIDE 6

November 11. 2004 IETF 61 6

Clean-up Attributes

  • Default value of

Address@category="ipv4-addr” not "unknown“

  • Dropped Contact@role="actor"

enumerated value referenced in the <Expectation> class

slide-7
SLIDE 7

November 11. 2004 IETF 61 7

Add new data

  • Added "asn" to %attvals.addrcat in

<Address> (Issue #359)

  • Added "investigate" to attvals.expectcat

in <Expectation>

  • Introduced <Application> (and replace

<Process> of <System>, added to <Service>)

slide-8
SLIDE 8

November 11. 2004 IETF 61 8

Flow Notation and Summarization Support (#360)

https://rt.psg.com/Ticket/Display.html?id=360

  • Added <Flow> as child of <EventData>

to encapsulate <System>s

  • Added <Counter> to <Node> and

<Service>

slide-9
SLIDE 9

November 11. 2004 IETF 61 9

Outline

Open Issues

slide-10
SLIDE 10

November 11. 2004 IETF 61 10

#356: Standardize extensions

https://rt.psg.com/Ticket/Display.html?id=356

  • Add a mandatory top-level container class to all extensions to allow

an easy determination of which one is used

  • PROPOSAL

<!ELEMENT IODEF-Extention (ANY)> <!ATTLIST IODEF-Extention name CDATA #REQUIRED source CDATA #REQUIRED version CDATA #IMPLIED >

  • STATUS:

– Will fix with Schema trickery? How?

slide-11
SLIDE 11

November 11. 2004 IETF 61 11

#551: Formalizing <RecordData>

https://rt.psg.com/Ticket/Display.html?id=551

  • Add meta-information so that in-lined

logs snippets and those reference externally can be processed

  • PROPOSALS

– Add a way to specify filter patterns and offsets into text and binary log files

  • STATUS: further discussion needed
slide-12
SLIDE 12

November 11. 2004 IETF 61 12

Other Issues

  • Rename and redesign Analyzer (drop <pid>, <path>,

<Process>); make it more similar to <Application>

  • Should <Application> be added to <Method>? (i.e.,

how to represent attack tools? Is using the System/Service/Application sufficient?)

  • Decide whether <Contact>/<name> requires its own

class since it is formatted as PERSON, but in other uses of <name> it is STRING.

  • Representing OS of <System>
slide-13
SLIDE 13

November 11. 2004 IETF 61 13

TODO

  • To be written

– IODEF Schema (done for v02, needs update for v03) – IANA Considerations – Examples and description of XML-Signature and XML-Encryption in Security Considerations

  • Define sane default values for all

attributes

  • Specify format of the TIMEZONE data-

type

slide-14
SLIDE 14

November 11. 2004 IETF 61 14

Moving Forward

  • Release an 04 draft using Schema

within a month Comments?