|
|
|
|
|
|
|
|
|
|
|
|
|
|
Network Working Group A. Dulaunoy |
|
|
Internet-Draft A. Iklody |
|
|
Intended status: Informational CIRCL |
|
|
Expires: April 4, 2017 October 1, 2016 |
|
|
|
|
|
|
|
|
MISP core format |
|
|
draft-dulaunoy-misp-core-format |
|
|
|
|
|
Abstract |
|
|
|
|
|
This document describes the MISP core format used to exchange |
|
|
indicators and threat information between MISP (Malware Information |
|
|
and threat Sharing Platform) instances. The JSON format includes the |
|
|
overall structure along with the semantic associated for each |
|
|
respective key. The format is described to support other |
|
|
implementations which reuse the format and ensuring an |
|
|
interoperability with existing MISP [MISP-P] software and other |
|
|
Threat Intelligence Platforms. |
|
|
|
|
|
Status of This Memo |
|
|
|
|
|
This Internet-Draft is submitted in full conformance with the |
|
|
provisions of BCP 78 and BCP 79. |
|
|
|
|
|
Internet-Drafts are working documents of the Internet Engineering |
|
|
Task Force (IETF). Note that other groups may also distribute |
|
|
working documents as Internet-Drafts. The list of current Internet- |
|
|
Drafts is at http://datatracker.ietf.org/drafts/current/. |
|
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six months |
|
|
and may be updated, replaced, or obsoleted by other documents at any |
|
|
time. It is inappropriate to use Internet-Drafts as reference |
|
|
material or to cite them other than as "work in progress." |
|
|
|
|
|
This Internet-Draft will expire on April 4, 2017. |
|
|
|
|
|
Copyright Notice |
|
|
|
|
|
Copyright (c) 2016 IETF Trust and the persons identified as the |
|
|
document authors. All rights reserved. |
|
|
|
|
|
This document is subject to BCP 78 and the IETF Trust's Legal |
|
|
Provisions Relating to IETF Documents |
|
|
(http://trustee.ietf.org/license-info) in effect on the date of |
|
|
publication of this document. Please review these documents |
|
|
carefully, as they describe your rights and restrictions with respect |
|
|
to this document. Code Components extracted from this document must |
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy & Iklody Expires April 4, 2017 [Page 1] |
|
|
|
|
|
Internet-Draft MISP core format October 2016 |
|
|
|
|
|
|
|
|
include Simplified BSD License text as described in Section 4.e of |
|
|
the Trust Legal Provisions and are provided without warranty as |
|
|
described in the Simplified BSD License. |
|
|
|
|
|
Table of Contents |
|
|
|
|
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 |
|
|
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 |
|
|
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 |
|
|
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 |
|
|
2.2. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
|
|
2.2.1. Event Attributes . . . . . . . . . . . . . . . . . . 3 |
|
|
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
|
|
3.1. Normative References . . . . . . . . . . . . . . . . . . 5 |
|
|
3.2. Informative References . . . . . . . . . . . . . . . . . 6 |
|
|
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 |
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 |
|
|
|
|
|
1. Introduction |
|
|
|
|
|
Sharing threat information became a fundamental requirements in the |
|
|
Internet, security and intelligence community at large. Threat |
|
|
information can include indicators of compromise, malicious file |
|
|
indicators, financial fraud indicators or even detailed information |
|
|
about a threat actor. MISP started as an open source project in late |
|
|
2011 and the MISP format started to be widely used as an exchange |
|
|
format within the community in the past years. The aim of this |
|
|
document is to describe the specification and the MISP core format. |
|
|
|
|
|
1.1. Conventions and Terminology |
|
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
|
|
document are to be interpreted as described in RFC 2119 [RFC2119]. |
|
|
|
|
|
2. Format |
|
|
|
|
|
2.1. Overview |
|
|
|
|
|
The MISP core format is in the JSON [RFC4627] format. In MISP, an |
|
|
event is composed of a single JSON object. |
|
|
|
|
|
A capitalized key (like Event, Org) represent a data model and a non- |
|
|
capitalized key is just an attribute. This nomenclature can support |
|
|
an implementation to represent the MISP format in another data |
|
|
structure. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy & Iklody Expires April 4, 2017 [Page 2] |
|
|
|
|
|
Internet-Draft MISP core format October 2016 |
|
|
|
|
|
|
|
|
2.2. Event |
|
|
|
|
|
An event is a simple meta structure scheme where attributes and meta- |
|
|
data are embedded to compose a coherent set of indicators. An event |
|
|
can be composed from an incident, a security analysis report or a |
|
|
specific threat actor analysis. The meaning of an event only depends |
|
|
of the information embedded in the event. |
|
|
|
|
|
2.2.1. Event Attributes |
|
|
|
|
|
2.2.1.1. uuid |
|
|
|
|
|
uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of |
|
|
the event. The uuid MUST be preserved for any updates or transfer of |
|
|
the same event. UUID version 4 is RECOMMENDED when assigning it to a |
|
|
new event. |
|
|
|
|
|
uuid is represented as a JSON string. uuid MUST be present. |
|
|
|
|
|
2.2.1.2. id |
|
|
|
|
|
id represents the human-readable identifier associated to the event |
|
|
for a specific MISP instance. |
|
|
|
|
|
id is represented as a JSON string. id SHALL be present. |
|
|
|
|
|
2.2.1.3. published |
|
|
|
|
|
published represents the event publication state. If the event was |
|
|
published, the published value MUST be true. In any other |
|
|
publication state, the published value MUST be false. |
|
|
|
|
|
published is represented as a JSON boolean. published MUST be |
|
|
present. |
|
|
|
|
|
2.2.1.4. info |
|
|
|
|
|
info represents the information field of the event. info a free-text |
|
|
value to provide a human-readable summary of the event. info SHOULD |
|
|
NOT be bigger than 256 characters. |
|
|
|
|
|
info is represented as a JSON string. info MUST be present. |
|
|
|
|
|
2.2.1.5. threat_level_id |
|
|
|
|
|
threat_level_id represents the threat level. |
|
|
|
|
|
0: |
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy & Iklody Expires April 4, 2017 [Page 3] |
|
|
|
|
|
Internet-Draft MISP core format October 2016 |
|
|
|
|
|
|
|
|
Undefined |
|
|
|
|
|
1: |
|
|
Low |
|
|
|
|
|
2: |
|
|
Medium |
|
|
|
|
|
3: |
|
|
High |
|
|
|
|
|
If a higher granularity is required, a MISP taxonomy applied as a Tag |
|
|
SHOULD be preferred. |
|
|
|
|
|
threat_level_id is represented as a JSON string. threat_level_id |
|
|
SHALL be present. |
|
|
|
|
|
2.2.1.6. date |
|
|
|
|
|
date represents a reference date to the event in year-month-date |
|
|
format. For a more precise time reference, the timestamp key is |
|
|
used. |
|
|
|
|
|
date is represented as a JSON string. |
|
|
|
|
|
2.2.1.7. timestamp |
|
|
|
|
|
timestamp represents a reference time when the event was created. |
|
|
timestamp is expressed in seconds (decimal) since 1st of January 1970 |
|
|
(Unix timestamp). The time zone MUST be UTC. |
|
|
|
|
|
timestamp is represented as a JSON string. timestamp MUST be present. |
|
|
|
|
|
2.2.1.8. publish_timestamp |
|
|
|
|
|
publish_timestamp represents a reference time when the event was |
|
|
published. published_timestamp is expressed in seconds (decimal) |
|
|
since 1st of January 1970 (Unix timestamp). At each publication of |
|
|
an event, publish_timestamp MUST be updated. The time zone MUST be |
|
|
UTC. |
|
|
|
|
|
publish_timestamp is represented as a JSON string. publish_timestamp |
|
|
MUST be present. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy & Iklody Expires April 4, 2017 [Page 4] |
|
|
|
|
|
Internet-Draft MISP core format October 2016 |
|
|
|
|
|
|
|
|
2.2.1.9. org_id |
|
|
|
|
|
org_id represents the Universally Unique IDentifier (UUID) [RFC4122] |
|
|
of the organization which generated the event. The org_id MUST be |
|
|
updated when the event is generated by a new instance. |
|
|
|
|
|
org_id is represented as a JSON string. org_id MUST be present. |
|
|
|
|
|
2.2.1.10. orgc_id |
|
|
|
|
|
orgc_id represents the Universally Unique IDentifier (UUID) [RFC4122] |
|
|
of the organization which created the event. The orgc_id MUST be |
|
|
preserved for any updates or transfer of the same event. UUID |
|
|
version 4 is RECOMMENDED when assigning it to a new event. orgc_id |
|
|
is globally assigned to an organization and SHALL be kept overtime. |
|
|
|
|
|
orgc_id is represented as a JSON string. orgc_id MUST be present. |
|
|
|
|
|
2.2.1.11. attribute_count |
|
|
|
|
|
attribute_count represents the number of attributes in the event. |
|
|
attribute_count is expressed in decimal. |
|
|
|
|
|
attribute_count is represented as a JSON string. attribute_count |
|
|
SHALL be present. |
|
|
|
|
|
3. References |
|
|
|
|
|
3.1. Normative References |
|
|
|
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
|
|
Requirement Levels", BCP 14, RFC 2119, |
|
|
DOI 10.17487/RFC2119, March 1997, |
|
|
<http://www.rfc-editor.org/info/rfc2119>. |
|
|
|
|
|
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally |
|
|
Unique IDentifier (UUID) URN Namespace", RFC 4122, |
|
|
DOI 10.17487/RFC4122, July 2005, |
|
|
<http://www.rfc-editor.org/info/rfc4122>. |
|
|
|
|
|
[RFC4627] Crockford, D., "The application/json Media Type for |
|
|
JavaScript Object Notation (JSON)", RFC 4627, |
|
|
DOI 10.17487/RFC4627, July 2006, |
|
|
<http://www.rfc-editor.org/info/rfc4627>. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy & Iklody Expires April 4, 2017 [Page 5] |
|
|
|
|
|
Internet-Draft MISP core format October 2016 |
|
|
|
|
|
|
|
|
3.2. Informative References |
|
|
|
|
|
[MISP-P] MISP, , "MISP Project - Malware Information Sharing |
|
|
Platform and Threat Sharing", <https://github.com/MISP>. |
|
|
|
|
|
Appendix A. Acknowledgements |
|
|
|
|
|
The authors wish to thank all the MISP community to support the |
|
|
creation of open standards in threat intelligence sharing. |
|
|
|
|
|
Authors' Addresses |
|
|
|
|
|
Alexandre Dulaunoy |
|
|
Computer Incident Response Center Luxembourg |
|
|
41, avenue de la gare |
|
|
Luxembourg L-1611 |
|
|
Luxembourg |
|
|
|
|
|
Phone: +352 247 88444 |
|
|
Email: alexandre.dulaunoy@circl.lu |
|
|
|
|
|
|
|
|
Andras Iklody |
|
|
Computer Incident Response Center Luxembourg |
|
|
41, avenue de la gare |
|
|
Luxembourg L-1611 |
|
|
Luxembourg |
|
|
|
|
|
Phone: +352 247 88444 |
|
|
Email: andras.iklody@circl.lu |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy & Iklody Expires April 4, 2017 [Page 6]
|
|
|
|
