mirror of https://github.com/MISP/misp-rfc
337 lines
10 KiB
Plaintext
337 lines
10 KiB
Plaintext
|
||
|
||
|
||
|
||
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 ISO 8601 format
|
||
(date only: YYYY-MM-DD). This date corresponds to the date the event
|
||
occured, which may be in the past.
|
||
|
||
date is represented as a JSON string.
|
||
|
||
2.2.1.7. timestamp
|
||
|
||
timestamp represents a reference time when the event was created, or
|
||
last updated/edited on the instance. 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 on the instance. 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]
|