misp-rfc/misp-core-format/raw.md.txt

337 lines
10 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters!

This file contains invisible Unicode characters that may be processed differently from what appears below. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to reveal hidden characters.

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]