IODEF vs IDMEF: XML DTD analysis

IODEF vs IDMEF: XML DTD analysis

This document in RTF format.

Initial assumptions:

1. IODEF should be compatible with IDMEF and be capable to use/include IDMEF message into IO, e.g. as or inside of IncidentAlert IO class. However, backward compatibility is not required, i.e. it's not necessary that IODEF message will be understood by IDS or Intrusion Alert System. It is expected that Security administrator if necessary runs Incident Handling System.
2. If some elements or attributes intersect, options should be considered: change name in IODEF, adopt to IODEF or extend

Problems discovered in developing IODEF from IDMEF

Note.

1. These comments refer to the current IO Data Model http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/iodef-datamodelv01.html
2. For clarity all terms related to IODEF are marked */IODEF, and those related to IDMEF - */IDMEF
3. Initial Version 0.0 of IODEF XML DTD is available (Format DTD, TXT)

Problem/Question	Definitions from IDMEF and Comment	Suggestion/Action
1. Is it possible to reuse (confirmed) IDMEF to generate in a simplest way IncidentAlert (message)	Possible format for IODEF IncidentAlert: Some Data Authority created IO AdditionalData containing IDMEF	TBConsidered. Ask IDWG about lifetime of IDMEF: What happen with confirmed Intrusion?
2. Consider possibility/need of Incident classification. Is it necessary if we have already classification of Vulnerabilities and Attacks in related documents?		TBC
3. Consider using IRT-Role entry in RIPE database for identifying Security contact for Victim and Attacker		TBC
4. Compare (target, source)/IDMEF and (target, source)/IODEF. Does source/IDMEF cover/equal to Attacker/IODEF?	The Target class contains information about the possible target(s) of the event(s) that generated an alert. An event may have more than one target (e.g., in the case of a port sweep). The Target class is composed of four aggregate classes: Node, User, Process, Service The Source class contains information about the possible source(s) of the event(s) that generated an alert. An event may have more than one source (e.g., in a distributed denial of service attack). The Source class is composed of four aggregate classes: Node, User, Process, Service <Source ident="a1a2" spoofed="yes"> <Node ident="a1a2-1"> <Address ident="a1a2-2" category="ipv4-addr"> <address>222.121.111.112</address> </Address> </Node> </Source> <Target ident="b3b4"> <Node> <Address ident="b3b4-1" category="ipv4-addr"> <address>123.234.231.121</address> </Address> </Node> </Target>	O.K. to reuse
5. Definition of impact/IDMEF	Impact (Optional). The evaluated impact of the event(s) leading up to the alert on the target. The permitted values for this attribute are shown below. The default value is "unknown".	O.K. to reuse
6. IDMEF uses detectTime/IDMEF. What is related element in IODEF	Consider registrationTime/IODEF The DetectTime class is used to indicate the date and time the event(s) producing an alert was detected by the analyzer. In the case of more than one event, the time the first event was detected. (This may or may not be the same time as CreateTime; analyzers are not required to send alerts immediately upon detection). The DetectTime class has one attribute: ntpstamp representing the same date and time as the element content.	Can be adopted
7. It seems that name "datetime" is commonly used in XML world but IDMEF use "date-time" with dash. Ask them about this.	Date-time strings are represented by the DATETIME data type. Each date-time string identifies a particular instant in time; ranges are not supported. Date-time strings are formatted according to a subset of ISO 8601:2000, as show below. Section references in parentheses refer to sections of the ISO 8601:2000 standard.	O.K.
8. IDMEF intends to define tool of the attack by element ToolAlert	ToolAlert is subclass of Alert. The ToolAlert class carries additional information related to the use of attack tools or malevolent programs such as Trojan horses, and can be used by the analyzer when it is able to identify these tools. It is intended to group one or more previously-sent alerts together, to say "these alerts were all the result of someone using this tool." The ToolAlert class is composed of three aggregate classes: name, command, alertident.	No suggestions. (Not applicable for IODEF)
9. Reuse definition of "Alertident" for extended identification of Incidents.	AlertIdent - the list of alert identifiers that are related to this alert. Because alert identifiers are only unique across the alerts sent by a single analyzer, the optional "analyzerid" attribute of "alertident" should be used to identify the analyzer that a particular alert came from. If the "analyzerid" is not provided, the alert is assumed to have come from the same analyzer that is sending the ToolAlert. <CorrelationAlert> <name>multiple ports in short time</name> <alertident>123456781</alertident> <alertident>123456782</alertident> <alertident analyzerid="a1b2c3d4">987654321</alertident> </CorrelationAlert>	Not applicable for IODEF
10. Check "user" and "userId" from IDMEF. Do we have/need "user*" element in IODEF?	The User class is used to describe user that is receiving the event(s). It is primarily used as a "container" class for the UserId aggregate class. The UserId class provides specific information about a user. More than one UserId can be used within the User class to indicate attempts to transition from one user to another, or to provide complete information about a user's (or process') privileges. The UserId class is composed of two aggregate classes: name, number.	User class in IDMEF is not clearly defined. Comment to IDWG.
11. IDMEF doesn't contain elements Attack and Vulnerability because Attack is a confirmed Intrusion that is being handled by CSIRT/humans What's relation between Alert and Attack?	Vulnerability is covered by Classification element. However, it looks a bit indefinite as sub-element of <!ELEMENT Alert (Analyzer, CreateTime, DetectTime?, AnalyzerTime?, Source, Target, Classification+, ToolAlert?, OverflowAlert?, CorrelationAlert?, AdditionalData)> The Classification class* provides the "name" of an alert, or other information allowing the manager to determine what it is (for example, to decide whether or not to display the alert on-screen, what color to display it in, etc.). The Classification class is composed of two aggregate classes: name (of vulnerability), url.	TBC
12. IDMEF doesn't contain element Vulnerability	It seems like Vulnerability is covered by Classification element
13. Check meaning/definition of "classification" in IDMEF. Does it mean known/registered vulnerability	<Classification origin="bugtraqid"> <name>629</name> <url>http://www.securityfocus.com</url> </Classification>	Classification class not clearly defined. Is it related to Vulnerabilities, exposure or Attacks. If latter, what's attack?
14. Check definition of method/IDMEF And consider changing/redefining Method/IODEF and/or moving: Vulnerability to Attack and Evidence to Top level elements/classes or to AdditionalData	IDMEF: Service>webservice>method The HTTP method (PUT, GET) used in the request <!ELEMENT WebService (url, cgi?, method?, arg*)> <WebService> <url> http://www.bigcompany.com/cgi-bin/phf?/etc/group </url> <cgi>/cgi-bin/phf</cgi> <method>GET</method> </WebService>	Contact IDWG to change method to httpmethod. Using generic term *method* is not good in general.
15. Consider reusing the following terms from IDMEF: size number url location name	Size is a sub-element of OverflowAlert	N/A
	Number is a sub-element of userId
	url (exactly one string)-used in classification, WebService	O.K.
	location - sub-element of node (location, name address)	Not clearly defined.
	name - has diverse number of definitions: name of a particular tool in ToolAlert, name of equipment in node, name of the alert in Classification from one of the known origins, etc.	Not clearly defined. Meaning depends on place in IDMEF hierarchy.