9. Security Considerations
The IODEF data model does not directly introduce security or privacy
issues. However, as the data encoded by the IODEF might be
considered sensitive by the parties exchanging it or by those
described by it, care needs to be taken to ensure appropriate
handling during the document construction, exchange, processing,
archiving, subsequent retrieval, and analysis.
The underlying messaging format and protocol used to exchange
instances of the IODEF MUST provide appropriate guarantees of
confidentiality, integrity, and authenticity. The use of a
standardized security protocol is encouraged. The Real-time Inter-
network Defense (RID) protocol [RFC6545] and its associated transport
binding IODEF/RID over HTTP/TLS [RFC6546] provide such security.
An IODEF implementation may act on the data in the document. These
actions might be explicitly requested in the document or the result
of analytical logic that triggered on data in the document. For this
reason, care must be taken by IODEF implementations to properly
authenticate the sender and receiver of the document. The sender
needs confidence that sensitive information and timely requests for
action are sent to the correct recipient. The recipient may
interpret the contents of the document differently based on who sent
it or vary actions based on the sender. While the sender of the
document may explicitly convey confidence in the data in a granular
way using the Confidence class, the recipient is free to ignore or
refine this information to make its own assessment. Ambiguous
Confidence elements (where it is unclear to which of a set of other
elements the Confidence element relates) in a document MUST be
ignored by the recipient.
Certain classes may require out-of-band coordination to agree upon
their semantics (e.g., Confidence@rating="low" or DefinedCOA). This
coordination MUST occur prior to operational data exchange to prevent
the incorrect interpretation of these select data elements. When
parsing these data elements, implementations should validate, when
possible, that they conform to the agreed upon semantics. These
semantics may need to be periodically reevaluated.
Executable content of various forms could be embedded into the IODEF
document directly or through an extension. Implementation MUST
handle this content with care to prevent unintentional automated
execution. The following classes are explicitly intended to
represent content that might be executable:
o All classes of type iodef:ExtensionType and the RecordPattern
class can represent arbitrary binary strings such as legitimate
software programs or malware.
o The EmailMessage and EmailBody classes can represent email
attachments that can contain arbitrary content.
o The DetectionPattern class could specify a machine-readable
configuration that directs the execution of the corresponding
Per Section 4.3, IODEF implementations will need to periodically
consult the IANA registries specified in Section 10.2 to discover
newly registered enumerated attribute values. These implementations
MUST communicate with IANA in a way that ensures the integrity of the
values and the authenticity of the source. HTTPS over TLS
[RFC2818][RFC5246] provides such security.
The IODEF contains numerous fields that are identifiers that could be
linked to an individual or organization. IODEF documents may contain
sensitive information about these identified parties; repeated
document exchanges about the same and related parties may enable the
correlation of data about them. Likewise, a party may report on
another to a third party without their knowledge.
When creating an IODEF document, careful consideration must be given
to what information is shared. Personal identifiers and attributable
sensitive information should only be shared when necessary.
When exchanging documents, transport security MUST provide document-
level confidentiality. XML element-level confidentiality can also be
provided by using [W3C.XMLENC].
In order to suggest data processing and handling guidelines of the
encoded information, the IODEF allows a document sender to convey a
instances of this attribute allow different data elements of the
document to be covered by dissimilar policies. While flexible, it
must be stressed that this approach only serves as a guideline from
the sender, as the recipient is free to ignore it.
Although outside of the scope of an IODEF implementation, the
contents of IODEF documents and any derived analysis should be
archived with appropriate confidentiality controls. Likewise, access
to retrieve and analyze this data should be restricted to authorized
10. IANA Considerations
This document registers a namespace, an XML schema, and a number of
registries that map to enumerated values defined in the data model.
It also defines an Expert Review process for IODEF-related XML
10.1. Namespace and Schema
This document uses URNs to describe an XML namespace and schema
conforming to a registry mechanism described in [RFC3688].
Registration for the IODEF namespace:
o URI: urn:ietf:params:xml:ns:iodef-2.0
o Registrant Contact: See the author in the "Author's Address"
section of this document.
o XML: None. Namespace URIs do not represent an XML specification.
Registration for the IODEF XML schema:
o URI: urn:ietf:params:xml:schema:iodef-2.0
o Registrant Contact: See the first author of the "Author's Address"
section of this document.
o XML: See Section 8 of this document.
10.2. Enumerated Value Registries
This document creates 34 identically structured registries to be
managed by IANA:
o Name of the parent registry: "Incident Object Description Exchange
Format v2 (IODEF)"
o URL of the registry: <http://www.iana.org/assignments/iodef2>
o Namespace format: A registry entry consists of:
* Value. A value for a given IODEF attribute. It MUST conform
to the formatting specified by the IODEF ENUM data type which
is implemented as an "xs:NMTOKEN" type per Section 3.3.4 of
[W3C.SCHEMA.DTYPES]. The value SHOULD conform to the
convention specified in Section 5.2.
* Description. A short description of the enumerated value.
* Reference. An optional list of URIs to further describe the
o Allocation policy: Expert Review per [RFC5226]. This reviewer
will ensure that the requested registry entry conforms to the
prescribed formatting. The reviewer will also ensure that the
entry is an appropriate value for the attribute per the
information model (Section 3).
The registries to be created are named in the "Registry Name" column
of Table 1. Each registry is initially populated with values and
descriptions that come from an attribute specified in the IODEF
schema (Section 8) whose description is found in a sub-section of the
information model (Section 3). The initial values for the Value and
Description fields of a given registry are listed in the "IV (Value)"
and "IV (Desc.)" columns, respectively. The "IV (Value)" points to a
given schema type per Section 8. Each enumerated value in the schema
gets a corresponding entry in a given registry. The "IV (Desc.)"
points to a section in the text of this document that describes each
enumerated value. The initial value of the Reference field of every
registry entry described below should be this document.