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

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
     2.3.  Objects . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.3.1.  Org . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.3.2.  Orgc  . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     3.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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




Dulaunoy & Iklody         Expires April 4, 2017                 [Page 2]

Internet-Draft              MISP core format                October 2016


   an implementation to represent the MISP format in another data
   structure.

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.






Dulaunoy & Iklody         Expires April 4, 2017                 [Page 3]

Internet-Draft              MISP core format                October 2016


2.2.1.5.  threat_level_id

   threat_level_id represents the threat level.

   0:
      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, or one of the
   attributes within 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.





Dulaunoy & Iklody         Expires April 4, 2017                 [Page 4]

Internet-Draft              MISP core format                October 2016


   publish_timestamp is represented as a JSON string. publish_timestamp
   MUST be present.

2.2.1.9.  org_id

   org_id represents a human-readable identifier referencing an Org
   object 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 a human-readable identifier referencing an Orgc
   object of the organization which created the event.

   The orgc_id and Orc object MUST be preserved for any updates or
   transfer of the same event.

   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.

2.3.  Objects

2.3.1.  Org

   An Org object is composed of an uuid, name and id.

   The uuid represents the Universally Unique IDentifier (UUID)
   [RFC4122] of the organization.  The organization UUID is globally
   assigned to an organization and SHALL be kept overtime.

   The name is a readable description of the organization and SHOULD be
   present.  The id is a human-readable identifier generated by the
   instance and used as reference in the event.

   uuid, name and id are represented as a JSON string. uuid, name and id
   MUST be present.




Dulaunoy & Iklody         Expires April 4, 2017                 [Page 5]

Internet-Draft              MISP core format                October 2016


2.3.1.1.  Sample Org Object

          "Org": {
                  "id": "2",
                  "name": "CIRCL",
                  "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f"
                 }

2.3.2.  Orgc

   An Orgc object is composed of an uuid, name and id.

   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.  The organization UUID is globally assigned to an organization
   and SHALL be kept overtime.

   The name is a readable description of the organization and SHOULD be
   present.  The id is a human-readable identifier generated by the
   instance and used as reference in the event.

   uuid, name and id are represented as a JSON string. uuid, name and id
   MUST 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>.

3.2.  Informative References

   [MISP-P]   MISP, , "MISP Project - Malware Information Sharing
              Platform and Threat Sharing", <https://github.com/MISP>.




Dulaunoy & Iklody         Expires April 4, 2017                 [Page 6]

Internet-Draft              MISP core format                October 2016


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 7]