¶ 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.
An overview video describing the MILE work can be found on the MILE Charter page, linked above. The presentation used in the video is provided at http://trac.tools.ietf.org/wg/mile/trac/attachment/wiki/WikiStart/MILE-Overview-073013.pptx
¶ Interoperability is Critical!
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.
See the list of interopable implementations for IODEF & RID, many are open source! http://siis.realmv6.org/implementations/
- IODEF is supported in several commercial products in addition to open source tools.
- There are two open source implementations of RID that have been tested for interoperability, with a third open source implementation to be added soon.
- IODEF and RID are the key information sharing standards in the Multi-national Alliance for Collaborative Cyber Situtational Awareness (MACCSA) information sharing framework.
- 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
¶ Data Formats:
RFC5070 Incident Object Description Exchange Format v1.0 https://datatracker.ietf.org/doc/rfc5070/
RFC5070-bis Incident Object Description Exchange Format (will be v2.0) publication target: January 2014 https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/
IODEF Usage Guidance http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/
IODEF Enumeration Reference Format http://tools.ietf.org/id/draft-montville-mile-enum-reference-format-02.txt
Scope of IODEF v2.0:
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
Sharing Transaction Fraud Data: RFC5941
Structured Cybersecurity Information Extension for IODEF: https://datatracker.ietf.org/doc/draft-ietf-mile-sci/
¶ 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.
¶ Transport Protocols
RFC6545 Real-time Inter-network Defense (RID) defines the base protocol
RFC6546 RID over HTTP/TLS is optimized for peer-to-peer models of operation among closed consortia of CSIRTs.
Resource Oriented Lightweight Indicator Exchange (ROLIE) https://datatracker.ietf.org/doc/draft-field-mile-rolie/ is designed for sharing of incident data from a repository.
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. | Peer-to-peer, tightly coupled access management/ authentication | Object level security supported through XML encryption & digital signatures. TLS 1.1 required for transport. Mutual TLS authentication must be supported in code. | Could use PKI federation capabilities within a consortium or cross federate with PKI | Published (RFC6545 + RFC6546), 3 interoperable implementations |
| ROLIE draft | 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. | Search capability, putting burden on client for search (appropriately). Clients only need a browser, low barrier to usage. | draft-field-mile-rolie-02; adopted as WG item. Need to gauge interest, need comments on content to mile@…. |
| XMPP | 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. |
The content of this page was last updated on 2014-01-13. It was migrated from the old Trac wiki on 2023-01-09.