Context Navigation

Managed Incident Lightweight Exchange (MILE) Working Group Overview

The MILE working group is focused in two areas, data formats and transport protocols to enable the secure exchange of indicator and incident information. This wiki is intended to provide an overview of the two work areas and how the drafts in the working group fit together. Although the Data Format is supported by the transport protocols defined, they can each be used independently either with alternate transports or the transports can support other data formats. Please reference the MILE Charter ​http://datatracker.ietf.org/wg/mile/charter/ for a complete overview of the scope of work possible under the charter. Submissions of drafts within scope of the charter are welcome.

MILE is focused on enabling interoperable exchanges of incident and indicator information. We are only concerned with on-the-wire exchanges to ensure that entities using different implementations can send each other information that is interpreted exactly as intended by the sender on the receiving end of the communication. Each implementation can leverage their own formats for storing data to optimize analysis and independently evolve their analytic capabilities separate from transport exchange standards. IODEF is intentionally limited to include the most commonly exchanged data types to provide interoperability for the majority of use cases, without requiring an overly complex implementation. This lowers the barrier for interoperability between implementations. IODEF is highly extensible, allowing for groups (industry or use case focused) to select how they will extend IODEF to meet any needs that fall outside of the core data model.

IODEF has been in use since publication in 2007 with large-scale information sharing groups like the Anti-phishing work group (APWG). They target two specific use cases leveraging IODEF as defined in RFC5070 as the core data model with specific extensions for their use case needs (eCrime & anti-phishing). Members and others in the community can submit reports using IODEF and IODEF can also be used to export data in a standard format. The APWG has automated exchanges with members, providing data feeds via IODEF. The APWG has been quite successful helping to mitigate or stop eCrime and phishing, see their web site for more details! ​http://www.apwg.org

The above picture, presented at IETF 86, describes the intended scope for review of the IODEF v2.0 in development by the MILE working group participants. Several data representations from the anti-phishing extension, RFC5901, were pulled foward into RFC5070-bis as they can be used for multiple use cases in addition the anti-phishing. The goal was to include the most commonly exchanged data types so that they could be represented int he core data model and extensions could be used for use case or industry specific efforts. Windows registry keys, HTTP Header information, domain data were among the data types that were common in exchanges at the time they were pulled forward. The IODEF revision work will run through January with two week poll periods to elicit feedback on open items identified by the working group through November. Draft versions will periodically be published for review and comments by the community.

The sections at the bottom of the picture demonstrate the ability to include other XML schemas into the IODEF data model through the Structured Cybersecurity Information draft. This capability is in addition to the extensions that can be made directly off the IODEF data model through the AdditionalData or Record classes, as was done for the Anti-Phishing extension, RFC5901, and the Anti-Fraud extension, RFC5941.

Please contribute to the review to help shape the emerging version to meet your use case needs!
Defined Extensions:

Extensions to the IODEF-Document Class for Reporting Phishing: RFC5901

Background on the IODEF Data Model

Organizations require help from other parties to mitigate malicious activity targeting
their network and to gain insight into potential threats. This coordination might entail
working with an ISP to filter attack traffic, contacting a remote site to take down a botnetwork,
or sharing watch-lists of known malicious IP addresses in a consortium.

IODEF is a format for representing computer security information commonly
exchanged between Computer Security Incident Response Teams (CSIRTs). It provides
an XML representation for conveying incident information administrative domains between
parties that have an operational responsibility of remediation or a watch-and-warning over a
defined constituency. The data model encodes information about hosts, networks, and the
services running on these systems; attack and associated forensic evidence; impact of the
activity; and limited approaches for documenting workflow.

The overriding purpose of IODEF is to enhance the operational capabilities of
CSIRTs. Community adoption of IODEF provides an improved ability to resolve
incidents and convey situational awareness by simplifying collaboration and data sharing.
This structured format provided by IODEF allows for:

increased automation in processing of indicator and incident data, since the resources of security analysts to parse free-form textual documents will be reduced;

decreased effort in normalizing similar data (even when highly structured) from different sources; and

