Subject: [mile] considerations for IETF 84 guidance / updating IODEF discussion

From: Rossella Mattioli <[email-masked]>
Date: Thu, 26 Jul 2012 18:41:42 +0200

Hi all,

considering the agenda of IETF 84 I would like to submit to the list some thoughts on the guidance / updating IODEF discussion.
These gaps and overlaps emerged during the data set analysis of 89 publicly available data feeds for response teams I made for my research.
Hope they can be of help for next week meeting.

Contact class: IODEF covers most of the available information within contact@role. There are some values that are not directly mapping with popular type of role such as sensor but this can be done via cross reference with the system@category for what concerns the sensor value. For what concerns LEA and vulnerability reporter there are two ways of implementation:

	• implement the escape value to extend this attribute;

	• foster the adoption of these values within the official data schema.

Moreover since PGP is widely used within the security community an ad-hoc element should be considered for future implementation.

Time: the time classes offered by IODEF cover most of the values encountered.There is one value that occurred in the data I analyzed which was not covered: next validation time. This gap can be fulfilled with escape value.

Address: to define an address IODEF already includes all the granularity to define IPv4, IPv6 and ASN numbers in the system and node classes. At the moment only domain data is not fully covered by the current data schema and in order to fulfill this gap two possible actions can be evaluated:

	• to use the definition of the class from RFC 5901 and describe the information with the DomainData, DomainContacts and Nameservers elements;

	• to implement a new class regarding the domain data with an update of the IODEF data schema. 

System@category: currently IODEF covers the typology of role of the system@category enumeration. The present values are infrastructure, intermediate, sensor, source and target. While attacker and destination could be considered as covered by source and target, they probably don't completely comply with the definition within RFC 5070. Another important point regards sinkhole and command&controls, these specific roles and possibilities are not clearly described in this RFC. This could be addressed in two ways:

	• a new guidance of the current data schema using existing values;

	• the further implementation of the available values in the system@category.

Status: At the moment IODEF does not handle the status of an address as detailed in the incident characterization that emerged in my research. In the RFC 5901 there are two enumerations regarding the Domain status and System Status that can partially fill this gap. Unfortunately they do not reflect the values extrapolated from the analyzed data which are the following:

	• offline / online

	• allocated / unallocated

	• advertised / unadvertised

	• inconsistent

There are two actions that could be considered:

	• fostering the implementation of a new guidance of the RFC 5070 system@spoofed (yes, no, unknown) in accordance with RFC 5901 values for system@status (spoofed, fraudulent. innocent-hacked, innocent-hijacked, unknown) and domain@status (reservedDelegation, assignedAndActive, assignedAndInactive, assignedAndOnHold, revoked, transferPending, registryLock, registrarLock) which occurs only in Fraud reporting;

	• implement a new set of enumerations which expands RFC 5070.

Impact@type:The attack part is not covered at the moment in IODEF. Two kinds of attempts can be recognized in this direction. One is the Impact@type values of RFC 5070:

	• admin. Administrative privileges were attempted;

	• dos. A denial of service was attempted;

	• file. An action that impacts the integrity of a file or database was attempted;

	• info-leak. An attempt was made to exfiltrate information;

	• misconfiguration. An attempt was made to exploit a mis-configuration in a system;

	• policy. Activity violating site's policy was attempted;

	• recon. Reconnaissance activity was attempted;

	• social-engineering. A social engineering attack was attempted;

	• user. User privileges were attempted.

and one is the Fraud@type in RFC 5901:

	• phishing;

	• recruiting;

	• malware distribution;

	• fraudulent site;

	• dnsspoof.

As it can be noted this characterization lacks of structure due to the overlap between attack vectors and impacts and hampers a clear identification of the occurring incident within the IODEF data model without the use of the Fraud extension. Indeed the more detailed description provided by RFC 5901 occurs only in case of fraudulent incidents. Due to this lack of equivalent values between the data available and the IODEF data model, it should be discussed:

	• further guidance on how to use the existing IODEF data-model possibilities to characterize an attack;

	• the definition of an high level taxonomy.

Malware: IODEF does not include any specific class to malware samples. The reference class can be used to refer to a particular sample but there are no related enumeration or specific classes to identify which kind of malware infections occurs in the incident. In the RFC 5901 a first attempt is made both with the fraud@type value “malware distribution” and also with the relative class “included malware” and the subclass data, the “FilesDownloaded” and “WindowsRegistryKeyModified” class. Considering the importance and the volume of these threats in the current scenario it should be discussed :

	• improving the guidance of the current IODEF data model and related extensions;

	• implementing a high level taxonomy of malware types and leave further characterization to the interoperability with other cyber security formats.

The malware indicators should be hashes (MD5 or SHA1), the filetype and the version. As it can be noticed I do not refer to the name of the file. Naming a file can be not straightforward, where possible the name of the malware should be defined using the CARO Malware Naming Scheme, which even if not updated, is the most popular guideline among anti virus companies. In this respect, the need to a high level characterization arises to help the handler in quickly identify the threat. Moreover IODEF Fraud extension is too generic for a complete in-depth categorization of the sample and lacks of detailed information regarding behaviors and other characteristics that could be of help in response of the threat.  This effort could help in understanding the infection and can be neighborly in the foreseen integration with other cyber security exchange formats regarding malware.

Unfortunately I cannot attend the meeting but I will try to be remotely present.

Best regards,
Rossella