a common format on which to build interoperable tools for incident handling and subsequent analysis, specifically when data comes from multiple constituencies.

Coordination among CSIRTs is not strictly a technical problem. There are
numerous procedural, trust, and legal considerations that might prevent an organization
from sharing information. IODEF does not attempt to address these. However,
operational implementations of IODEF will need to consider this broader context. The
ISF describes the larger framework to enable the exchange of data at the appropriate
assurance levels (identity, federations, secure access via PKI, etc.), using a common data
format (IODEF), over the appropriate exchange mechanism (push or pull).

The IODEF data model is a data representation that provides a framework for
sharing information commonly exchanged by organizations or CSIRTs about computer
security incidents or indicators of compromise. A number of considerations were made
in the design of the data model:

The data model serves as a format for the exchange of data. Therefore, its specific representation is not the optimal representation for on- disk storage, long-term archiving, or in-memory processing. This design criterion allows for media independence.

As there is no precise, widely agreed upon definition of an "incident", the data model does not attempt to dictate one through its implementation. Rather, a broad understanding is assumed in IODEF that is flexible enough to encompass most operators for both full incident descriptions and subsets of data that may be limited to indicators of compromise.

Describing an incident or indicators of compromise for all definitions would require an extremely complex data model. Therefore, the IODEF only intends to be a framework to convey commonly exchanged incident information. It ensures that there are ample mechanisms for extensibility to support organization-specific information, and techniques to reference information kept outside of the explicit data model. This design goal is directly aligned with the ISF requirement of a hierarchical taxonomy that supports extensions, both standardized and private extension types.

The domain of security analysis is not fully standardized and must rely on free-form textual descriptions. The IODEF attempts to strike a balance between supporting this free-form content, while still allowing automated processing of incident and indicator information.

Current Extensions

A draft document - IODEF-extension for structured cybersecurity information (SCI)
(​https://datatracker.ietf.org/doc/draft-ietf-mile-sci/) – is in the final stages before publication as an RFC to extend IODEF to
facilitate enriched cybersecurity information exchange among cybersecurity entities. It
provides the capability of embedding structured information, such as identifier- and XML-based
information defined in other schemas, in such a way that will facilitate automation
and system-system interaction. The SCI draft establishes an IANA
table to incorporate complementary data model schemas (or taxonomies) using a
consistent method grouping the extensions into high level categories such as AttackPattern,
Vulnerabilities, Platforms, EventReport, etc. to include malware samples, vulnerability
reports, and other helpful information.

Industry-specific information may be included directly via the IODEF extension
capability or may be embedded in IODEF via the SCI draft extension capabilities. The
extensions needed to support specific use cases, such as anti-phishing, or
industries may be includes via a direct extension to IODEF or through the SCI extension mechanism.
Relationships between existing standards can be made by
extending IODEF to include or reference data formats since the IODEF standard was designed to be flexible and extensible. Examples might include the Common Alerting Protocol (CAP) data format from OASIS or the Abuse Reporting Format (ARF) defined by the IETF's MARF working group for mail abuse use cases.

RFC6684 provides a template for defining new IODEF extensions within the MILE working group.

The following picture describes some of the use cases for the RID and ROLIE transport options. Both of these transports can exchange IODEF and it's extensions or other data formats. As mentioned previously, the data formats can be exchanged via other means, such as secure email as the data formats and transports are defined separately. If another transport is used, implementers may wish to leverage the object security options to consistently encrypt and digitally sign IODEF documents as described in RFC6545, Section 9.1 without using the rest of the RID standard.

The working group has discussed the use of XMPP to provide publish/subscribe capabilities, leveraging a protocol that provides this functionality as well as federation capabilities. XMPP can be used for the transport of formatted data and an extension to XMPP has been created, but has not been formalized in MILE yet. If there is sufficient interest, it is possible to standardize this transport. As it deals with message exchange as opposed to access to stable resources, XMPP would be most useful in peer to peer models, as RFC6546.

Peer-to-Peer or Hub-and-Spoke Sharing Models

Real-time Inter-network Defense (RID) defined in RFC6545 with a transport binding using HTTP/TLS defined in RFC6546 is preferred for peer-to-peer models (e.g., among pre-introduced CSIRTs operating under a consortium agreement) where higher levels of security and privacy are required. This transport method enables increased automation over embedding the IODEF document in a secured email for instance. RID was designed to transport IODEF cyber security
information (and any appropriate extensions), and is flexible to exchange other
schemas/data models either embedded in IODEF or independent of IODEF. There is a
standards method to extend the acceptable uses of RID Through an IANA table defined
in RFC6545.

RID and RID Transport allow options for data encryption at the data or object level using PKI, authentication and
authorization at the data and transport levels via PKI, as well as authentication at the
data level via XML digital signatures. While this can be managed on a peer-by-peer
basis, the use of federations is necessary to scale the relationships. RID can be used in a hub-and-spoke model, but does require the establishment of trusted relationships between RID endpoints.

Repository Access Sharing Models (Internal or External Exchanges)

File servers and applications like SharePoint are very helpful in
to enable portal access for information sharing groups. However, for the emerging
needs of a trusted broker to widely disseminate information a well-defined repository
access structure is preferred. The MILE working group in the IETF is developing such a
standard that will generically support any defined schema, with IODEF as the core
supported schema to prove interoperability. The draft is open for comments and is
called, Resource Oriented Lightweight Indicator Exchange
(​https://datatracker.ietf.org/doc/draft-field-mile-rolie/). The repository access method
described could allow for low to medium assurance cyber exchanges where low
exchanges may allow for full public access to information. Higher levels of assurance
can be supported through federated access management to authenticate and authorize
users as well as to secure transport. This transport method may also be used internal to an enterprise environment to exchange data between products in a trusted environment, allowing for easier search access through a RESTful interface.

Although data at the object level could be
encrypted via this exchange mechanism, additional means to enable this are required.
Higher assurance exchanges may require peer-to-peer models where the data can be
better protected at the data (object-level) and transport levels. While the peer-to-peer models
do not scale like the repository models, they may be very useful in brokered
relationships where one user or SME wants to share data for analysis that may be
obscured, anonymized, and then disseminated via a repository sharing model.

Protecting data at the object-level is described in RFC6545 Section 9.1 using W3C XML encryption and digital signatures applied in a standard way for interoperability between end points.

Comparison Table of Transport Protocol Options

Protocol

Why Use This Protocol

Architecture Model

Security Features

Additional Features and Information

Status

RID + HTTP/TLS

I am interested in tight security between trusted peers. I may also be concerned that my data will be intercepted. We want to prevent session monitoring or passive surveillance of our information.

My data isn’t super sensitive or is stored on a protected network. Easy access with a browser via a RESTful interface is preferred. I want my users to have a low barrier to entry for sharing data. I may or may not be interested in federated identity and access management.

Repository model, allows for authentication of clients if desired. RESTful model. May be used for repository access to replace portals or for product interfaces on internal networks.

Limited to identity and access management, as well as TLS 1.1 for session encryption. Authentication of server supported. Client authentication supported, not required for users depending on usage requirements.

I am very interested in using an efficient publish/subscribe mechanism with a tested protocol that has had wide deployment and interoperability tested. I am also interested in federated identity and access management.

This option stands apart for it's inherent design of a Federated model allowing for federated identity and access management. Hub-and-spoke is also possible with this option and can leverage the publish/subscribe capabilities that are part of the XMPP protocol, providing an alternate method (push) than the ROLIE draft. Peer-to-peer is also possible with XMPP.

Intermediate nodes will be able to see data that is not encrypted at object level. POSH draft will assist with security improvements. Could use object security from RID (RFC6545) or the developing draft on object security for XMPP by Matt Miller.

Publish/subscribe built into protocol

Good idea without a draft; XMPP transports XML natively, but may need some guidelines / IODEF extension work. Numerous interoperable implementations and large-scale deployment of XMPP.