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.
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 https://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 February 9, 2019.
Copyright (c) 2018 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 (https://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 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.
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 [MISP-P] 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.
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].
The MISP core format is in the JSON [RFC8259] 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-capitalised key is just an attribute. This nomenclature can support an implementation to represent the MISP format in another data structure.
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.
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.
id represents the human-readable identifier associated to the event for a specific MISP instance. A human-readable identifier MUST be represented as an unsigned integer.
+
id is represented as a JSON string. id SHALL be present.
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.
info represents the information field of the event. info is a free-text value to provide a human-readable summary of the event. info SHOULD NOT be bigger than 256 characters and SHOULD NOT include new-lines.
+
info is represented as a JSON string. info MUST be present.
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 occurred, which may be in the past.
+
date is represented as a JSON string. date MUST be present.
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.
publishtimestamp represents a reference time when the event was published on the instance. publishedtimestamp is expressed in seconds (decimal) since 1st of January 1970 (Unix timestamp). At each publication of an event, publishtimestamp MUST be updated. The time zone MUST be UTC. If the publishedtimestamp is present and the published flag is set to false, the publishtimestamp represents the previous publication timestamp. If the event was never published, the publishedtimestamp MUST be set to 0.
+
publishtimestamp is represented as a JSON string. publishtimestamp MUST be present.
org_id represents a human-readable identifier referencing an Org object of the organisation which generated the event. A human-readable identifier MUST be represented as an unsigned integer.
+
The org_id MUST be updated when the event is generated by a new instance.
+
orgid is represented as a JSON string. orgid MUST be present.
distribution represents the basic distribution rules of the event. The system must adhere to the distribution setting for access control and for dissemination of the event.
+
distribution is represented by a JSON string. distribution MUST be present and be one of the following options:
sharing_group_id represents a human-readable identifier referencing a Sharing Group object that defines the distribution of the event, if distribution level "4" is set. A human-readable identifier MUST be represented as an unsigned integer.
+
sharing_group_id is represented by a JSON string and SHOULD be present. If a distribution level other than "4" is chosen the sharing_group_id MUST be set to "0".
extends_uuid represents which event is extended by this event. The extends_uuid is described as a Universally Unique IDentifier (UUID) [RFC4122] with the UUID of the extended event.
+
extends_uuid is represented as a JSON string. extends_uuid SHOULD be present.
An Org object is composed of an uuid, name and id.
+
The uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the organisation. The organisation UUID is globally assigned to an organisation and SHALL be kept overtime.
+
The name is a readable description of the organisation and SHOULD be present. The id is a human-readable identifier generated by the instance and used as reference in the event. A human-readable identifier MUST be represented as an unsigned integer.
+
uuid, name and id are represented as a JSON string. uuid, name and id MUST be present.
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 organisation UUID is globally assigned to an organisation and SHALL be kept overtime.
+
The name is a readable description of the organisation and SHOULD be present. The id is a human-readable identifier generated by the instance and used as reference in the event. A human-readable identifier MUST be represented as an unsigned integer.
+
uuid, name and id are represented as a JSON string. uuid, name and id MUST be present.
Attributes are used to describe the indicators and contextual data of an event. The main information contained in an attribute is made up of a category-type-value triplet, where the category and type give meaning and context to the value. Through the various category-type combinations a wide range of information can be conveyed.
+
A MISP document MUST at least includes category-type-value triplet described in section "Attribute Attributes".
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.
id represents the human-readable identifier associated to the event for a specific MISP instance. A human-readable identifier MUST be represented as an unsigned integer.
+
id is represented as a JSON string. id SHALL be present.
type represents the means through which an attribute tries to describe the intent of the attribute creator, using a list of pre-defined attribute types.
+
type is represented as a JSON string. type MUST be present and it MUST be a valid selection for the chosen category. The list of valid category-type combinations is as follows:
Attributes are based on the usage within their different communities. Attributes can be extended on a regular basis and this reference document is updated accordingly.
category represents the intent of what the attribute is describing as selected by the attribute creator, using a list of pre-defined attribute categories.
+
category is represented as a JSON string. category MUST be present and it MUST be a valid selection for the chosen type. The list of valid category-type combinations is mentioned above.
to_ids represents whether the attribute is meant to be actionable. Actionable defined attributes that can be used in automated processes as a pattern for detection in Local or Network Intrusion Detection System, log analysis tools or even filtering mechanisms.
+
to_ids is represented as a JSON boolean. to_ids MUST be present.
event_id represents a human-readable identifier referencing the Event object that the attribute belongs to. A human-readable identifier MUST be represented as an unsigned integer.
+
The event_id SHOULD be updated when the event is imported to reflect the newly created event's id on the instance.
+
event_id is represented as a JSON string. event_id MUST be present.
distribution represents the basic distribution rules of the attribute. The system must adhere to the distribution setting for access control and for dissemination of the attribute.
+
distribution is represented by a JSON string. distribution MUST be present and be one of the following options:
timestamp represents a reference time when the attribute was created or last modified. 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.
sharing_group_id represents a human-readable identifier referencing a Sharing Group object that defines the distribution of the attribute, if distribution level "4" is set. A human-readable identifier MUST be represented as an unsigned integer.
+
sharing_group_id is represented by a JSON string and SHOULD be present. If a distribution level other than "4" is chosen the sharing_group_id MUST be set to "0".
deleted represents a setting that allows attributes to be revoked. Revoked attributes are not actionable and exist merely to inform other instances of a revocation.
+
deleted is represented by a JSON boolean. deleted MUST be present.
data contains the base64 encoded contents of an attachment or a malware sample. For malware samples, the sample MUST be encrypted using a password protected zip archive, with the password being "infected".
+
data is represented by a JSON string in base64 encoding. data MUST be set for attributes of type malware-sample and attachment.
RelatedAttribute is an array of attributes correlating with the current attribute. Each element in the array represents an JSON object which contains an Attribute dictionnary with the external attributes who correlate. Each Attribute MUST include the id, org_id, info and a value. Only the correlations found on the local instance are shown in RelatedAttribute.
ShadowAttribute is an array of shadow attributes that serve as proposals by third parties to alter the containing attribute. The structure of a ShadowAttribute is similar to that of an Attribute, which can be accepted or discarded by the event creator. If accepted, the original attribute containing the shadow attribute is removed and the shadow attribute is converted into an attribute.
+
Each shadow attribute that references an attribute MUST contain the containing attribute's ID in the oldid field and the event's ID in the eventid field.
firstseen represents a reference time when the attribute was first seen. firstseen is expressed as an ISO 8601 datetime up to the micro-second with time zone support.
+
firstseen is represented as a JSON string. firstseen MAY be present.
lastseen represents a reference time when the attribute was last seen. lastseen is expressed as an ISO 8601 datetime up to the micro-second with time zone support.
+
lastseen is represented as a JSON string. lastseen MAY be present.
ShadowAttributes are 3rd party created attributes that either propose to add new information to an event or modify existing information. They are not meant to be actionable until the event creator accepts them - at which point they will be converted into attributes or modify an existing attribute.
+
They are similar in structure to Attributes but additionally carry a reference to the creator of the ShadowAttribute as well as a revocation flag.
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.
id represents the human-readable identifier associated to the event for a specific MISP instance. human-readable identifier MUST be represented as an unsigned integer. id is represented as a JSON string. id SHALL be present.
type represents the means through which an attribute tries to describe the intent of the attribute creator, using a list of pre-defined attribute types.
+
type is represented as a JSON string. type MUST be present and it MUST be a valid selection for the chosen category. The list of valid category-type combinations is as follows:
Attributes are based on the usage within their different communities. Attributes can be extended on a regular basis and this reference document is updated accordingly.
category represents the intent of what the attribute is describing as selected by the attribute creator, using a list of pre-defined attribute categories.
+
category is represented as a JSON string. category MUST be present and it MUST be a valid selection for the chosen type. The list of valid category-type combinations is mentioned above.
to_ids represents whether the Attribute to be created if the ShadowAttribute is accepted is meant to be actionable. Actionable defined attributes that can be used in automated processes as a pattern for detection in Local or Network Intrusion Detection System, log analysis tools or even filtering mechanisms.
+
to_ids is represented as a JSON boolean. to_ids MUST be present.
old_id represents a human-readable identifier referencing the Attribute object that the ShadowAttribute belongs to. A ShadowAttribute can this way target an existing Attribute, implying that it is a proposal to modify an existing Attribute, or alternatively it can be a proposal to create a new Attribute for the containing Event.
+
The old_id SHOULD be updated when the event is imported to reflect the newly created Attribute's id on the instance. Alternatively, if the ShadowAttribute proposes the creation of a new Attribute, it should be set to 0.
+
old_id is represented as a JSON string. old_id MUST be present.
timestamp represents a reference time when the attribute was created or last modified. 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.
org_id represents a human-readable identifier referencing the proposal creator's Organisation object. A human-readable identifier MUST be represented as an unsigned integer.
+
Whilst attributes can only be created by the event creator organisation, shadow attributes can be created by third parties. org_id tracks the creator organisation.
+
org_id is represented by a JSON string and MUST be present.
proposal_to_delete is a boolean flag that sets whether the shadow attribute proposes to alter an attribute, or whether it proposes to remove it completely.
+
Accepting a shadow attribute with this flag set will remove the target attribute.
+
proposal_to_delete is a JSON boolean and it MUST be present. If proposal_to_delete is set to true, old_id MUST NOT be 0.
deleted represents a setting that allows shadow attributes to be revoked. Revoked shadow attributes only serve to inform other instances that the shadow attribute is no longer active.
+
deleted is represented by a JSON boolean. deleted SHOULD be present.
data contains the base64 encoded contents of an attachment or a malware sample. For malware samples, the sample MUST be encrypted using a password protected zip archive, with the password being "infected".
+
data is represented by a JSON string in base64 encoding. data MUST be set for shadow attributes of type malware-sample and attachment.
firstseen represents a reference time when the attribute was first seen. firstseen as an ISO 8601 datetime up to the micro-second with time zone support.
+
firstseen is represented as a JSON string. firstseen MAY be present.
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. A human-readable identifier MUST be represented as an unsigned integer.
+
uuid, name and id are represented as a JSON string. uuid, name and id MUST be present.
Objects serve as a contextual bond between a list of attributes within an event. Their main purpose is to describe more complex structures than can be described by a single attribute Each object is created using an Object Template and carries the meta-data of the template used for its creation within. Objects belong to a meta-category and are defined by a name.
+
The schema used is described by the templateuuid and templateversion fields.
+
A MISP document containing an Object MUST contain a name, a meta-category, a description, a templateuuid and a templateversion as described in the "Object Attributes" section.
uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the object. The uuid MUST be preserved for any updates or transfer of the same object. UUID version 4 is RECOMMENDED when assigning it to a new object.
id represents the human-readable identifier associated to the object for a specific MISP instance. A human-readable identifier MUST be represented as an unsigned integer.
+
id is represented as a JSON string. id SHALL be present.
meta-category represents the sub-category of objects that the given object belongs to. meta-categories are not tied to a fixed list of options but can be created on the fly.
+
meta-category is represented as a JSON string. meta-category MUST be present
uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the template used to create the object. The uuid MUST be preserved to preserve the object's association with the correct template used for creation. UUID version 4 is RECOMMENDED when assigning it to a new object.
templateversion represents a numeric incrementing version of the template used to create the object. It is used to associate the object to the correct version of the template and together with the templateuuid forms an association to the correct template type and version.
+
version is represented as a JSON string. version MUST be present.
event_id represents the human-readable identifier of the event that the object belongs to on a specific MISP instance. A human-readable identifier MUST be represented as an unsigned integer.
+
eventid is represented as a JSON string. eventid SHALL be present.
timestamp represents a reference time when the object was created or last modified. 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.
distribution represents the basic distribution rules of the object. The system must adhere to the distribution setting for access control and for dissemination of the object.
+
distribution is represented by a JSON string. distribution MUST be present and be one of the following options:
sharing_group_id represents a human-readable identifier referencing a Sharing Group object that defines the distribution of the object, if distribution level "4" is set. A human-readable identifier MUST be represented as an unsigned integer.
+
sharing_group_id is represented by a JSON string and SHOULD be present. If a distribution level other than "4" is chosen the sharing_group_id MUST be set to "0".
deleted represents a setting that allows attributes to be revoked. Revoked attributes are not actionable and exist merely to inform other instances of a revocation.
+
deleted is represented by a JSON boolean. deleted MUST be present.
Object References serve as a logical link between an Object and another referenced Object or Attribute. The relationship is categorised by an enumerated value from a fixed vocabulary.
+
The relationship_type is recommended to be taken from the MISP object relationship list [[MISP-R]] is RECOMMENDED to ensure a coherent naming of the tags
+
All Object References MUST contain an object_uuid, a referenced_uuid and a relationship type.
uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the object reference. The uuid MUST be preserved for any updates or transfer of the same object reference. UUID version 4 is RECOMMENDED when assigning it to a new object reference.
timestamp represents a reference time when the object was created or last modified. 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.
object_id represents the human-readable identifier of the object that the object reference belongs to on a specific MISP instance. A human-readable identifier MUST be represented as an unsigned integer.
+
eventid is represented as a JSON string. eventid SHALL be present.
event_id represents the human-readable identifier of the event that the object reference belongs to on a specific MISP instance. A human-readable identifier MUST be represented as an unsigned integer.
+
eventid is represented as a JSON string. eventid SHALL be present.
referenced_id represents the human-readable identifier of the object or attribute that the parent object of the object reference points to on a specific MISP instance.
+
referencedid is represented as a JSON string. referencedid MAY be present.
referenced_type represents the numeric value describing what the object reference points to, "0" representing an attribute and "1" representing an object
+
referencedtype is represented as a JSON string. referencedtype MAY be present.
relationshiptype represents the human-readable context of the relationship between an object and another object or attribute as described by the objectreference.
+
referencedtype is represented as a JSON string. relationshiptype MUST be present.
deleted represents a setting that allows object references to be revoked. Revoked object references are not actionable and exist merely to inform other instances of a revocation.
+
deleted is represented by a JSON boolean. deleted MUST be present.
object_uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the object that the given object reference belongs to. The object_uuid MUST be preserved to preserve the object reference's association with the object.
referenced_uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the object or attribute that is being referenced by the object reference. The referenced_uuid MUST be preserved to preserve the object reference's association with the object or attribute.
A tag is a simple method to classify an event with a simple string. The tag name can be freely chosen. The tag name can be also chosen from a fixed machine-tag vocabulary called MISP taxonomies[[MISP-T]]. When an event is distributed outside an organisation, the use of MISP taxonomies[[MISP-T]] is RECOMMENDED to ensure a coherent naming of the tags. A tag is represented as a JSON array where each element describes each tag associated. A tag array SHALL be at event level or attribute level. A tag element is described with a name, id, colour and exportable flag.
+
exportable represents a setting if the tag is kept local or exportable to other MISP instances. exportable is represented by a JSON boolean. id is a human-readable identifier that references the tag on the local instance. colour represents an RGB value of the tag.
+
name MUST be present. colour, id and exportable SHALL be present.
A sighting is an ascertainment which describes whether an attribute has been seen under a given set of conditions. The sighting can include the organisation who sighted the attribute or can be anonymised. Sighting is composed of a JSON array in which each element describes one singular instance of a sighting. A sighting element is a JSON object composed of the following values:
+
type MUST be present. type describes the type of a sighting. MISP allows 3 default types:
+
+
+
Sighting type
+
Description
+
+
+
+
0
+
denotes an attribute which has been seen
+
+
+
1
+
denotes an attribute which has been seen and confirmed as false-positive
+
+
+
2
+
denotes an attribute which will be expired at the time of the sighting
+
+
+
+
uuid MUST be present. uuid references the uuid of the sighted attribute.
+
datesighting MUST be present. datesighting is expressed in seconds (decimal) elapsed since 1st of January 1970 (Unix timestamp). date_sighting represents when the referenced attribute, designated by its uuid, is sighted.
+
source MAY be present. source is represented as a JSON string and represents the human-readable version of the sighting source, which can be a given piece of software (e.g. SIEM), device or a specific analytical process.
+
id, eventid and attributeid MAY be present.
+
id represents the human-readable identifier of the sighting reference which belongs to a specific MISP instance. eventid represents the human-readable identifier of the event referenced by the sighting and belongs to a specific MISP instance. attributeid represents the human-readable identifier of the attribute referenced by the sighting and belongs to a specific MISP instance.
+
orgid MAY be present along the JSON object describing the organisation. If the orgid is not present, the sighting is considered as anonymised.
+
org_id represents the human-readable identifier of the organisation which did the sighting and belongs to a specific MISP instance.
+
A human-readable identifier MUST be represented as an unsigned integer.
A galaxy is a simple method to express a large object called cluster that can be attached to MISP events. A cluster can be composed of one or more elements. Elements are expressed as key-values.
The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP core format as literally described before. The JSON Schema is used to validate MISP events at creation time or parsing.
MISP events can be shared over an HTTP repository, a file package or USB key. A manifest file is used to provide an index of MISP events allowing to only fetch the recently updated files without the need to parse each json file.
A manifest file is a simple JSON file named manifest.json in a directory where the MISP events are located. Each MISP event is a file located in the same directory with the event uuid as filename with the json extension.
+
The manifest format is a JSON object composed of a dictionary where the field is the uuid of the event.
+
Each uuid is composed of a JSON object with the following fields which came from the original event referenced by the same uuid:
+
+
+
+
info (MUST)
+
Orgc object (MUST)
+
analysis (SHALL)
+
timestamp (MUST)
+
date (MUST)
+
threatlevelid (SHALL)
+
+
+
+
In addition to the fields originating from the event, the following fields can be added:
+
+
+
+
integrity:sha256 represents the SHA256 value in hexadecimal representation of the associated MISP event file to ensure integrity of the file. (SHOULD)
+
integrity:pgp represents a detached PGP signature [RFC4880] of the associated MISP event file to ensure integrity of the file. (SHOULD)
+
+
+
+
If a detached PGP signature is used for each MISP event, a detached PGP signature is a MUST to ensure integrity of the manifest file. A detached PGP signature for a manifest file is a manifest.json.asc file containing the PGP signature.
MISP format is implemented by different software including the MISP threat sharing platform and libraries like PyMISP [MISP-P]. Implementations use the format as an export/import mechanism, staging transport format or synchronisation format as used in the MISP core platform. MISP format doesn't impose any restriction on the data representation of the format in data-structure of other implementations.
MISP events might contain sensitive or confidential information. Adequate access control and encryption measures shall be implemented to ensure the confidentiality of the MISP events.
+
Adversaries might include malicious content in MISP events and attributes. Implementation MUST consider the input of malicious inputs beside the standard threat information that might already include malicious intended inputs.
The authors wish to thank all the MISP community who are supporting the creation of open standards in threat intelligence sharing. A special thank to Nicolas Bareil for the review of the JSON Schema.
+
+
+
diff --git a/rfc/misp-standard-core.txt b/rfc/misp-standard-core.txt
new file mode 100644
index 0000000..74d45e7
--- /dev/null
+++ b/rfc/misp-standard-core.txt
@@ -0,0 +1,2912 @@
+
+
+
+
+Network Working Group A. Dulaunoy
+Internet-Draft A. Iklody
+Expires: February 9, 2019 CIRCL
+ August 8, 2018
+
+
+ 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 https://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 February 9, 2019.
+
+Copyright Notice
+
+ Copyright (c) 2018 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
+ (https://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
+ include Simplified BSD License text as described in Section 4.e of
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 1]
+
+Internet-Draft MISP core format August 2018
+
+
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
+ 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2.1. Event Attributes . . . . . . . . . . . . . . . . . . 3
+ 2.3. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.3.1. Org . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.3.2. Orgc . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 2.4. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 2.4.1. Sample Attribute Object . . . . . . . . . . . . . . . 8
+ 2.4.2. Attribute Attributes . . . . . . . . . . . . . . . . 9
+ 2.5. ShadowAttribute . . . . . . . . . . . . . . . . . . . . . 15
+ 2.5.1. Sample Attribute Object . . . . . . . . . . . . . . . 16
+ 2.5.2. ShadowAttribute Attributes . . . . . . . . . . . . . 16
+ 2.5.3. Org . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 2.6. Object . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 2.6.1. Sample Object . . . . . . . . . . . . . . . . . . . . 23
+ 2.6.2. Object Attributes . . . . . . . . . . . . . . . . . . 24
+ 2.7. Object References . . . . . . . . . . . . . . . . . . . . 28
+ 2.7.1. Sample ObjectReference object . . . . . . . . . . . . 28
+ 2.7.2. ObjectReference Attributes . . . . . . . . . . . . . 28
+ 2.8. Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 2.8.1. Sample Tag . . . . . . . . . . . . . . . . . . . . . 31
+ 2.9. Sighting . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 2.9.1. Sample Sighting . . . . . . . . . . . . . . . . . . . 32
+ 2.10. Galaxy . . . . . . . . . . . . . . . . . . . . . . . . . 33
+ 2.10.1. Sample Galaxy . . . . . . . . . . . . . . . . . . . 33
+ 3. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 35
+ 4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 49
+ 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 49
+ 4.1.1. Sample Manifest . . . . . . . . . . . . . . . . . . . 50
+ 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 51
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 51
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 51
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 52
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 2]
+
+Internet-Draft MISP core format August 2018
+
+
+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 [MISP-P] 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 [RFC8259] 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-
+ capitalised key is just an attribute. This nomenclature can support
+ 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.
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 3]
+
+Internet-Draft MISP core format August 2018
+
+
+2.2.1.2. id
+
+ id represents the human-readable identifier associated to the event
+ for a specific MISP instance. A human-readable identifier MUST be
+ represented as an unsigned integer.
+
+ 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 is a free-
+ text value to provide a human-readable summary of the event. info
+ SHOULD NOT be bigger than 256 characters and SHOULD NOT include new-
+ lines.
+
+ 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.
+
+ 4:
+ Undefined
+
+ 3:
+ Low
+
+ 2:
+ Medium
+
+ 1:
+ 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.
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 4]
+
+Internet-Draft MISP core format August 2018
+
+
+2.2.1.6. analysis
+
+ analysis represents the analysis level.
+
+ 0:
+ Initial
+
+ 1:
+ Ongoing
+
+ 2:
+ Complete
+
+ If a higher granularity is required, a MISP taxonomy applied as a Tag
+ SHOULD be preferred.
+
+ analysis is represented as a JSON string. analysis SHALL be present.
+
+2.2.1.7. 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
+ occurred, which may be in the past.
+
+ date is represented as a JSON string. date MUST be present.
+
+2.2.1.8. 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.9. 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. If the published_timestamp is present and the
+ published flag is set to false, the publish_timestamp represents the
+ previous publication timestamp. If the event was never published,
+ the published_timestamp MUST be set to 0.
+
+ publish_timestamp is represented as a JSON string. publish_timestamp
+ MUST be present.
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 5]
+
+Internet-Draft MISP core format August 2018
+
+
+2.2.1.10. org_id
+
+ org_id represents a human-readable identifier referencing an Org
+ object of the organisation which generated the event. A human-
+ readable identifier MUST be represented as an unsigned integer.
+
+ 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.11. orgc_id
+
+ orgc_id represents a human-readable identifier referencing an Orgc
+ object of the organisation which created the event.
+
+ The orgc_id and Org 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.12. 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.2.1.13. distribution
+
+ distribution represents the basic distribution rules of the event.
+ The system must adhere to the distribution setting for access control
+ and for dissemination of the event.
+
+ distribution is represented by a JSON string. distribution MUST be
+ present and be one of the following options:
+
+ 0
+ Your Organisation Only
+
+ 1
+ This Community Only
+
+ 2
+ Connected Communities
+
+ 3
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 6]
+
+Internet-Draft MISP core format August 2018
+
+
+ All Communities
+
+ 4
+ Sharing Group
+
+2.2.1.14. sharing_group_id
+
+ sharing_group_id represents a human-readable identifier referencing a
+ Sharing Group object that defines the distribution of the event, if
+ distribution level "4" is set. A human-readable identifier MUST be
+ represented as an unsigned integer.
+
+ sharing_group_id is represented by a JSON string and SHOULD be
+ present. If a distribution level other than "4" is chosen the
+ sharing_group_id MUST be set to "0".
+
+2.2.1.15. extends_uuid
+
+ extends_uuid represents which event is extended by this event. The
+ extends_uuid is described as a Universally Unique IDentifier (UUID)
+ [RFC4122] with the UUID of the extended event.
+
+ extends_uuid is represented as a JSON string. extends_uuid SHOULD 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 organisation. The organisation UUID is globally
+ assigned to an organisation and SHALL be kept overtime.
+
+ The name is a readable description of the organisation and SHOULD be
+ present. The id is a human-readable identifier generated by the
+ instance and used as reference in the event. A human-readable
+ identifier MUST be represented as an unsigned integer.
+
+ uuid, name and id are represented as a JSON string. uuid, name and id
+ MUST be present.
+
+2.3.1.1. Sample Org Object
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 7]
+
+Internet-Draft MISP core format August 2018
+
+
+ "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 organisation UUID is globally assigned to an organisation
+ and SHALL be kept overtime.
+
+ The name is a readable description of the organisation and SHOULD be
+ present. The id is a human-readable identifier generated by the
+ instance and used as reference in the event. A human-readable
+ identifier MUST be represented as an unsigned integer.
+
+ uuid, name and id are represented as a JSON string. uuid, name and id
+ MUST be present.
+
+2.4. Attribute
+
+ Attributes are used to describe the indicators and contextual data of
+ an event. The main information contained in an attribute is made up
+ of a category-type-value triplet, where the category and type give
+ meaning and context to the value. Through the various category-type
+ combinations a wide range of information can be conveyed.
+
+ A MISP document MUST at least includes category-type-value triplet
+ described in section "Attribute Attributes".
+
+2.4.1. Sample Attribute Object
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 8]
+
+Internet-Draft MISP core format August 2018
+
+
+ "Attribute": {
+ "id": "346056",
+ "type": "comment",
+ "category": "Other",
+ "to_ids": false,
+ "uuid": "57f4f6d9-cd20-458b-84fd-109ec0a83869",
+ "event_id": "3357",
+ "distribution": "5",
+ "timestamp": "1475679332",
+ "comment": "",
+ "sharing_group_id": "0",
+ "deleted": false,
+ "value": "Hello world",
+ "SharingGroup": [],
+ "ShadowAttribute": [],
+ "RelatedAttribute": [],
+ "first_seen": "2019-06-02T22:14:28.711954+00:00",
+ "last_seen": null
+ }
+
+2.4.2. Attribute Attributes
+
+2.4.2.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.4.2.2. id
+
+ id represents the human-readable identifier associated to the event
+ for a specific MISP instance. A human-readable identifier MUST be
+ represented as an unsigned integer.
+
+ id is represented as a JSON string. id SHALL be present.
+
+2.4.2.3. type
+
+ type represents the means through which an attribute tries to
+ describe the intent of the attribute creator, using a list of pre-
+ defined attribute types.
+
+ type is represented as a JSON string. type MUST be present and it
+ MUST be a valid selection for the chosen category. The list of valid
+ category-type combinations is as follows:
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 9]
+
+Internet-Draft MISP core format August 2018
+
+
+ Antivirus detection
+ link, comment, text, hex, attachment, other, anonymised
+
+ Artifacts dropped
+ md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
+ ssdeep, imphash, impfuzzy, authentihash, cdhash, filename,
+ filename|md5, filename|sha1, filename|sha224, filename|sha256,
+ filename|sha384, filename|sha512, filename|sha512/224,
+ filename|sha512/256, filename|authentihash, filename|ssdeep,
+ filename|tlsh, filename|imphash, filename|impfuzzy,
+ filename|pehash, regkey, regkey|value, pattern-in-file, pattern-
+ in-memory, pdb, stix2-pattern, yara, sigma, attachment, malware-
+ sample, named pipe, mutex, windows-scheduled-task, windows-
+ service-name, windows-service-displayname, comment, text, hex,
+ x509-fingerprint-sha1, x509-fingerprint-md5, x509-fingerprint-
+ sha256, other, cookie, gene, mime-type, anonymised
+
+ Attribution
+ threat-actor, campaign-name, campaign-id, whois-registrant-phone,
+ whois-registrant-email, whois-registrant-name, whois-registrant-
+ org, whois-registrar, whois-creation-date, comment, text, x509-
+ fingerprint-sha1, x509-fingerprint-md5, x509-fingerprint-sha256,
+ other, dns-soa-email, anonymised
+
+ External analysis
+ md5, sha1, sha256, filename, filename|md5, filename|sha1,
+ filename|sha256, ip-src, ip-dst, ip-dst|port, ip-src|port, mac-
+ address, mac-eui-64, hostname, domain, domain|ip, url, user-agent,
+ regkey, regkey|value, AS, snort, bro, zeek, pattern-in-file,
+ pattern-in-traffic, pattern-in-memory, vulnerability, attachment,
+ malware-sample, link, comment, text, x509-fingerprint-sha1, x509-
+ fingerprint-md5, x509-fingerprint-sha256, ja3-fingerprint-md5,
+ hassh-md5, hasshserver-md5, github-repository, other, cortex,
+ anonymised
+
+ Financial fraud
+ btc, xmr, iban, bic, bank-account-nr, aba-rtn, bin, cc-number,
+ prtn, phone-number, comment, text, other, hex, anonymised
+
+ Internal reference
+ text, link, comment, other, hex, anonymised
+
+ Network activity
+ ip-src, ip-dst, ip-dst|port, ip-src|port, port, hostname, domain,
+ domain|ip, mac-address, mac-eui-64, email-dst, url, uri, user-
+ agent, http-method, AS, snort, pattern-in-file, stix2-pattern,
+ pattern-in-traffic, attachment, comment, text, x509-fingerprint-
+ md5, x509-fingerprint-sha1, x509-fingerprint-sha256, ja3-
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 10]
+
+Internet-Draft MISP core format August 2018
+
+
+ fingerprint-md5, hassh-md5, hasshserver-md5, other, hex, cookie,
+ hostname|port, bro, zeek, anonymised
+
+ Other
+ comment, text, other, size-in-bytes, counter, datetime, cpe, port,
+ float, hex, phone-number, boolean, anonymised
+
+ Payload delivery
+ md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
+ ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, cdhash,
+ filename, filename|md5, filename|sha1, filename|sha224,
+ filename|sha256, filename|sha384, filename|sha512,
+ filename|sha512/224, filename|sha512/256, filename|authentihash,
+ filename|ssdeep, filename|tlsh, filename|imphash,
+ filename|impfuzzy, filename|pehash, mac-address, mac-eui-64, ip-
+ src, ip-dst, ip-dst|port, ip-src|port, hostname, domain, email-
+ src, email-dst, email-subject, email-attachment, email-body, url,
+ user-agent, AS, pattern-in-file, pattern-in-traffic,
+ stix2-pattern, yara, sigma, mime-type, attachment, malware-sample,
+ link, malware-type, comment, text, hex, vulnerability, x509-
+ fingerprint-sha1, x509-fingerprint-md5, x509-fingerprint-sha256,
+ ja3-fingerprint-md5, hassh-md5, hasshserver-md5, other,
+ hostname|port, email-dst-display-name, email-src-display-name,
+ email-header, email-reply-to, email-x-mailer, email-mime-boundary,
+ email-thread-index, email-message-id, mobile-application-id,
+ whois-registrant-email, anonymised
+
+ Payload installation
+ md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
+ ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, cdhash,
+ filename, filename|md5, filename|sha1, filename|sha224,
+ filename|sha256, filename|sha384, filename|sha512,
+ filename|sha512/224, filename|sha512/256, filename|authentihash,
+ filename|ssdeep, filename|tlsh, filename|imphash,
+ filename|impfuzzy, filename|pehash, pattern-in-file, pattern-in-
+ traffic, pattern-in-memory, stix2-pattern, yara, sigma,
+ vulnerability, attachment, malware-sample, malware-type, comment,
+ text, hex, x509-fingerprint-sha1, x509-fingerprint-md5, x509-
+ fingerprint-sha256, mobile-application-id, other, mime-type,
+ anonymised
+
+ Payload type
+ comment, text, other, anonymised
+
+ Persistence mechanism
+ filename, regkey, regkey|value, comment, text, other, hex,
+ anonymised
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 11]
+
+Internet-Draft MISP core format August 2018
+
+
+ Person
+ first-name, middle-name, last-name, date-of-birth, place-of-birth,
+ gender, passport-number, passport-country, passport-expiration,
+ redress-number, nationality, visa-number, issue-date-of-the-visa,
+ primary-residence, country-of-residence, special-service-request,
+ frequent-flyer-number, travel-details, payment-details, place-
+ port-of-original-embarkation, place-port-of-clearance, place-port-
+ of-onward-foreign-destination, passenger-name-record-locator-
+ number, comment, text, other, phone-number, identity-card-number,
+ anonymised
+
+ Social network
+ github-username, github-repository, github-organisation, jabber-
+ id, twitter-id, email-src, email-dst, comment, text, other, whois-
+ registrant-email, anonymised
+
+ Support Tool
+ link, text, attachment, comment, other, hex, anonymised
+
+ Targeting data
+ target-user, target-email, target-machine, target-org, target-
+ location, target-external, comment, anonymised
+
+ Attributes are based on the usage within their different communities.
+ Attributes can be extended on a regular basis and this reference
+ document is updated accordingly.
+
+2.4.2.4. category
+
+ category represents the intent of what the attribute is describing as
+ selected by the attribute creator, using a list of pre-defined
+ attribute categories.
+
+ category is represented as a JSON string. category MUST be present
+ and it MUST be a valid selection for the chosen type. The list of
+ valid category-type combinations is mentioned above.
+
+2.4.2.5. to_ids
+
+ to_ids represents whether the attribute is meant to be actionable.
+ Actionable defined attributes that can be used in automated processes
+ as a pattern for detection in Local or Network Intrusion Detection
+ System, log analysis tools or even filtering mechanisms.
+
+ to_ids is represented as a JSON boolean. to_ids MUST be present.
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 12]
+
+Internet-Draft MISP core format August 2018
+
+
+2.4.2.6. event_id
+
+ event_id represents a human-readable identifier referencing the Event
+ object that the attribute belongs to. A human-readable identifier
+ MUST be represented as an unsigned integer.
+
+ The event_id SHOULD be updated when the event is imported to reflect
+ the newly created event's id on the instance.
+
+ event_id is represented as a JSON string. event_id MUST be present.
+
+2.4.2.7. distribution
+
+ distribution represents the basic distribution rules of the
+ attribute. The system must adhere to the distribution setting for
+ access control and for dissemination of the attribute.
+
+ distribution is represented by a JSON string. distribution MUST be
+ present and be one of the following options:
+
+ 0
+ Your Organisation Only
+
+ 1
+ This Community Only
+
+ 2
+ Connected Communities
+
+ 3
+ All Communities
+
+ 4
+ Sharing Group
+
+ 5
+ Inherit Event
+
+2.4.2.8. timestamp
+
+ timestamp represents a reference time when the attribute was created
+ or last modified. 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.
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 13]
+
+Internet-Draft MISP core format August 2018
+
+
+2.4.2.9. comment
+
+ comment is a contextual comment field.
+
+ comment is represented by a JSON string. comment MAY be present.
+
+2.4.2.10. sharing_group_id
+
+ sharing_group_id represents a human-readable identifier referencing a
+ Sharing Group object that defines the distribution of the attribute,
+ if distribution level "4" is set. A human-readable identifier MUST
+ be represented as an unsigned integer.
+
+ sharing_group_id is represented by a JSON string and SHOULD be
+ present. If a distribution level other than "4" is chosen the
+ sharing_group_id MUST be set to "0".
+
+2.4.2.11. deleted
+
+ deleted represents a setting that allows attributes to be revoked.
+ Revoked attributes are not actionable and exist merely to inform
+ other instances of a revocation.
+
+ deleted is represented by a JSON boolean. deleted MUST be present.
+
+2.4.2.12. data
+
+ data contains the base64 encoded contents of an attachment or a
+ malware sample. For malware samples, the sample MUST be encrypted
+ using a password protected zip archive, with the password being
+ "infected".
+
+ data is represented by a JSON string in base64 encoding. data MUST be
+ set for attributes of type malware-sample and attachment.
+
+2.4.2.13. RelatedAttribute
+
+ RelatedAttribute is an array of attributes correlating with the
+ current attribute. Each element in the array represents an JSON
+ object which contains an Attribute dictionnary with the external
+ attributes who correlate. Each Attribute MUST include the id,
+ org_id, info and a value. Only the correlations found on the local
+ instance are shown in RelatedAttribute.
+
+ RelatedAttribute MAY be present.
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 14]
+
+Internet-Draft MISP core format August 2018
+
+
+2.4.2.14. ShadowAttribute
+
+ ShadowAttribute is an array of shadow attributes that serve as
+ proposals by third parties to alter the containing attribute. The
+ structure of a ShadowAttribute is similar to that of an Attribute,
+ which can be accepted or discarded by the event creator. If
+ accepted, the original attribute containing the shadow attribute is
+ removed and the shadow attribute is converted into an attribute.
+
+ Each shadow attribute that references an attribute MUST contain the
+ containing attribute's ID in the old_id field and the event's ID in
+ the event_id field.
+
+2.4.2.15. value
+
+ value represents the payload of an attribute. The format of the
+ value is dependent on the type of the attribute.
+
+ value is represented by a JSON string. value MUST be present.
+
+2.4.2.16. first_seen
+
+ first_seen represents a reference time when the attribute was first
+ seen. first_seen is expressed as an ISO 8601 datetime up to the
+ micro-second with time zone support.
+
+ first_seen is represented as a JSON string. first_seen MAY be
+ present.
+
+2.4.2.17. last_seen
+
+ last_seen represents a reference time when the attribute was last
+ seen. last_seen is expressed as an ISO 8601 datetime up to the micro-
+ second with time zone support.
+
+ last_seen is represented as a JSON string. last_seen MAY be present.
+
+2.5. ShadowAttribute
+
+ ShadowAttributes are 3rd party created attributes that either propose
+ to add new information to an event or modify existing information.
+ They are not meant to be actionable until the event creator accepts
+ them - at which point they will be converted into attributes or
+ modify an existing attribute.
+
+ They are similar in structure to Attributes but additionally carry a
+ reference to the creator of the ShadowAttribute as well as a
+ revocation flag.
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 15]
+
+Internet-Draft MISP core format August 2018
+
+
+2.5.1. Sample Attribute Object
+
+"ShadowAttribute": {
+ "id": "8",
+ "type": "ip-src",
+ "category": "Network activity",
+ "to_ids": false,
+ "uuid": "57d475f1-da78-4569-89de-1458c0a83869",
+ "event_uuid": "57d475e6-41c4-41ca-b450-145ec0a83869",
+ "event_id": "9",
+ "old_id": "319",
+ "comment": "",
+ "org_id": "1",
+ "proposal_to_delete": false,
+ "value": "5.5.5.5",
+ "deleted": false,
+ "Org": {
+ "id": "1",
+ "name": "MISP",
+ "uuid": "568cce5a-0c80-412b-8fdf-1ffac0a83869"
+ },
+ "first_seen": "2019-06-02T22:14:28.711954+00:00",
+ "last_seen": null
+ }
+
+2.5.2. ShadowAttribute Attributes
+
+2.5.2.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.5.2.2. id
+
+ id represents the human-readable identifier associated to the event
+ for a specific MISP instance. human-readable identifier MUST be
+ represented as an unsigned integer. id is represented as a JSON
+ string. id SHALL be present.
+
+2.5.2.3. type
+
+ type represents the means through which an attribute tries to
+ describe the intent of the attribute creator, using a list of pre-
+ defined attribute types.
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 16]
+
+Internet-Draft MISP core format August 2018
+
+
+ type is represented as a JSON string. type MUST be present and it
+ MUST be a valid selection for the chosen category. The list of valid
+ category-type combinations is as follows:
+
+ Antivirus detection
+ link, comment, text, hex, attachment, other, anonymised
+
+ Artifacts dropped
+ md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
+ ssdeep, imphash, impfuzzy, authentihash, cdhash, filename,
+ filename|md5, filename|sha1, filename|sha224, filename|sha256,
+ filename|sha384, filename|sha512, filename|sha512/224,
+ filename|sha512/256, filename|authentihash, filename|ssdeep,
+ filename|tlsh, filename|imphash, filename|impfuzzy,
+ filename|pehash, regkey, regkey|value, pattern-in-file, pattern-
+ in-memory, pdb, stix2-pattern, yara, sigma, attachment, malware-
+ sample, named pipe, mutex, windows-scheduled-task, windows-
+ service-name, windows-service-displayname, comment, text, hex,
+ x509-fingerprint-sha1, x509-fingerprint-md5, x509-fingerprint-
+ sha256, other, cookie, gene, mime-type, anonymised
+
+ Attribution
+ threat-actor, campaign-name, campaign-id, whois-registrant-phone,
+ whois-registrant-email, whois-registrant-name, whois-registrant-
+ org, whois-registrar, whois-creation-date, comment, text, x509-
+ fingerprint-sha1, x509-fingerprint-md5, x509-fingerprint-sha256,
+ other, dns-soa-email, anonymised
+
+ External analysis
+ md5, sha1, sha256, filename, filename|md5, filename|sha1,
+ filename|sha256, ip-src, ip-dst, ip-dst|port, ip-src|port, mac-
+ address, mac-eui-64, hostname, domain, domain|ip, url, user-agent,
+ regkey, regkey|value, AS, snort, bro, zeek, pattern-in-file,
+ pattern-in-traffic, pattern-in-memory, vulnerability, attachment,
+ malware-sample, link, comment, text, x509-fingerprint-sha1, x509-
+ fingerprint-md5, x509-fingerprint-sha256, ja3-fingerprint-md5,
+ hassh-md5, hasshserver-md5, github-repository, other, cortex,
+ anonymised
+
+ Financial fraud
+ btc, xmr, iban, bic, bank-account-nr, aba-rtn, bin, cc-number,
+ prtn, phone-number, comment, text, other, hex, anonymised
+
+ Internal reference
+ text, link, comment, other, hex, anonymised
+
+ Network activity
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 17]
+
+Internet-Draft MISP core format August 2018
+
+
+ ip-src, ip-dst, ip-dst|port, ip-src|port, port, hostname, domain,
+ domain|ip, mac-address, mac-eui-64, email-dst, url, uri, user-
+ agent, http-method, AS, snort, pattern-in-file, stix2-pattern,
+ pattern-in-traffic, attachment, comment, text, x509-fingerprint-
+ md5, x509-fingerprint-sha1, x509-fingerprint-sha256, ja3-
+ fingerprint-md5, hassh-md5, hasshserver-md5, other, hex, cookie,
+ hostname|port, bro, zeek, anonymised
+
+ Other
+ comment, text, other, size-in-bytes, counter, datetime, cpe, port,
+ float, hex, phone-number, boolean, anonymised
+
+ Payload delivery
+ md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
+ ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, cdhash,
+ filename, filename|md5, filename|sha1, filename|sha224,
+ filename|sha256, filename|sha384, filename|sha512,
+ filename|sha512/224, filename|sha512/256, filename|authentihash,
+ filename|ssdeep, filename|tlsh, filename|imphash,
+ filename|impfuzzy, filename|pehash, mac-address, mac-eui-64, ip-
+ src, ip-dst, ip-dst|port, ip-src|port, hostname, domain, email-
+ src, email-dst, email-subject, email-attachment, email-body, url,
+ user-agent, AS, pattern-in-file, pattern-in-traffic,
+ stix2-pattern, yara, sigma, mime-type, attachment, malware-sample,
+ link, malware-type, comment, text, hex, vulnerability, x509-
+ fingerprint-sha1, x509-fingerprint-md5, x509-fingerprint-sha256,
+ ja3-fingerprint-md5, hassh-md5, hasshserver-md5, other,
+ hostname|port, email-dst-display-name, email-src-display-name,
+ email-header, email-reply-to, email-x-mailer, email-mime-boundary,
+ email-thread-index, email-message-id, mobile-application-id,
+ whois-registrant-email, anonymised
+
+ Payload installation
+ md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
+ ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, cdhash,
+ filename, filename|md5, filename|sha1, filename|sha224,
+ filename|sha256, filename|sha384, filename|sha512,
+ filename|sha512/224, filename|sha512/256, filename|authentihash,
+ filename|ssdeep, filename|tlsh, filename|imphash,
+ filename|impfuzzy, filename|pehash, pattern-in-file, pattern-in-
+ traffic, pattern-in-memory, stix2-pattern, yara, sigma,
+ vulnerability, attachment, malware-sample, malware-type, comment,
+ text, hex, x509-fingerprint-sha1, x509-fingerprint-md5, x509-
+ fingerprint-sha256, mobile-application-id, other, mime-type,
+ anonymised
+
+ Payload type
+ comment, text, other, anonymised
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 18]
+
+Internet-Draft MISP core format August 2018
+
+
+ Persistence mechanism
+ filename, regkey, regkey|value, comment, text, other, hex,
+ anonymised
+
+ Person
+ first-name, middle-name, last-name, date-of-birth, place-of-birth,
+ gender, passport-number, passport-country, passport-expiration,
+ redress-number, nationality, visa-number, issue-date-of-the-visa,
+ primary-residence, country-of-residence, special-service-request,
+ frequent-flyer-number, travel-details, payment-details, place-
+ port-of-original-embarkation, place-port-of-clearance, place-port-
+ of-onward-foreign-destination, passenger-name-record-locator-
+ number, comment, text, other, phone-number, identity-card-number,
+ anonymised
+
+ Social network
+ github-username, github-repository, github-organisation, jabber-
+ id, twitter-id, email-src, email-dst, comment, text, other, whois-
+ registrant-email, anonymised
+
+ Support Tool
+ link, text, attachment, comment, other, hex, anonymised
+
+ Targeting data
+ target-user, target-email, target-machine, target-org, target-
+ location, target-external, comment, anonymised
+
+ Attributes are based on the usage within their different communities.
+ Attributes can be extended on a regular basis and this reference
+ document is updated accordingly.
+
+2.5.2.4. category
+
+ category represents the intent of what the attribute is describing as
+ selected by the attribute creator, using a list of pre-defined
+ attribute categories.
+
+ category is represented as a JSON string. category MUST be present
+ and it MUST be a valid selection for the chosen type. The list of
+ valid category-type combinations is mentioned above.
+
+2.5.2.5. to_ids
+
+ to_ids represents whether the Attribute to be created if the
+ ShadowAttribute is accepted is meant to be actionable. Actionable
+ defined attributes that can be used in automated processes as a
+ pattern for detection in Local or Network Intrusion Detection System,
+ log analysis tools or even filtering mechanisms.
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 19]
+
+Internet-Draft MISP core format August 2018
+
+
+ to_ids is represented as a JSON boolean. to_ids MUST be present.
+
+2.5.2.6. event_id
+
+ event_id represents a human-readable identifier referencing the Event
+ object that the ShadowAttribute belongs to.
+
+ The event_id SHOULD be updated when the event is imported to reflect
+ the newly created event's id on the instance.
+
+ event_id is represented as a JSON string. event_id MUST be present.
+
+2.5.2.7. old_id
+
+ old_id represents a human-readable identifier referencing the
+ Attribute object that the ShadowAttribute belongs to. A
+ ShadowAttribute can this way target an existing Attribute, implying
+ that it is a proposal to modify an existing Attribute, or
+ alternatively it can be a proposal to create a new Attribute for the
+ containing Event.
+
+ The old_id SHOULD be updated when the event is imported to reflect
+ the newly created Attribute's id on the instance. Alternatively, if
+ the ShadowAttribute proposes the creation of a new Attribute, it
+ should be set to 0.
+
+ old_id is represented as a JSON string. old_id MUST be present.
+
+2.5.2.8. timestamp
+
+ timestamp represents a reference time when the attribute was created
+ or last modified. 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.5.2.9. comment
+
+ comment is a contextual comment field.
+
+ comment is represented by a JSON string. comment MAY be present.
+
+2.5.2.10. org_id
+
+ org_id represents a human-readable identifier referencing the
+ proposal creator's Organisation object. A human-readable identifier
+ MUST be represented as an unsigned integer.
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 20]
+
+Internet-Draft MISP core format August 2018
+
+
+ Whilst attributes can only be created by the event creator
+ organisation, shadow attributes can be created by third parties.
+ org_id tracks the creator organisation.
+
+ org_id is represented by a JSON string and MUST be present.
+
+2.5.2.11. proposal_to_delete
+
+ proposal_to_delete is a boolean flag that sets whether the shadow
+ attribute proposes to alter an attribute, or whether it proposes to
+ remove it completely.
+
+ Accepting a shadow attribute with this flag set will remove the
+ target attribute.
+
+ proposal_to_delete is a JSON boolean and it MUST be present. If
+ proposal_to_delete is set to true, old_id MUST NOT be 0.
+
+2.5.2.12. deleted
+
+ deleted represents a setting that allows shadow attributes to be
+ revoked. Revoked shadow attributes only serve to inform other
+ instances that the shadow attribute is no longer active.
+
+ deleted is represented by a JSON boolean. deleted SHOULD be present.
+
+2.5.2.13. data
+
+ data contains the base64 encoded contents of an attachment or a
+ malware sample. For malware samples, the sample MUST be encrypted
+ using a password protected zip archive, with the password being
+ "infected".
+
+ data is represented by a JSON string in base64 encoding. data MUST be
+ set for shadow attributes of type malware-sample and attachment.
+
+2.5.2.14. first_seen
+
+ first_seen represents a reference time when the attribute was first
+ seen. first_seen as an ISO 8601 datetime up to the micro-second with
+ time zone support.
+
+ first_seen is represented as a JSON string. first_seen MAY be
+ present.
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 21]
+
+Internet-Draft MISP core format August 2018
+
+
+2.5.2.15. last_seen
+
+ last_seen represents a reference time when the attribute was last
+ seen. last_seen as an ISO 8601 datetime up to the micro-second with
+ time zone support.
+
+ last_seen is represented as a JSON string. last_seen MAY be present.
+
+2.5.3. 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. A human-readable
+ identifier MUST be represented as an unsigned integer.
+
+ uuid, name and id are represented as a JSON string. uuid, name and id
+ MUST be present.
+
+2.5.3.1. Sample Org Object
+
+ "Org": {
+ "id": "2",
+ "name": "CIRCL",
+ "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f"
+ }
+
+2.5.3.2. value
+
+ value represents the payload of an attribute. The format of the
+ value is dependent on the type of the attribute.
+
+ value is represented by a JSON string. value MUST be present.
+
+2.6. Object
+
+ Objects serve as a contextual bond between a list of attributes
+ within an event. Their main purpose is to describe more complex
+ structures than can be described by a single attribute Each object is
+ created using an Object Template and carries the meta-data of the
+ template used for its creation within. Objects belong to a meta-
+ category and are defined by a name.
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 22]
+
+Internet-Draft MISP core format August 2018
+
+
+ The schema used is described by the template_uuid and
+ template_version fields.
+
+ A MISP document containing an Object MUST contain a name, a meta-
+ category, a description, a template_uuid and a template_version as
+ described in the "Object Attributes" section.
+
+2.6.1. Sample Object
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 23]
+
+Internet-Draft MISP core format August 2018
+
+
+"Object": {
+ "id": "588",
+ "name": "file",
+ "meta-category": "file",
+ "description": "File object describing a file with meta-information",
+ "template_uuid": "688c46fb-5edb-40a3-8273-1af7923e2215",
+ "template_version": "3",
+ "event_id": "56",
+ "uuid": "398b0094-0384-4c48-9bf0-22b3dff9c4d3",
+ "timestamp": "1505747965",
+ "distribution": "5",
+ "sharing_group_id": "0",
+ "comment": "",
+ "deleted": false,
+ "ObjectReference": [],
+ "Attribute": [
+ {
+ "id": "7822",
+ "type": "filename",
+ "category": "Payload delivery",
+ "to_ids": true,
+ "uuid": "59bfe3fb-bde0-4dfe-b5b1-2b10a07724d1",
+ "event_id": "56",
+ "distribution": "0",
+ "timestamp": "1505747963",
+ "comment": "",
+ "sharing_group_id": "0",
+ "deleted": false,
+ "disable_correlation": false,
+ "object_id": "588",
+ "object_relation": "filename",
+ "value": "StarCraft.exe",
+ "ShadowAttribute": [],
+ "first_seen": null,
+ "last_seen": null
+ },
+ "first_seen": "2019-06-02T22:14:28.711954+00:00",
+ "last_seen": null
+ ]
+}
+
+ Figure 1
+
+2.6.2. Object Attributes
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 24]
+
+Internet-Draft MISP core format August 2018
+
+
+2.6.2.1. uuid
+
+ uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of
+ the object. The uuid MUST be preserved for any updates or transfer
+ of the same object. UUID version 4 is RECOMMENDED when assigning it
+ to a new object.
+
+2.6.2.2. id
+
+ id represents the human-readable identifier associated to the object
+ for a specific MISP instance. A human-readable identifier MUST be
+ represented as an unsigned integer.
+
+ id is represented as a JSON string. id SHALL be present.
+
+2.6.2.3. name
+
+ name represents the human-readable name of the object describing the
+ intent of the object package.
+
+ name is represented as a JSON string. name MUST be present
+
+2.6.2.4. meta-category
+
+ meta-category represents the sub-category of objects that the given
+ object belongs to. meta-categories are not tied to a fixed list of
+ options but can be created on the fly.
+
+ meta-category is represented as a JSON string. meta-category MUST be
+ present
+
+2.6.2.5. description
+
+ description is a human-readable description of the given object type,
+ as derived from the template used for creation.
+
+ description is represented as a JSON string. id SHALL be present.
+
+2.6.2.6. template_uuid
+
+ uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of
+ the template used to create the object. The uuid MUST be preserved
+ to preserve the object's association with the correct template used
+ for creation. UUID version 4 is RECOMMENDED when assigning it to a
+ new object.
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 25]
+
+Internet-Draft MISP core format August 2018
+
+
+2.6.2.7. template_version
+
+ template_version represents a numeric incrementing version of the
+ template used to create the object. It is used to associate the
+ object to the correct version of the template and together with the
+ template_uuid forms an association to the correct template type and
+ version.
+
+ version is represented as a JSON string. version MUST be present.
+
+2.6.2.8. event_id
+
+ event_id represents the human-readable identifier of the event that
+ the object belongs to on a specific MISP instance. A human-readable
+ identifier MUST be represented as an unsigned integer.
+
+ event_id is represented as a JSON string. event_id SHALL be present.
+
+2.6.2.9. timestamp
+
+ timestamp represents a reference time when the object was created or
+ last modified. 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.6.2.10. distribution
+
+ distribution represents the basic distribution rules of the object.
+ The system must adhere to the distribution setting for access control
+ and for dissemination of the object.
+
+ distribution is represented by a JSON string. distribution MUST be
+ present and be one of the following options:
+
+ 0
+ Your Organisation Only
+
+ 1
+ This Community Only
+
+ 2
+ Connected Communities
+
+ 3
+ All Communities
+
+ 4
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 26]
+
+Internet-Draft MISP core format August 2018
+
+
+ Sharing Group
+
+2.6.2.11. sharing_group_id
+
+ sharing_group_id represents a human-readable identifier referencing a
+ Sharing Group object that defines the distribution of the object, if
+ distribution level "4" is set. A human-readable identifier MUST be
+ represented as an unsigned integer.
+
+ sharing_group_id is represented by a JSON string and SHOULD be
+ present. If a distribution level other than "4" is chosen the
+ sharing_group_id MUST be set to "0".
+
+2.6.2.12. comment
+
+ comment is a contextual comment field.
+
+ comment is represented by a JSON string. comment MAY be present.
+
+2.6.2.13. deleted
+
+ deleted represents a setting that allows attributes to be revoked.
+ Revoked attributes are not actionable and exist merely to inform
+ other instances of a revocation.
+
+ deleted is represented by a JSON boolean. deleted MUST be present.
+
+2.6.2.14. Attribute
+
+ Attribute is an array of attributes that describe the object with
+ data.
+
+ Each attribute in an object MUST contain the parent event's ID in the
+ event_id field and the parent object's ID in the object_id field.
+
+2.6.2.15. first_seen
+
+ first_seen represents a reference time when the object was first
+ seen. first_seen as an ISO 8601 datetime up to the micro-second with
+ time zone support.
+
+ first_seen is represented as a JSON string. first_seen MAY be
+ present.
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 27]
+
+Internet-Draft MISP core format August 2018
+
+
+2.6.2.16. last_seen
+
+ last_seen represents a reference time when the object was last seen.
+ last_seen as an ISO 8601 datetime up to the micro-second with time
+ zone support.
+
+ last_seen is represented as a JSON string. last_seen MAY be present.
+
+2.7. Object References
+
+ Object References serve as a logical link between an Object and
+ another referenced Object or Attribute. The relationship is
+ categorised by an enumerated value from a fixed vocabulary.
+
+ The relationship_type is recommended to be taken from the MISP object
+ relationship list [[MISP-R]] is RECOMMENDED to ensure a coherent
+ naming of the tags
+
+ All Object References MUST contain an object_uuid, a referenced_uuid
+ and a relationship type.
+
+2.7.1. Sample ObjectReference object
+
+"ObjectReference": {
+ "id": "195",
+ "uuid": "59c21a2c-c0ac-4083-93b3-363da07724d1",
+ "timestamp": "1505892908",
+ "object_id": "591",
+ "event_id": "113",
+ "referenced_id": "590",
+ "referenced_type": "1",
+ "relationship_type": "derived-from",
+ "comment": "",
+ "deleted": false,
+ "object_uuid": "59c1134d-8a40-4c14-ad94-0f7ba07724d1",
+ "referenced_uuid": "59c1133c-9adc-4d06-a34b-0f7ca07724d1",
+ }
+
+2.7.2. ObjectReference Attributes
+
+2.7.2.1. uuid
+
+ uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of
+ the object reference. The uuid MUST be preserved for any updates or
+ transfer of the same object reference. UUID version 4 is RECOMMENDED
+ when assigning it to a new object reference.
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 28]
+
+Internet-Draft MISP core format August 2018
+
+
+2.7.2.2. id
+
+ id represents the human-readable identifier associated to the object
+ reference for a specific MISP instance.
+
+ id is represented as a JSON string. id SHALL be present.
+
+2.7.2.3. timestamp
+
+ timestamp represents a reference time when the object was created or
+ last modified. 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.7.2.4. object_id
+
+ object_id represents the human-readable identifier of the object that
+ the object reference belongs to on a specific MISP instance. A
+ human-readable identifier MUST be represented as an unsigned integer.
+
+ event_id is represented as a JSON string. event_id SHALL be present.
+
+2.7.2.5. event_id
+
+ event_id represents the human-readable identifier of the event that
+ the object reference belongs to on a specific MISP instance. A
+ human-readable identifier MUST be represented as an unsigned integer.
+
+ event_id is represented as a JSON string. event_id SHALL be present.
+
+2.7.2.6. referenced_id
+
+ referenced_id represents the human-readable identifier of the object
+ or attribute that the parent object of the object reference points to
+ on a specific MISP instance.
+
+ referenced_id is represented as a JSON string. referenced_id MAY be
+ present.
+
+2.7.2.7. referenced_type
+
+ referenced_type represents the numeric value describing what the
+ object reference points to, "0" representing an attribute and "1"
+ representing an object
+
+ referenced_type is represented as a JSON string. referenced_type MAY
+ be present.
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 29]
+
+Internet-Draft MISP core format August 2018
+
+
+2.7.2.8. relationship_type
+
+ relationship_type represents the human-readable context of the
+ relationship between an object and another object or attribute as
+ described by the object_reference.
+
+ referenced_type is represented as a JSON string. relationship_type
+ MUST be present.
+
+2.7.2.9. comment
+
+ comment is a contextual comment field.
+
+ comment is represented by a JSON string. comment MAY be present.
+
+2.7.2.10. deleted
+
+ deleted represents a setting that allows object references to be
+ revoked. Revoked object references are not actionable and exist
+ merely to inform other instances of a revocation.
+
+ deleted is represented by a JSON boolean. deleted MUST be present.
+
+2.7.2.11. object_uuid
+
+ object_uuid represents the Universally Unique IDentifier (UUID)
+ [RFC4122] of the object that the given object reference belongs to.
+ The object_uuid MUST be preserved to preserve the object reference's
+ association with the object.
+
+2.7.2.12. referenced_uuid
+
+ referenced_uuid represents the Universally Unique IDentifier (UUID)
+ [RFC4122] of the object or attribute that is being referenced by the
+ object reference. The referenced_uuid MUST be preserved to preserve
+ the object reference's association with the object or attribute.
+
+2.8. Tag
+
+ A tag is a simple method to classify an event with a simple string.
+ The tag name can be freely chosen. The tag name can be also chosen
+ from a fixed machine-tag vocabulary called MISP taxonomies[[MISP-T]].
+ When an event is distributed outside an organisation, the use of MISP
+ taxonomies[[MISP-T]] is RECOMMENDED to ensure a coherent naming of
+ the tags. A tag is represented as a JSON array where each element
+ describes each tag associated. A tag array SHALL be at event level
+ or attribute level. A tag element is described with a name, id,
+ colour and exportable flag.
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 30]
+
+Internet-Draft MISP core format August 2018
+
+
+ exportable represents a setting if the tag is kept local or
+ exportable to other MISP instances. exportable is represented by a
+ JSON boolean. id is a human-readable identifier that references the
+ tag on the local instance. colour represents an RGB value of the tag.
+
+ name MUST be present. colour, id and exportable SHALL be present.
+
+2.8.1. Sample Tag
+
+ "Tag": [{
+ "exportable": true,
+ "colour": "#ffffff",
+ "name": "tlp:white",
+ "id": "2" }]
+
+2.9. Sighting
+
+ A sighting is an ascertainment which describes whether an attribute
+ has been seen under a given set of conditions. The sighting can
+ include the organisation who sighted the attribute or can be
+ anonymised. Sighting is composed of a JSON array in which each
+ element describes one singular instance of a sighting. A sighting
+ element is a JSON object composed of the following values:
+
+ type MUST be present. type describes the type of a sighting. MISP
+ allows 3 default types:
+
+ +------------+------------------------------------------------------+
+ | Sighting | Description |
+ | type | |
+ +------------+------------------------------------------------------+
+ | 0 | denotes an attribute which has been seen |
+ | 1 | denotes an attribute which has been seen and |
+ | | confirmed as false-positive |
+ | 2 | denotes an attribute which will be expired at the |
+ | | time of the sighting |
+ +------------+------------------------------------------------------+
+
+ uuid MUST be present. uuid references the uuid of the sighted
+ attribute.
+
+ date_sighting MUST be present. date_sighting is expressed in seconds
+ (decimal) elapsed since 1st of January 1970 (Unix timestamp).
+ date_sighting represents when the referenced attribute, designated by
+ its uuid, is sighted.
+
+ source MAY be present. source is represented as a JSON string and
+ represents the human-readable version of the sighting source, which
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 31]
+
+Internet-Draft MISP core format August 2018
+
+
+ can be a given piece of software (e.g. SIEM), device or a specific
+ analytical process.
+
+ id, event_id and attribute_id MAY be present.
+
+ id represents the human-readable identifier of the sighting reference
+ which belongs to a specific MISP instance. event_id represents the
+ human-readable identifier of the event referenced by the sighting and
+ belongs to a specific MISP instance. attribute_id represents the
+ human-readable identifier of the attribute referenced by the sighting
+ and belongs to a specific MISP instance.
+
+ org_id MAY be present along the JSON object describing the
+ organisation. If the org_id is not present, the sighting is
+ considered as anonymised.
+
+ org_id represents the human-readable identifier of the organisation
+ which did the sighting and belongs to a specific MISP instance.
+
+ A human-readable identifier MUST be represented as an unsigned
+ integer.
+
+2.9.1. Sample Sighting
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 32]
+
+Internet-Draft MISP core format August 2018
+
+
+"Sighting": [
+ {
+ "id": "13599",
+ "attribute_id": "1201615",
+ "event_id": "10164",
+ "org_id": "2",
+ "date_sighting": "1517581400",
+ "uuid": "5a747459-41b4-4826-9b29-42dd950d210f",
+ "source": "M2M-CIRCL",
+ "type": "0",
+ "Organisation": {
+ "id": "2",
+ "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f",
+ "name": "CIRCL"
+ }
+ },
+ {
+ "id": "13601",
+ "attribute_id": "1201615",
+ "event_id": "10164",
+ "org_id": "2",
+ "date_sighting": "1517581401",
+ "uuid": "5a74745a-a190-4d04-b719-4916950d210f",
+ "source": "M2M-CIRCL",
+ "type": "0",
+ "Organisation": {
+ "id": "2",
+ "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f",
+ "name": "CIRCL"
+ }
+ }
+ ]
+
+2.10. Galaxy
+
+ A galaxy is a simple method to express a large object called cluster
+ that can be attached to MISP events. A cluster can be composed of
+ one or more elements. Elements are expressed as key-values.
+
+2.10.1. Sample Galaxy
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 33]
+
+Internet-Draft MISP core format August 2018
+
+
+"Galaxy": [ {
+ "id": "18",
+ "uuid": "698774c7-8022-42c4-917f-8d6e4f06ada3",
+ "name": "Threat Actor",
+ "type": "threat-actor",
+ "description": "Threat actors are characteristics of malicious actors
+ (or adversaries) representing a cyber attack threat
+ including presumed intent and historically observed behaviour.",
+ "version": "1",
+ "GalaxyCluster": [
+ {
+ "id": "1699",
+ "uuid": "7cdff317-a673-4474-84ec-4f1754947823",
+ "type": "threat-actor",
+ "value": "Anunak",
+ "tag_name": "misp-galaxy:threat-actor=\"Anunak\"",
+ "description": "Groups targeting financial organizations
+ or people with significant financial assets.",
+ "galaxy_id": "18",
+ "source": "MISP Project",
+ "authors": [
+ "Alexandre Dulaunoy",
+ "Florian Roth",
+ "Thomas Schreck",
+ "Timo Steffens",
+ "Various"
+ ],
+ "tag_id": "111",
+ "meta": {
+ "synonyms": [
+ "Carbanak",
+ "Carbon Spider"
+ ],
+ "country": [
+ "RU"
+ ],
+ "motive": [
+ "Cybercrime"
+ ]
+ }
+ }
+ ]
+ }
+ ]
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 34]
+
+Internet-Draft MISP core format August 2018
+
+
+3. JSON Schema
+
+ The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP
+ core format as literally described before. The JSON Schema is used
+ to validate MISP events at creation time or parsing.
+
+ {
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "title": "Validator for misp events",
+ "id": "https://github.com/MISP/MISP/blob/2.4/format/2.4/schema.json",
+ "defs": {
+ "org": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "uuid"
+ ]
+ },
+ "orgc": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "uuid"
+ ]
+ },
+ "sharing_group": {
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 35]
+
+Internet-Draft MISP core format August 2018
+
+
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "releasability": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "organisation_uuid": {
+ "type": "string"
+ },
+ "org_id": {
+ "type": "string"
+ },
+ "sync_user_id": {
+ "type": "string"
+ },
+ "active": {
+ "type": "boolean"
+ },
+ "created": {
+ "type": "string"
+ },
+ "modified": {
+ "type": "string"
+ },
+ "local": {
+ "type": "boolean"
+ },
+ "roaming": {
+ "type": "boolean"
+ },
+ "Organisation": {
+ "$ref": "#/defs/org"
+ },
+ "SharingGroupOrg": {
+ "type": "array",
+ "uniqueItems": true,
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 36]
+
+Internet-Draft MISP core format August 2018
+
+
+ "items": {
+ "$ref": "#/defs/sharing_group_org"
+ }
+ },
+ "SharingGroupServer": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/sharing_group_server"
+ }
+ },
+ "required": [
+ "uuid"
+ ]
+ },
+ "required": [
+ "uuid"
+ ]
+ },
+ "sharing_group_org": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "sharing_group_id": {
+ "type": "string"
+ },
+ "org_id": {
+ "type": "string"
+ },
+ "extend": {
+ "type": "boolean"
+ },
+ "Organisation": {
+ "$ref": "#/defs/org"
+ }
+ }
+ },
+ "sharing_group_server": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "sharing_group_id": {
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 37]
+
+Internet-Draft MISP core format August 2018
+
+
+ "type": "string"
+ },
+ "server_id": {
+ "type": "string"
+ },
+ "all_orgs": {
+ "type": "boolean"
+ },
+ "Server": {
+ "$ref": "#/defs/server"
+ }
+ }
+ },
+ "server": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ }
+ },
+ "object": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "uuid": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "event_id": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "template_uuid": {
+ "type": "string"
+ },
+ "template_version": {
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 38]
+
+Internet-Draft MISP core format August 2018
+
+
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meta-category": {
+ "type": "string"
+ },
+ "deleted": {
+ "type": "boolean"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "distribution": {
+ "type": "string"
+ },
+ "sharing_group_id": {
+ "type": "string"
+ },
+ "comment": {
+ "type": "string"
+ },
+ "ObjectReference": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/objectreference"
+ }
+ },
+ "Attribute": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/attribute"
+ }
+ }
+ }
+ },
+ "sighthing": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "attribute_id": {
+ "type": "string"
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 39]
+
+Internet-Draft MISP core format August 2018
+
+
+ },
+ "event_id": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "org_id": {
+ "type": "string"
+ },
+ "date_sighting": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "Organisation": {
+ "$ref": "#/defs/organisation"
+ }
+ }
+ },
+ "organisation": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ }
+ },
+ "objectreference": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "deleted": {
+ "type": "boolean"
+ },
+ "object_id": {
+ "type": "string"
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 40]
+
+Internet-Draft MISP core format August 2018
+
+
+ },
+ "event_id": {
+ "type": "string"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "referenced_id": {
+ "type": "string"
+ },
+ "referenced_uuid": {
+ "type": "string"
+ },
+ "referenced_type": {
+ "type": "string"
+ },
+ "relationship_type": {
+ "type": "string"
+ },
+ "object_uuid": {
+ "type": "string"
+ },
+ "comment": {
+ "type": "string"
+ },
+ "Object": {
+ "$ref": "#/defs/object"
+ }
+ }
+ },
+ "attribute": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "old_id": {
+ "type": "string"
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 41]
+
+Internet-Draft MISP core format August 2018
+
+
+ },
+ "type": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "to_ids": {
+ "type": "boolean"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "event_id": {
+ "type": "string"
+ },
+ "event_uuid": {
+ "type": "string"
+ },
+ "proposal_to_delete": {
+ "type": "boolean"
+ },
+ "validationIssue": {
+ "type": "boolean"
+ },
+ "Org": {
+ "$ref": "#/defs/organisation"
+ },
+ "org_id": {
+ "type": "string"
+ },
+ "distribution": {
+ "type": "string"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "comment": {
+ "type": "string"
+ },
+ "sharing_group_id": {
+ "type": "string"
+ },
+ "deleted": {
+ "type": "boolean"
+ },
+ "disable_correlation": {
+ "type": "boolean"
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 42]
+
+Internet-Draft MISP core format August 2018
+
+
+ },
+ "value": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "object_relation": {
+ "type": ["string", "null"]
+ },
+ "object_id": {
+ "type": "string"
+ },
+ "SharingGroup": {
+ "$ref": "#/defs/sharing_group"
+ },
+ "ShadowAttribute": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/attribute"
+ }
+ },
+ "Sighting": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/sighthing"
+ }
+ },
+ "Galaxy": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/galaxy"
+ }
+ },
+ "Tag": {
+ "uniqueItems": true,
+ "type": "array",
+ "items": {
+ "$ref": "#/defs/tag"
+ }
+ }
+ }
+ },
+ "event": {
+ "type": "object",
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 43]
+
+Internet-Draft MISP core format August 2018
+
+
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "orgc_id": {
+ "type": "string"
+ },
+ "org_id": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "extends_uuid": {
+ "type": "string"
+ },
+ "threat_level_id": {
+ "type": "string"
+ },
+ "info": {
+ "type": "string"
+ },
+ "published": {
+ "type": "boolean"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "attribute_count": {
+ "type": "string"
+ },
+ "analysis": {
+ "type": "string"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "distribution": {
+ "type": "string"
+ },
+ "proposal_email_lock": {
+ "type": "boolean"
+ },
+ "locked": {
+ "type": "boolean"
+ },
+ "publish_timestamp": {
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 44]
+
+Internet-Draft MISP core format August 2018
+
+
+ "type": "string"
+ },
+ "sharing_group_id": {
+ "type": "string"
+ },
+ "disable_correlation": {
+ "type": "boolean"
+ },
+ "event_creator_email": {
+ "type": "string"
+ },
+ "Org": {
+ "$ref": "#/defs/org"
+ },
+ "Orgc": {
+ "$ref": "#/defs/org"
+ },
+ "SharingGroup": {
+ "$ref": "#/defs/sharing_group"
+ },
+ "Attribute": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/attribute"
+ }
+ },
+ "ShadowAttribute": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/attribute"
+ }
+ },
+ "RelatedEvent": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "Event":{
+ "$ref": "#/defs/event"
+ }
+ }
+ }
+ },
+ "Galaxy": {
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 45]
+
+Internet-Draft MISP core format August 2018
+
+
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/galaxy"
+ }
+ },
+ "Object": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/object"
+ }
+ },
+ "Tag": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/tag"
+ }
+ }
+ }
+ },
+ "tag": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "colour": {
+ "type": "string"
+ },
+ "exportable": {
+ "type": "boolean"
+ },
+ "hide_tag": {
+ "type": "boolean"
+ },
+ "user_id": {
+ "type": "string"
+ }
+ }
+ },
+ "galaxy": {
+ "type": "object",
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 46]
+
+Internet-Draft MISP core format August 2018
+
+
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "icon": {
+ "type": "string"
+ },
+ "namespace": {
+ "type": "string"
+ },
+ "GalaxyCluster": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "$ref": "#/defs/galaxy_cluster"
+ }
+ }
+ }
+ },
+ "galaxy_cluster": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 47]
+
+Internet-Draft MISP core format August 2018
+
+
+ "value": {
+ "type": "string"
+ },
+ "tag_name": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "galaxy_id": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "authors": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "tag_id": {
+ "type": "string"
+ },
+ "meta": {
+ "type": "object"
+ }
+ }
+ }
+ },
+ "type": "object",
+ "properties": {
+ "Event": {
+ "$ref": "#/defs/event"
+ }
+ },
+ "required": [
+ "Event"
+ ]
+ }
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 48]
+
+Internet-Draft MISP core format August 2018
+
+
+4. Manifest
+
+ MISP events can be shared over an HTTP repository, a file package or
+ USB key. A manifest file is used to provide an index of MISP events
+ allowing to only fetch the recently updated files without the need to
+ parse each json file.
+
+4.1. Format
+
+ A manifest file is a simple JSON file named manifest.json in a
+ directory where the MISP events are located. Each MISP event is a
+ file located in the same directory with the event uuid as filename
+ with the json extension.
+
+ The manifest format is a JSON object composed of a dictionary where
+ the field is the uuid of the event.
+
+ Each uuid is composed of a JSON object with the following fields
+ which came from the original event referenced by the same uuid:
+
+ o info (MUST)
+
+ o Orgc object (MUST)
+
+ o analysis (SHALL)
+
+ o timestamp (MUST)
+
+ o date (MUST)
+
+ o threat_level_id (SHALL)
+
+ In addition to the fields originating from the event, the following
+ fields can be added:
+
+ o integrity:sha256 represents the SHA256 value in hexadecimal
+ representation of the associated MISP event file to ensure
+ integrity of the file. (SHOULD)
+
+ o integrity:pgp represents a detached PGP signature [RFC4880] of the
+ associated MISP event file to ensure integrity of the file.
+ (SHOULD)
+
+ If a detached PGP signature is used for each MISP event, a detached
+ PGP signature is a MUST to ensure integrity of the manifest file. A
+ detached PGP signature for a manifest file is a manifest.json.asc
+ file containing the PGP signature.
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 49]
+
+Internet-Draft MISP core format August 2018
+
+
+4.1.1. Sample Manifest
+
+{
+ "57c6ac4c-c60c-4f79-a38f-b666950d210f": {
+ "info": "Malspam 2016-08-31 (.wsf in .zip) - campaign: Photo",
+ "Orgc": {
+ "id": "2",
+ "name": "CIRCL",
+ "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f"
+ },
+ "analysis": "0",
+ "Tag": [
+ {
+ "colour": "#3d7a00",
+ "name": "circl:incident-classification=\"malware\""
+ },
+ {
+ "colour": "#ffffff",
+ "name": "tlp:white"
+ }
+ ],
+ "timestamp": "1472638251",
+ "date": "2016-08-31",
+ "threat_level_id": "3"
+ },
+ "5720accd-dd28-45f8-80e5-4605950d210f": {
+ "info": "Malspam 2016-04-27 - Locky",
+ "Orgc": {
+ "id": "2",
+ "name": "CIRCL"
+ },
+ "analysis": "2",
+ "Tag": [
+ {
+ "colour": "#ffffff",
+ "name": "tlp:white"
+ },
+ {
+ "colour": "#3d7a00",
+ "name": "circl:incident-classification=\"malware\""
+ },
+ {
+ "colour": "#2c4f00",
+ "name": "malware_classification:malware-category=\"Ransomware\""
+ }
+ ],
+ "timestamp": "1461764231",
+ "date": "2016-04-27",
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 50]
+
+Internet-Draft MISP core format August 2018
+
+
+ "threat_level_id": "3"
+ }
+}
+
+5. Implementation
+
+ MISP format is implemented by different software including the MISP
+ threat sharing platform and libraries like PyMISP [MISP-P].
+ Implementations use the format as an export/import mechanism, staging
+ transport format or synchronisation format as used in the MISP core
+ platform. MISP format doesn't impose any restriction on the data
+ representation of the format in data-structure of other
+ implementations.
+
+6. Security Considerations
+
+ MISP events might contain sensitive or confidential information.
+ Adequate access control and encryption measures shall be implemented
+ to ensure the confidentiality of the MISP events.
+
+ Adversaries might include malicious content in MISP events and
+ attributes. Implementation MUST consider the input of malicious
+ inputs beside the standard threat information that might already
+ include malicious intended inputs.
+
+7. Acknowledgements
+
+ The authors wish to thank all the MISP community who are supporting
+ the creation of open standards in threat intelligence sharing. A
+ special thank to Nicolas Bareil for the review of the JSON Schema.
+
+8. References
+
+9. References
+
+9.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,
+ .
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122,
+ DOI 10.17487/RFC4122, July 2005,
+ .
+
+
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 51]
+
+Internet-Draft MISP core format August 2018
+
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880,
+ DOI 10.17487/RFC4880, November 2007,
+ .
+
+ [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+ Interchange Format", STD 90, RFC 8259,
+ DOI 10.17487/RFC8259, December 2017,
+ .
+
+9.2. Informative References
+
+ [JSON-SCHEMA]
+ Wright, A., "JSON Schema: A Media Type for Describing JSON
+ Documents", 2016,
+ .
+
+ [MISP-P] Community, M., "MISP Project - Malware Information Sharing
+ Platform and Threat Sharing", .
+
+ [MISP-R] Community, M., "MISP Object Relationship Types - common
+ vocabulary of relationships", .
+
+ [MISP-T] Community, M., "MISP Taxonomies - shared and common
+ vocabularies of tags",
+ .
+
+Authors' Addresses
+
+ Alexandre Dulaunoy
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1160
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: alexandre.dulaunoy@circl.lu
+
+
+ Andras Iklody
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1160
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: andras.iklody@circl.lu
+
+
+
+Dulaunoy & Iklody Expires February 9, 2019 [Page 52]
diff --git a/rfc/misp-standard-galaxy-format.html b/rfc/misp-standard-galaxy-format.html
new file mode 100644
index 0000000..2051306
--- /dev/null
+++ b/rfc/misp-standard-galaxy-format.html
@@ -0,0 +1,1006 @@
+
+
+
+
+
+
+ MISP galaxy format
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [MISP-G][MISP-G-DOC] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
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 https://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 March 24, 2019.
Copyright (c) 2018 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 (https://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 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.
Sharing threat information became a fundamental requirements on 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. Some of these informations, such as malware or threat actors are common to several security events. MISP galaxy is a public repository [MISP-G] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
+
In the MISP galaxy context, clusters help analysts to give more informations about their cybersecurity events, indicators or threats. MISP galaxies can be used for classification, filtering, triggering actions or visualisation depending on their use in threat intelligence platforms such as MISP [MISP-P].
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].
The MISP galaxy format uses the JSON [RFC8259] format. Each galaxy is represented as a JSON object with meta information including the following fields: name, uuid, description, version, type, authors, source, values, category.
+
name defines the name of the galaxy. The name is represented as a string and MUST be present. The uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the object reference. The uuid MUST be preserved. For any updates or transfer of the same object reference. UUID version 4 is RECOMMENDED when assigning it to a new object reference and MUST be present. The description is represented as a string and MUST be present. The uuid is represented as a string and MUST be present. The version is represented as a decimal and MUST be present. The type is represented as a string and MUST be present and MUST match the name of the galaxy file. The source is represented as a string and MUST be present. Authors are represented as an array containing one or more authors and MUST be present. The category is represented as a string and MUST be present and describes the overall category of the galaxy such as tool or actor.
+
Values are represented as an array containing one or more values and MUST be present. Values defines all values available in the galaxy.
The values array contains one or more JSON objects which represent all the possible values in the galaxy. The JSON object contains four fields: value, description, uuid and meta. The value is represented as a string and MUST be present. The description is represented as a string and SHOULD be present. The meta or metadata is represented as a JSON list and SHOULD be present. The uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the value reference. The uuid SHOULD can be present and MUST be preserved.
Related contains a list of JSON key value pairs which describe the related values in this galaxy cluster or to other galaxy clusters. The JSON object contains three fields, dest-uuid, type and tags. The dest-uuid represents the target UUID which encompasses a relation of some type. The dest-uuid is represented as a string and MUST be present. The type is represented as a string and MUST be present and SHOULD be selected from the relationship types available in MISP objects [MISP-R]. The tags is a list of string which labels the related relationship such as the level of similarities, level of certainty, trust or confidence in the relationship, false-positive. A tag is represented in machine tag format which is a string an SHOULD be present.
Meta contains a list of custom defined JSON key value pairs. Users SHOULD reuse commonly used keys such as complexity, effectiveness, country, possible_issues, colour, motive, impact, refs, synonyms, status, date, encryption, extensions, ransomnotes, ransomnotes-filenames, ransomnotes-refs, suspected-victims, suspected-state-sponsor, type-of-incident, target-category, cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-incident, cfr-target-category, attribution-confidence, payment-method, price wherever applicable.
+
refs, synonyms SHALL be used to give further informations. refs is represented as an array containing one or more strings and SHALL be present. synonyms is represented as an array containing one or more strings and SHALL be present.
+
date, status MAY be used to give time information about an cluster. date is represented as a string describing a time or period and SHALL be present. status is represented as a string describing the current status of the clusters. It MAY also describe a time or period and SHALL be present.
+
colour fields MAY be used at predicates or values level to set a specify colour that MAY be used by the implementation. The colour field is described as an RGB colour fill in hexadecimal representation.
+
complexity, effectiveness, impact, possibleissues MAY be used to give further information in preventive-measure galaxy. complexity is represented by an enumerated value from a fixed vocabulary and SHALL be present. effectiveness is represented by an enumerated value from a fixed vocabulary and SHALL be present. impact is represented by an enumerated value from a fixed vocabulary and SHALL be present. possibleissues is represented as a string and SHOULD be present.
+
Example use of the complexity, effectiveness, impact, possible_issues fields in the preventive-measure galaxy:
country, motive MAY be used to give further information in threat-actor galaxy. country is represented as a string and SHOULD be present. motive is represented as a string and SHOULD be present.
+
Example use of the country, motive fields in the threat-actor galaxy:
encryption, extensions, ransomnotes, ransomnotes-filenames, ransomnotes-refs, payment-method, price MAY be used to give further information in ransomware galaxy. encryption is represented as a string and SHALL be present. extensions is represented as an array containing one or more strings and SHALL be present. ransomnotes is represented as an array containing one or more strings ans SHALL be present. ransomnotes-filenames is represented as an array containing one or more strings ans SHALL be present. ransomnotes-refs is represented as an array containing one or more strings ans SHALL be present. payment-method is represented as a string and SHALL be present. price is represented as a string and SHALL be present.
+
Example use of the encryption, extensions, ransomnotes fields in the ransomware galaxy:
+
{
+ "description": "Similar to Samas and BitPaymer, Ryuk is specifically used to target enterprise environments. Code comparison between versions of Ryuk and Hermes ransomware indicates that Ryuk was derived from the Hermes source code and has been under steady development since its release. Hermes is commodity ransomware that has been observed for sale on forums and used by multiple threat actors. However, Ryuk is only used by GRIM SPIDER and, unlike Hermes, Ryuk has only been used to target enterprise environments. Since Ryuk’s appearance in August, the threat actors operating it have netted over 705.80 BTC across 52 transactions for a total current value of $3,701,893.98 USD.",
+ "meta": {
+ "ransomnotes-filenames": [
+ "RyukReadMe.txt"
+ ],
+ "ransomnotes-refs": [
+ "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig3.png",
+ "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig4.png"
+ ],
+ "refs": [
+ "https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/"
+ ]
+ },
+ "uuid": "f9464c80-b776-4f37-8682-ffde0cf8f718",
+ "value": "Ryuk ransomware"
+}
+
+
Example use of the payment-method, price fields in the ransomware galaxy:
+
{
+ "description": "This is most likely to affect English speaking users, since the note is written in English. English is understood worldwide, thus anyone can be harmed. The hacker spread the virus using email spam, fake updates, and harmful attachments. All your files are compromised including music, MS Office, Open Office, pictures, videos, shared online files etc..",
+ "meta": {
+ "date": "March 2017",
+ "encryption": "AES-128",
+ "extensions": [
+ ".enc"
+ ],
+ "payment-method": "Bitcoin",
+ "price": "0.1",
+ "ransomnotes": [
+ "Blocked Your computer has been blocked All your files are encrypted. To access your PC, you need to send to Bitcoin at the address below loading Step 1: Go to xxxxs : //wvw.coinbase.com/ siqnup Step 2: Create an account and follow the instructions Step 3: Go to the \"Buy Bitcoins\" section and then buy Bitcoin Step 4: Go to the \"Send\" section, enter the address above and the amount (0.1 Bitcoin) Step 5: Click on the button below to verify the payment, your files will be decrypted and the virus will disappear 'Check' If you try to bypass the lock, all files will be published on the Internet, as well as your login for all sites."
+ ],
+ "refs": [
+ "https://id-ransomware.blogspot.co.il/2017/03/cryptomeister-ransomware.html"
+ ]
+ },
+ "uuid": "4c76c845-c5eb-472c-93a1-4178f86c319b",
+ "value": "CryptoMeister Ransomware"
+}
+
+
source-uuid, target-uuid SHALL be used to describe relationships. source-uuid and target-uuid represent the Universally Unique IDentifier (UUID) [RFC4122] of the value reference. source-uuid and target-uuid MUST be preserved.
+
Example use of the source-uuid, target-uuid fields in the mitre-enterprise-attack-relationship galaxy:
cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-incident and cfr-target-category MAY be used to report information gathered from CFR's (Council on Foreign Relations) [CFR] Cyber Operations Tracker. cfr-suspected-victims is represented as an array containing one or more strings and SHALL be present. cfr-suspected-state-sponsor is represented as a string and SHALL be present. cfr-type-of-incident is represented as a string or an array and SHALL be present. RECOMMENDED but not exhaustive list of possible values for cfr-type-of-incident includes "Espionage", "Denial of service", "Sabotage". cfr-target-category is represented as an array containing one or more strings ans SHALL be present. RECOMMENDED but not exhaustive list of possible values for cfr-target-category includes "Private sector", "Government", "Civil society", "Military".
+
Example use of the cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-incident, cfr-target-category fields in the threat-actor galaxy:
attribution-confidence MAY be used to indicate the confidence about an attribution given by country or cfr-suspected-state-sponsor. attribution-confidence is represented on a scale from 0 to 100, where 50 means "no information", the values under 50 mean "probably not, almost certainly not to impossibility", the values above 50 means "from probable, almost certain to certainty" and SHALL be present if country or cfr-suspected-state-sponsor are present.
+
Impossibility no information Certainty
+ +
+ |
+ +-------------------+------------------>
+
+ 0 50 100
+
+
+
+
diff --git a/rfc/misp-standard-galaxy-format.txt b/rfc/misp-standard-galaxy-format.txt
new file mode 100644
index 0000000..1c3c9f5
--- /dev/null
+++ b/rfc/misp-standard-galaxy-format.txt
@@ -0,0 +1,896 @@
+
+
+
+
+Network Working Group A. Dulaunoy
+Internet-Draft A. Iklody
+Expires: March 24, 2019 D. Servili
+ CIRCL
+ September 20, 2018
+
+
+ MISP galaxy format
+
+Abstract
+
+ This document describes the MISP galaxy format which describes a
+ simple JSON format to represent galaxies and clusters that can be
+ attached to MISP events or attributes. A public directory of MISP
+ galaxies is available and relies on the MISP galaxy format. MISP
+ galaxies are used to add further informations on a MISP event. MISP
+ galaxy is a public repository [MISP-G] [MISP-G-DOC] of known malware,
+ threats actors and various other collections of data that can be used
+ to mark, classify or label data in threat information sharing.
+
+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 https://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 March 24, 2019.
+
+Copyright Notice
+
+ Copyright (c) 2018 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
+ (https://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, et al. Expires March 24, 2019 [Page 1]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. values . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.3. related . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.4. meta . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1. MISP galaxy format - galaxy . . . . . . . . . . . . . . . 9
+ 3.2. MISP galaxy format - clusters . . . . . . . . . . . . . . 10
+ 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.1. Normative References . . . . . . . . . . . . . . . . . . 14
+ 5.2. Informative References . . . . . . . . . . . . . . . . . 14
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
+
+1. Introduction
+
+ Sharing threat information became a fundamental requirements on 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. Some of these informations, such as malware or
+ threat actors are common to several security events. MISP galaxy is
+ a public repository [MISP-G] of known malware, threats actors and
+ various other collections of data that can be used to mark, classify
+ or label data in threat information sharing.
+
+ In the MISP galaxy context, clusters help analysts to give more
+ informations about their cybersecurity events, indicators or threats.
+ MISP galaxies can be used for classification, filtering, triggering
+ actions or visualisation depending on their use in threat
+ intelligence platforms such as MISP [MISP-P].
+
+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].
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 2]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+2. Format
+
+ A cluster is composed of a value (MUST), a description (OPTIONAL) and
+ metadata (OPTIONAL).
+
+ Clusters are represented as a JSON [RFC8259] dictionary.
+
+2.1. Overview
+
+ The MISP galaxy format uses the JSON [RFC8259] format. Each galaxy
+ is represented as a JSON object with meta information including the
+ following fields: name, uuid, description, version, type, authors,
+ source, values, category.
+
+ name defines the name of the galaxy. The name is represented as a
+ string and MUST be present. The uuid represents the Universally
+ Unique IDentifier (UUID) [RFC4122] of the object reference. The uuid
+ MUST be preserved. For any updates or transfer of the same object
+ reference. UUID version 4 is RECOMMENDED when assigning it to a new
+ object reference and MUST be present. The description is represented
+ as a string and MUST be present. The uuid is represented as a string
+ and MUST be present. The version is represented as a decimal and
+ MUST be present. The type is represented as a string and MUST be
+ present and MUST match the name of the galaxy file. The source is
+ represented as a string and MUST be present. Authors are represented
+ as an array containing one or more authors and MUST be present. The
+ category is represented as a string and MUST be present and describes
+ the overall category of the galaxy such as tool or actor.
+
+ Values are represented as an array containing one or more values and
+ MUST be present. Values defines all values available in the galaxy.
+
+2.2. values
+
+ The values array contains one or more JSON objects which represent
+ all the possible values in the galaxy. The JSON object contains four
+ fields: value, description, uuid and meta. The value is represented
+ as a string and MUST be present. The description is represented as a
+ string and SHOULD be present. The meta or metadata is represented as
+ a JSON list and SHOULD be present. The uuid represents the
+ Universally Unique IDentifier (UUID) [RFC4122] of the value
+ reference. The uuid SHOULD can be present and MUST be preserved.
+
+2.3. related
+
+ Related contains a list of JSON key value pairs which describe the
+ related values in this galaxy cluster or to other galaxy clusters.
+ The JSON object contains three fields, dest-uuid, type and tags. The
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 3]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ dest-uuid represents the target UUID which encompasses a relation of
+ some type. The dest-uuid is represented as a string and MUST be
+ present. The type is represented as a string and MUST be present and
+ SHOULD be selected from the relationship types available in MISP
+ objects [MISP-R]. The tags is a list of string which labels the
+ related relationship such as the level of similarities, level of
+ certainty, trust or confidence in the relationship, false-positive.
+ A tag is represented in machine tag format which is a string an
+ SHOULD be present.
+
+"related": [ {
+ "dest-uuid": "f873db71-3d53-41d5-b141-530675ade27a",
+ "type": "similar",
+ "tags": ["estimative-language:likelihood-probability=\"very-likely\""]
+} ]
+
+2.4. meta
+
+ Meta contains a list of custom defined JSON key value pairs. Users
+ SHOULD reuse commonly used keys such as complexity, effectiveness,
+ country, possible_issues, colour, motive, impact, refs, synonyms,
+ status, date, encryption, extensions, ransomnotes, ransomnotes-
+ filenames, ransomnotes-refs, suspected-victims, suspected-state-
+ sponsor, type-of-incident, target-category, cfr-suspected-victims,
+ cfr-suspected-state-sponsor, cfr-type-of-incident, cfr-target-
+ category, attribution-confidence, payment-method, price wherever
+ applicable.
+
+ refs, synonyms SHALL be used to give further informations. refs is
+ represented as an array containing one or more strings and SHALL be
+ present. synonyms is represented as an array containing one or more
+ strings and SHALL be present.
+
+ date, status MAY be used to give time information about an cluster.
+ date is represented as a string describing a time or period and SHALL
+ be present. status is represented as a string describing the current
+ status of the clusters. It MAY also describe a time or period and
+ SHALL be present.
+
+ colour fields MAY be used at predicates or values level to set a
+ specify colour that MAY be used by the implementation. The colour
+ field is described as an RGB colour fill in hexadecimal
+ representation.
+
+ complexity, effectiveness, impact, possible_issues MAY be used to
+ give further information in preventive-measure galaxy. complexity is
+ represented by an enumerated value from a fixed vocabulary and SHALL
+ be present. effectiveness is represented by an enumerated value from
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 4]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ a fixed vocabulary and SHALL be present. impact is represented by an
+ enumerated value from a fixed vocabulary and SHALL be present.
+ possible_issues is represented as a string and SHOULD be present.
+
+ Example use of the complexity, effectiveness, impact, possible_issues
+ fields in the preventive-measure galaxy:
+
+{
+ "meta": {
+ "refs": [
+ "http://www.windowsnetworking.com/kbase/WindowsTips/WindowsXP/AdminTips/Customization/DisableWindowsScriptingHostWSH.html"
+ ],
+ "complexity": "Low",
+ "effectiveness": "Medium",
+ "impact": "Medium",
+ "type": [
+ "GPO"
+ ],
+ "possible_issues": "Administrative VBS scripts on Workstations"
+ },
+ "value": "Disable WSH",
+ "description": "Disable Windows Script Host",
+ "uuid": "e6df1619-f8b3-476c-b5cf-22b4c9e9dd7f"
+}
+
+ country, motive MAY be used to give further information in threat-
+ actor galaxy. country is represented as a string and SHOULD be
+ present. motive is represented as a string and SHOULD be present.
+
+ Example use of the country, motive fields in the threat-actor galaxy:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 5]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ {
+ "meta": {
+ "country": "CN",
+ "synonyms": [
+ "APT14",
+ "APT 14",
+ "QAZTeam",
+ "ALUMINUM"
+ ],
+ "refs": [
+ "http://www.crowdstrike.com/blog/whois-anchor-panda/"
+ ],
+ "motive": "Espionage",
+ "attribution-confidence": 50
+ },
+ "value": "Anchor Panda",
+ "description": "PLA Navy",
+ "uuid": "c82c904f-b3b4-40a2-bf0d-008912953104"
+ }
+
+ encryption, extensions, ransomnotes, ransomnotes-filenames,
+ ransomnotes-refs, payment-method, price MAY be used to give further
+ information in ransomware galaxy. encryption is represented as a
+ string and SHALL be present. extensions is represented as an array
+ containing one or more strings and SHALL be present. ransomnotes is
+ represented as an array containing one or more strings ans SHALL be
+ present. ransomnotes-filenames is represented as an array containing
+ one or more strings ans SHALL be present. ransomnotes-refs is
+ represented as an array containing one or more strings ans SHALL be
+ present. payment-method is represented as a string and SHALL be
+ present. price is represented as a string and SHALL be present.
+
+ Example use of the encryption, extensions, ransomnotes fields in the
+ ransomware galaxy:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 6]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+{
+ "description": "Similar to Samas and BitPaymer, Ryuk is specifically used to target enterprise environments. Code comparison between versions of Ryuk and Hermes ransomware indicates that Ryuk was derived from the Hermes source code and has been under steady development since its release. Hermes is commodity ransomware that has been observed for sale on forums and used by multiple threat actors. However, Ryuk is only used by GRIM SPIDER and, unlike Hermes, Ryuk has only been used to target enterprise environments. Since Ryuk's appearance in August, the threat actors operating it have netted over 705.80 BTC across 52 transactions for a total current value of $3,701,893.98 USD.",
+ "meta": {
+ "ransomnotes-filenames": [
+ "RyukReadMe.txt"
+ ],
+ "ransomnotes-refs": [
+ "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig3.png",
+ "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig4.png"
+ ],
+ "refs": [
+ "https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/"
+ ]
+ },
+ "uuid": "f9464c80-b776-4f37-8682-ffde0cf8f718",
+ "value": "Ryuk ransomware"
+}
+
+ Example use of the payment-method, price fields in the ransomware
+ galaxy:
+
+{
+ "description": "This is most likely to affect English speaking users, since the note is written in English. English is understood worldwide, thus anyone can be harmed. The hacker spread the virus using email spam, fake updates, and harmful attachments. All your files are compromised including music, MS Office, Open Office, pictures, videos, shared online files etc..",
+ "meta": {
+ "date": "March 2017",
+ "encryption": "AES-128",
+ "extensions": [
+ ".enc"
+ ],
+ "payment-method": "Bitcoin",
+ "price": "0.1",
+ "ransomnotes": [
+ "Blocked Your computer has been blocked All your files are encrypted. To access your PC, you need to send to Bitcoin at the address below loading Step 1: Go to xxxxs : //wvw.coinbase.com/ siqnup Step 2: Create an account and follow the instructions Step 3: Go to the \"Buy Bitcoins\" section and then buy Bitcoin Step 4: Go to the \"Send\" section, enter the address above and the amount (0.1 Bitcoin) Step 5: Click on the button below to verify the payment, your files will be decrypted and the virus will disappear 'Check' If you try to bypass the lock, all files will be published on the Internet, as well as your login for all sites."
+ ],
+ "refs": [
+ "https://id-ransomware.blogspot.co.il/2017/03/cryptomeister-ransomware.html"
+ ]
+ },
+ "uuid": "4c76c845-c5eb-472c-93a1-4178f86c319b",
+ "value": "CryptoMeister Ransomware"
+}
+
+ source-uuid, target-uuid SHALL be used to describe relationships.
+ source-uuid and target-uuid represent the Universally Unique
+ IDentifier (UUID) [RFC4122] of the value reference. source-uuid and
+ target-uuid MUST be preserved.
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 7]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ Example use of the source-uuid, target-uuid fields in the mitre-
+ enterprise-attack-relationship galaxy:
+
+ {
+ "meta": {
+ "source-uuid": "222fbd21-fc4f-4b7e-9f85-0e6e3a76c33f",
+ "target-uuid": "2f1a9fd0-3b7c-4d77-a358-78db13adbe78"
+ },
+ "uuid": "cfc7da70-d7c5-4508-8f50-1c3107269633",
+ "value": "menuPass (G0045) uses EvilGrab (S0152)"
+ }
+
+ cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-
+ incident and cfr-target-category MAY be used to report information
+ gathered from CFR's (Council on Foreign Relations) [CFR] Cyber
+ Operations Tracker. cfr-suspected-victims is represented as an array
+ containing one or more strings and SHALL be present. cfr-suspected-
+ state-sponsor is represented as a string and SHALL be present. cfr-
+ type-of-incident is represented as a string or an array and SHALL be
+ present. RECOMMENDED but not exhaustive list of possible values for
+ cfr-type-of-incident includes "Espionage", "Denial of service",
+ "Sabotage". cfr-target-category is represented as an array containing
+ one or more strings ans SHALL be present. RECOMMENDED but not
+ exhaustive list of possible values for cfr-target-category includes
+ "Private sector", "Government", "Civil society", "Military".
+
+ Example use of the cfr-suspected-victims, cfr-suspected-state-
+ sponsor, cfr-type-of-incident, cfr-target-category fields in the
+ threat-actor galaxy:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 8]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+{
+ "meta": {
+ "country": "CN",
+ "refs": [
+ "https://www.fireeye.com/blog/threat-research/2015/12/the_eps_awakens.html",
+ "https://www.cfr.org/interactive/cyber-operations/apt-16"
+ ],
+ "cfr-suspected-victims": [
+ "Japan",
+ "Taiwan"
+ ],
+ "cfr-suspected-state-sponsor": "China",
+ "cfr-type-of-incident": "Espionage",
+ "cfr-target-category": [
+ "Private sector"
+ ],
+ "attribution-confidence": 50
+ },
+ "value": "APT 16",
+ "uuid": "1f73e14f-b882-4032-a565-26dc653b0daf"
+},
+
+ attribution-confidence MAY be used to indicate the confidence about
+ an attribution given by country or cfr-suspected-state-sponsor.
+ attribution-confidence is represented on a scale from 0 to 100, where
+ 50 means "no information", the values under 50 mean "probably not,
+ almost certainly not to impossibility", the values above 50 means
+ "from probable, almost certain to certainty" and SHALL be present if
+ country or cfr-suspected-state-sponsor are present.
+
+ Impossibility no information Certainty
+ +
+ |
+ +-------------------+------------------>
+
+ 0 50 100
+
+3. JSON Schema
+
+ The JSON Schema [JSON-SCHEMA] below defines the overall MISP galaxy
+ formats. The main format is the MISP galaxy format used for the
+ clusters.
+
+3.1. MISP galaxy format - galaxy
+
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 9]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+{
+ "$schema": "http://json-schema.org/schema#",
+ "title": "Validator for misp-galaxies - Galaxies",
+ "id": "https://www.github.com/MISP/misp-galaxies/schema_galaxies.json",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "version": {
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "icon": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "namespace": {
+ "type": "string"
+ },
+ "kill_chain_order": {
+ "type": "object"
+ }
+ },
+ "required": [
+ "description",
+ "type",
+ "version",
+ "name",
+ "uuid"
+ ]
+}
+
+3.2. MISP galaxy format - clusters
+
+{
+ "$schema": "http://json-schema.org/schema#",
+ "title": "Validator for misp-galaxies - Clusters",
+ "id": "https://www.github.com/MISP/misp-galaxies/schema_clusters.json",
+ "type": "object",
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 10]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "version": {
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string
+ },
+ "values": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ },
+ "uuid": {
+ "type": "string"
+ },
+ "related": {
+ "type": "array",
+ "additionalProperties": false,
+ "items": {
+ "type": "object"
+ },
+ "properties": {
+ "dest-uuid": {
+ "type": "string"
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 11]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ },
+ "type": {
+ "type": "string"
+ },
+ "tags": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ }
+ }
+ },
+ "meta": {
+ "type": "object",
+ "additionalProperties": true,
+ "properties": {
+ "type": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "complexity": {
+ "type": "string"
+ },
+ "effectiveness": {
+ "type": "string"
+ },
+ "country": {
+ "type": "string"
+ },
+ "possible_issues": {
+ "type": "string"
+ },
+ "colour": {
+ "type": "string"
+ },
+ "motive": {
+ "type": "string"
+ },
+ "impact": {
+ "type": "string"
+ },
+ "refs": {
+ "type": "array",
+ "uniqueItems": true,
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 12]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ "items": {
+ "type": "string"
+ }
+ },
+ "synonyms": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "status": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "encryption": {
+ "type": "string"
+ },
+ "extensions": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "ransomnotes": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ }
+ }
+ }
+ },
+ "required": [
+ "value"
+ ]
+ }
+ },
+ "authors": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 13]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ }
+ },
+ "required": [
+ "description",
+ "type",
+ "version",
+ "name",
+ "uuid",
+ "values",
+ "authors",
+ "source",
+ "category
+ ]
+}
+
+4. Acknowledgements
+
+ The authors wish to thank all the MISP community who are supporting
+ the creation of open standards in threat intelligence sharing.
+
+5. References
+
+5.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,
+ .
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122,
+ DOI 10.17487/RFC4122, July 2005,
+ .
+
+ [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+ Interchange Format", STD 90, RFC 8259,
+ DOI 10.17487/RFC8259, December 2017,
+ .
+
+5.2. Informative References
+
+ [CFR] Relations, C. O. F., "Cyber Operations Tracker - Council
+ on Foreign Relations", 2018,
+ .
+
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 14]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ [JSON-SCHEMA]
+ Wright, A., "JSON Schema: A Media Type for Describing JSON
+ Documents", 2016,
+ .
+
+ [MISP-G] Community, M., "MISP Galaxy - Public Repository",
+ .
+
+ [MISP-G-DOC]
+ Community, M., "MISP Galaxy - Documentation of the Public
+ Repository", .
+
+ [MISP-P] Community, M., "MISP Project - Malware Information Sharing
+ Platform and Threat Sharing", .
+
+ [MISP-R] Community, M., "MISP Object Relationship Types - common
+ vocabulary of relationships", .
+
+Authors' Addresses
+
+ Alexandre Dulaunoy
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1611
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: alexandre.dulaunoy@circl.lu
+
+
+ Andras Iklody
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1611
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: andras.iklody@circl.lu
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 15]
+
+Internet-Draft MISP galaxy format September 2018
+
+
+ Deborah Servili
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1611
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: deborah.servili@circl.lu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy, et al. Expires March 24, 2019 [Page 16]
diff --git a/rfc/misp-standard-object-template-format.html b/rfc/misp-standard-object-template-format.html
new file mode 100644
index 0000000..c814517
--- /dev/null
+++ b/rfc/misp-standard-object-template-format.html
@@ -0,0 +1,964 @@
+
+
+
+
+
+
+ MISP object template format
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format.
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 https://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 October 12, 2018.
Copyright (c) 2018 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 (https://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 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.
Due to the increased maturity of threat information sharing, the need arose for more complex and exhaustive data-points to be shared across the various sharing communities. MISP's information sharing in general relied on a flat structure of attributes contained within an event, where attributes served as atomic secluded data-points with some commonalities as defined by the encapsulating event. However, this flat structure restricted the use of more diverse and complex data-points described by a list of atomic values, a problem solved by the MISP object structure.
+
MISP objects combine a list of attributes to represent a singular object with various facets. In order to bootstrap the object creation process and to maintain uniformity among objects describing similar data-points, the MISP object template format serves as a reusable and share-able blueprint format.
+
MISP object templates also include a vocabulary to describe the various inter object and object to attribute relationships and are leveraged by MISP object references.
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].
MISP object templates are composed of the MISP object template (MUST) structure itself and a list of MISP object template elements (SHOULD) describing the list of possible attributes belonging to the resulting object, along with their context and settings.
+
MISP object templates themselves consist of a name (MUST), a meta-category (MUST) and a description (SHOULD). They are identified by a uuid (MUST) and a version (MUST). For any updates or transfer of the same object reference. UUID version 4 is RECOMMENDED when assigning it to a new object reference. The list of requirements when it comes to the contained MISP object template elements is defined in the requirements field (OPTIONAL).
+
MISP object template elements consist of an object_relation (MUST), a type (MUST), an object_template_id (SHOULD), a ui_priority (SHOULD), a list of categories (MAY), a list of sane_default values (MAY) or a values_list (MAY).
The MISP object template format uses the JSON [RFC8259] format. Each template is represented as a JSON object with meta information including the following fields: uuid, requiredOneOf, description, version, meta-category, name.
uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of the object template. The uuid MUST be preserved for to keep consistency of the templates across instances. UUID version 4 is RECOMMENDED when assigning it to a new object template.
+
uuid is represented as a JSON string. uuid MUST be present.
requiredOneOf is represented as a JSON list and contains a list of attribute relationships of which one must be present in the object to be created based on the given template. The requiredOneOf field MAY be present.
required is represented as a JSON list and contains a list of attribute relationships of which all must be present in the object to be created based on the given template. The required field MAY be present.
description is represented as a JSON string and contains the assigned meaning given to objects created using this template. The description field MUST be present.
version represents a numeric incrementing version of the object template. It is used to associate the object to the correct version of the template and together with the uuid field forms an association to the correct template type and version.
+
version is represented as a JSON string. version MUST be present.
meta-category represents the sub-category of objects that the given object template belongs to. meta-categories are not tied to a fixed list of options but can be created on the fly.
+
meta-category is represented as a JSON string. meta-category MUST be present.
attributes is represented as a JSON list and contains a list of template elements used as a template for creating the individual attributes within the object that is to be created with the object.
+
attributes is represented as a JSON list. attributes MUST be present.
description is represented as a JSON string and contains the description of the given attribute in the context of the object with the given relationship. The description field MUST be present.
ui-priority is represented by a numeric values in JSON string format and is meant to provide a priority for the given element in the object template visualisation. The ui-priority MAY be present.
misp-attribute is represented by a JSON string or a JSON object with a list of values. The value(s) are taken from the pool of types defined by the MISP core format's Attribute Object's type list. type can contain a JSON object with a list of suggested value alternatives encapsulated in a list within a sane_default key or a list of enforced value alternatives encapsulated in a list_values key.
disable_correlation is represented by a JSON boolean. The disable_correlation field flags the attribute(s) created by the given object template element to be marked as non correlating.
categories is represented by a JSON list containing one or several valid options from the list of verbs valid for the category field in the Attribute object within the MISP core format.
multiple is represented by a JSON boolean value. It marks the MISP object template element as a multiple input field, allowing for several attributes to be created by the element within the same object.
sane_default is represented by a JSON list containing one or several recommended/sane values for an attribute. sane_default is mutually exclusive with values_list.
values_list is represented by a JSON List containing one or several of fixed values for an attribute. values_list is mutually exclusive with sane_default.
The MISP object template directory is publicly available [MISP-O] in a git repository and contains more than 60 object templates. As illustration, two sample objects templates are included.
format is represented by a JSON list containing a list of formats that the relationship type is valid for and can be mapped to. The format field MUST be present.
The MISP object template directory is publicly available [MISP-O] in a git repository. The repository contains an objects directory, which contains a directory per object type, containing a file named definition.json which contains the definition of the object template in the above described format.
+
A relationships directory is also included, containing a definition.json file which contains a list of MISP object relation definitions. There are more than 125 existing templates object documented in [MISP-O-DOC].
tsk-chats - An Object Template to gather information from evidential or interesting exchange of messages identified during a digital forensic investigation.
+
tsk-web-bookmark - An Object Template to add evidential bookmarks identified during a digital forensic investigation.
+
tsk-web-cookie - An TSK-Autopsy Object Template to represent cookies identified during a forensic investigation.
+
tsk-web-downloads - An Object Template to add web-downloads.
+
tsk-web-history - An Object Template to share web history information.
+
tsk-web-search-query - An Object Template to share web search query information.
+
ail-leak - An information leak as defined by the AIL Analysis Information Leak framework.
+
ais-info - Automated Indicator Sharing (AIS) Information Source Markings.
+
android-permission - A set of android permissions - one or more permission(s) which can be linked to other objects (e.g. malware, app).
+
annotation - An annotation object allowing analysts to add annotations, comments, executive summary to a MISP event, objects or attributes.
asn - Autonomous system object describing an autonomous system which can include one or more network operators management an entity (e.g. ISP) along with their routing policy, routing prefixes or alike.
bank-account - An object describing bank account information based on account description from goAML 4.0.
+
bgp-hijack - Object encapsulating BGP Hijack description as specified, for example, by bgpstream.com.
+
cap-alert - Common Alerting Protocol Version (CAP) alert object.
+
cap-info - Common Alerting Protocol Version (CAP) info object.
+
cap-resource - Common Alerting Protocol Version (CAP) resource object.
+
coin-address - An address used in a cryptocurrency.
+
cookie - An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to the user's web browser. The browser may store it and send it back with the next request to the same server. Typically, it's used to tell if two requests came from the same browser — keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol. (as defined by the Mozilla foundation.
+
cortex - Cortex object describing a complete cortex analysis. Observables would be attribute with a relationship from this object.
+
cortex-taxonomy - Cortex object describing an Cortex Taxonomy (or mini report).
+
course-of-action - An object describing a specific measure taken to prevent or respond to an attack.
+
cowrie - Cowrie honeypot object template.
+
credential - Credential describes one or more credential(s) including password(s), api key(s) or decryption key(s).
+
credit-card - A payment card like credit card, debit card or any similar cards which can be used for financial transactions.
+
ddos - DDoS object describes a current DDoS activity from a specific or/and to a specific target. Type of DDoS can be attached to the object as a taxonomy.
+
device - An object to define a device.
+
diameter-attack - Attack as seen on diameter authentication against a GSM, UMTS or LTE network.
+
domain-ip - A domain and IP address seen as a tuple in a specific time frame.
+
elf - Object describing a Executable and Linkable Format.
+
elf-section - Object describing a section of an Executable and Linkable Format.
+
email - Email object describing an email with meta-information.
+
exploit-poc - Exploit-poc object describing a proof of concept or exploit of a vulnerability. This object has often a relationship with a vulnerability object.
+
facial-composite - An object which describes a facial composite.
+
fail2ban - Fail2ban event.
+
file - File object describing a file with meta-information.
+
forensic-case - An object template to describe a digital forensic case.
+
forensic-evidence - An object template to describe a digital forensic evidence.
+
geolocation - An object to describe a geographic location.
+
gtp-attack - GTP attack object as seen on a GSM, UMTS or LTE network.
+
http-request - A single HTTP request header.
+
ilr-impact - Institut Luxembourgeois de Regulation - Impact.
+
ilr-notification-incident - Institut Luxembourgeois de Regulation - Notification d'incident.
+
internal-reference - Internal reference.
+
interpol-notice - An object which describes a Interpol notice.
+
ip-api-address - IP Address information. Useful if you are pulling your ip information from ip-api.com.
+
ip-port - An IP address (or domain or hostname) and a port seen as a tuple (or as a triple) in a specific time frame.
+
irc - An IRC object to describe an IRC server and the associated channels.
+
ja3 - JA3 is a new technique for creating SSL client fingerprints that are easy to produce and can be easily shared for threat intelligence. Fingerprints are composed of Client Hello packet; SSL Version, Accepted Ciphers, List of Extensions, Elliptic Curves, and Elliptic Curve Formats. https://github.com/salesforce/ja3.
+
legal-entity - An object to describe a legal entity.
+
lnk - LNK object describing a Windows LNK binary file (aka Windows shortcut).
+
macho - Object describing a file in Mach-O format.
+
macho-section - Object describing a section of a file in Mach-O format.
+
mactime-timeline-analysis - Mactime template, used in forensic investigations to describe the timeline of a file activity.
+
malware-config - Malware configuration recovered or extracted from a malicious binary.
+
microblog - Microblog post like a Twitter tweet or a post on a Facebook wall.
+
mutex - Object to describe mutual exclusion locks (mutex) as seen in memory or computer program.
+
netflow - Netflow object describes an network object based on the Netflowv5/v9 minimal definition.
+
network-connection - A local or remote network connection.
+
network-socket - Network socket object describes a local or remote network connections based on the socket data structure.
+
misc - An object which describes an organization.
+
original-imported-file - Object describing the original file used to import data in MISP.
+
passive-dns - Passive DNS records as expressed in draft-dulaunoy-dnsop-passive-dns-cof-01.
+
paste - Paste or similar post from a website allowing to share privately or publicly posts.
+
pcap-metadata - Network packet capture metadata.
+
pe - Object describing a Portable Executable.
+
pe-section - Object describing a section of a Portable Executable.
+
person - An object which describes a person or an identity.
+
phishing - Phishing template to describe a phishing website and its analysis.
+
phishing-kit - Object to describe a phishing-kit.
+
phone - A phone or mobile phone object which describe a phone.
+
process - Object describing a system process.
+
python-etvx-event-log - Event log object template to share information of the activities conducted on a system. .
+
r2graphity - Indicators extracted from files using radare2 and graphml.
+
regexp - An object describing a regular expression (regex or regexp). The object can be linked via a relationship to other attributes or objects to describe how it can be represented as a regular expression.
+
registry-key - Registry key object describing a Windows registry key with value and last-modified timestamp.
+
regripper-NTUser - Regripper Object template designed to present user specific configuration details extracted from the NTUSER.dat hive.
+
regripper-sam-hive-single-user - Regripper Object template designed to present user profile details extracted from the SAM hive.
+
regripper-sam-hive-user-group - Regripper Object template designed to present group profile details extracted from the SAM hive.
+
regripper-software-hive-BHO - Regripper Object template designed to gather information of the browser helper objects installed on the system.
+
regripper-software-hive-appInit-DLLS - Regripper Object template designed to gather information of the DLL files installed on the system.
+
regripper-software-hive-application-paths - Regripper Object template designed to gather information of the application paths.
+
regripper-software-hive-applications-installed - Regripper Object template designed to gather information of the applications installed on the system.
+
regripper-software-hive-command-shell - Regripper Object template designed to gather information of the shell commands executed on the system.
+
regripper-software-hive-windows-general-info - Regripper Object template designed to gather general windows information extracted from the software-hive.
+
regripper-software-hive-software-run - Regripper Object template designed to gather information of the applications set to run on the system.
+
regripper-software-hive-userprofile-winlogon - Regripper Object template designed to gather user profile information when the user logs onto the system, gathered from the software hive.
+
regripper-system-hive-firewall-configuration - Regripper Object template designed to present firewall configuration information extracted from the system-hive.
+
regripper-system-hive-general-configuration - Regripper Object template designed to present general system properties extracted from the system-hive.
+
regripper-system-hive-network-information. - Regripper object template designed to gather network information from the system-hive.
+
regripper-system-hive-services-drivers - Regripper Object template designed to gather information regarding the services/drivers from the system-hive.
+
report - Metadata used to generate an executive level report.
+
research-scanner - Information related to known scanning activity (e.g. from research projects).
+
rogue-dns - Rogue DNS as defined by CERT.br.
+
rtir - RTIR - Request Tracker for Incident Response.
+
sandbox-report - Sandbox report.
+
sb-signature - Sandbox detection signature.
+
script - Object describing a computer program written to be run in a special run-time environment. The script or shell script can be used for malicious activities but also as support tools for threat analysts.
+
shell-commands - Object describing a series of shell commands executed. This object can be linked with malicious files in order to describe a specific execution of shell commands.
+
short-message-service - Short Message Service (SMS) object template describing one or more SMS message. Restriction of the initial format 3GPP 23.038 GSM character set doesn't apply.
+
shortened-link - Shortened link and its redirect target.
+
splunk - Splunk / Splunk ES object.
+
ss7-attack - SS7 object of an attack seen on a GSM, UMTS or LTE network via SS7 logging.
+
ssh-authorized-keys - An object to store ssh authorized keys file.
+
stix2-pattern - An object describing a STIX pattern. The object can be linked via a relationship to other attributes or objects to describe how it can be represented as a STIX pattern.
+
suricata - An object describing one or more Suricata rule(s) along with version and contextual information.
+
target-system - Description about an targeted system, this could potentially be a compromissed internal system.
+
threatgrid-report - ThreatGrid report.
+
timecode - Timecode object to describe a start of video sequence (e.g. CCTV evidence) and the end of the video sequence.
+
timesketch-timeline - A timesketch timeline object based on mandatory field in timesketch to describe a log entry.
+
timesketch_message - A timesketch message entry.
+
timestamp - A generic timestamp object to represent time including first time and last time seen. Relationship will then define the kind of time relationship.
+
tor-hiddenservice - Tor hidden service (onion service) object.
+
tor-node - Tor node (which protects your privacy on the internet by hiding the connection between users Internet address and the services used by the users) description which are part of the Tor network at a time.
+
tracking-id - Analytics and tracking ID such as used in Google Analytics or other analytic platform.
+
transaction - An object to describe a financial transaction.
+
url - url object describes an url along with its normalized field (like extracted using faup parsing library) and its metadata.
+
vehicle - Vehicle object template to describe a vehicle information and registration.
+
victim - Victim object describes the target of an attack or abuse.
+
virustotal-report - VirusTotal report.
+
vulnerability - Vulnerability object describing a common vulnerability enumeration which can describe published, unpublished, under review or embargo vulnerability for software, equipments or hardware.
+
whois - Whois records information for a domain name or an IP address.
+
x509 - x509 object describing a X.509 certificate.
+
+
+
diff --git a/rfc/misp-standard-object-template-format.txt b/rfc/misp-standard-object-template-format.txt
new file mode 100644
index 0000000..09b1cfb
--- /dev/null
+++ b/rfc/misp-standard-object-template-format.txt
@@ -0,0 +1,1064 @@
+
+
+
+
+Network Working Group A. Dulaunoy
+Internet-Draft A. Iklody
+Expires: October 12, 2018 CIRCL
+ April 10, 2018
+
+
+ MISP object template format
+
+Abstract
+
+ This document describes the MISP object template format which
+ describes a simple JSON format to represent the various templates
+ used to construct MISP objects. A public directory of common
+ vocabularies MISP object templates [MISP-O] is available and relies
+ on the MISP object reference format.
+
+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 https://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 October 12, 2018.
+
+Copyright Notice
+
+ Copyright (c) 2018 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
+ (https://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
+ 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.
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 1]
+
+Internet-Draft MISP object template format April 2018
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
+ 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1.1. Object Template . . . . . . . . . . . . . . . . . . . 3
+ 2.1.2. attributes . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1.3. Sample Object Template object . . . . . . . . . . . . 6
+ 2.1.4. Object Relationships . . . . . . . . . . . . . . . . 9
+ 3. Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.1. Existing and public MISP object templates . . . . . . . . 10
+ 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.1. Normative References . . . . . . . . . . . . . . . . . . 18
+ 5.2. Informative References . . . . . . . . . . . . . . . . . 18
+ 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
+
+1. Introduction
+
+ Due to the increased maturity of threat information sharing, the need
+ arose for more complex and exhaustive data-points to be shared across
+ the various sharing communities. MISP's information sharing in
+ general relied on a flat structure of attributes contained within an
+ event, where attributes served as atomic secluded data-points with
+ some commonalities as defined by the encapsulating event. However,
+ this flat structure restricted the use of more diverse and complex
+ data-points described by a list of atomic values, a problem solved by
+ the MISP object structure.
+
+ MISP objects combine a list of attributes to represent a singular
+ object with various facets. In order to bootstrap the object
+ creation process and to maintain uniformity among objects describing
+ similar data-points, the MISP object template format serves as a
+ reusable and share-able blueprint format.
+
+ MISP object templates also include a vocabulary to describe the
+ various inter object and object to attribute relationships and are
+ leveraged by MISP object references.
+
+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].
+
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 2]
+
+Internet-Draft MISP object template format April 2018
+
+
+2. Format
+
+ MISP object templates are composed of the MISP object template (MUST)
+ structure itself and a list of MISP object template elements (SHOULD)
+ describing the list of possible attributes belonging to the resulting
+ object, along with their context and settings.
+
+ MISP object templates themselves consist of a name (MUST), a meta-
+ category (MUST) and a description (SHOULD). They are identified by a
+ uuid (MUST) and a version (MUST). For any updates or transfer of the
+ same object reference. UUID version 4 is RECOMMENDED when assigning
+ it to a new object reference. The list of requirements when it comes
+ to the contained MISP object template elements is defined in the
+ requirements field (OPTIONAL).
+
+ MISP object template elements consist of an object_relation (MUST), a
+ type (MUST), an object_template_id (SHOULD), a ui_priority (SHOULD),
+ a list of categories (MAY), a list of sane_default values (MAY) or a
+ values_list (MAY).
+
+2.1. Overview
+
+ The MISP object template format uses the JSON [RFC8259] format. Each
+ template is represented as a JSON object with meta information
+ including the following fields: uuid, requiredOneOf, description,
+ version, meta-category, name.
+
+2.1.1. Object Template
+
+2.1.1.1. uuid
+
+ uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of
+ the object template. The uuid MUST be preserved for to keep
+ consistency of the templates across instances. UUID version 4 is
+ RECOMMENDED when assigning it to a new object template.
+
+ uuid is represented as a JSON string. uuid MUST be present.
+
+2.1.1.2. requiredOneOf
+
+ requiredOneOf is represented as a JSON list and contains a list of
+ attribute relationships of which one must be present in the object to
+ be created based on the given template. The requiredOneOf field MAY
+ be present.
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 3]
+
+Internet-Draft MISP object template format April 2018
+
+
+2.1.1.3. required
+
+ required is represented as a JSON list and contains a list of
+ attribute relationships of which all must be present in the object to
+ be created based on the given template. The required field MAY be
+ present.
+
+2.1.1.4. description
+
+ description is represented as a JSON string and contains the assigned
+ meaning given to objects created using this template. The
+ description field MUST be present.
+
+2.1.1.5. version
+
+ version represents a numeric incrementing version of the object
+ template. It is used to associate the object to the correct version
+ of the template and together with the uuid field forms an association
+ to the correct template type and version.
+
+ version is represented as a JSON string. version MUST be present.
+
+2.1.1.6. meta-category
+
+ meta-category represents the sub-category of objects that the given
+ object template belongs to. meta-categories are not tied to a fixed
+ list of options but can be created on the fly.
+
+ meta-category is represented as a JSON string. meta-category MUST be
+ present.
+
+2.1.1.7. name
+
+ name represents the human-readable name of the objects created using
+ the given template, describing the intent of the object package.
+
+ name is represented as a JSON string. name MUST be present
+
+2.1.2. attributes
+
+ attributes is represented as a JSON list and contains a list of
+ template elements used as a template for creating the individual
+ attributes within the object that is to be created with the object.
+
+ attributes is represented as a JSON list. attributes MUST be present.
+
+
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 4]
+
+Internet-Draft MISP object template format April 2018
+
+
+2.1.2.1. description
+
+ description is represented as a JSON string and contains the
+ description of the given attribute in the context of the object with
+ the given relationship. The description field MUST be present.
+
+2.1.2.2. ui-priority
+
+ ui-priority is represented by a numeric values in JSON string format
+ and is meant to provide a priority for the given element in the
+ object template visualisation. The ui-priority MAY be present.
+
+2.1.2.3. misp-attribute
+
+ misp-attribute is represented by a JSON string or a JSON object with
+ a list of values. The value(s) are taken from the pool of types
+ defined by the MISP core format's Attribute Object's type list. type
+ can contain a JSON object with a list of suggested value alternatives
+ encapsulated in a list within a sane_default key or a list of
+ enforced value alternatives encapsulated in a list_values key.
+
+ The misp-attribute field MUST be present.
+
+2.1.2.4. disable_correlation
+
+ disable_correlation is represented by a JSON boolean. The
+ disable_correlation field flags the attribute(s) created by the given
+ object template element to be marked as non correlating.
+
+ The misp-attribute field MAY be present.
+
+2.1.2.5. categories
+
+ categories is represented by a JSON list containing one or several
+ valid options from the list of verbs valid for the category field in
+ the Attribute object within the MISP core format.
+
+ The categories field MAY be present.
+
+2.1.2.6. multiple
+
+ multiple is represented by a JSON boolean value. It marks the MISP
+ object template element as a multiple input field, allowing for
+ several attributes to be created by the element within the same
+ object.
+
+ The multiple field MAY be present.
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 5]
+
+Internet-Draft MISP object template format April 2018
+
+
+2.1.2.7. sane_default
+
+ sane_default is represented by a JSON list containing one or several
+ recommended/sane values for an attribute. sane_default is mutually
+ exclusive with values_list.
+
+ The sane_default field MAY be present.
+
+2.1.2.8. values_list
+
+ values_list is represented by a JSON List containing one or several
+ of fixed values for an attribute. values_list is mutually exclusive
+ with sane_default.
+
+ The value_list field MAY be present.
+
+2.1.3. Sample Object Template object
+
+ The MISP object template directory is publicly available [MISP-O] in
+ a git repository and contains more than 60 object templates. As
+ illustration, two sample objects templates are included.
+
+2.1.3.1. credit-card object template
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 6]
+
+Internet-Draft MISP object template format April 2018
+
+
+{
+ "requiredOneOf": [
+ "cc-number"
+ ],
+ "attributes": {
+ "version": {
+ "description": "Version of the card.",
+ "ui-priority": 0,
+ "misp-attribute": "text"
+ },
+ "comment": {
+ "description": "A description of the card.",
+ "ui-priority": 0,
+ "misp-attribute": "comment"
+ },
+ "card-security-code": {
+ "description": "Card security code (CSC, CVD, CVV, CVC and SPC) as embossed or printed on the card.",
+ "ui-priority": 0,
+ "misp-attribute": "text"
+ },
+ "name": {
+ "description": "Name of the card owner.",
+ "ui-priority": 0,
+ "misp-attribute": "text"
+ },
+ "issued": {
+ "description": "Initial date of validity or issued date.",
+ "ui-priority": 0,
+ "misp-attribute": "datetime"
+ },
+ "expiration": {
+ "description": "Maximum date of validity",
+ "ui-priority": 0,
+ "misp-attribute": "datetime"
+ },
+ "cc-number": {
+ "description": "credit-card number as encoded on the card.",
+ "ui-priority": 0,
+ "misp-attribute": "cc-number"
+ }
+ },
+ "version": 2,
+ "description": "A payment card like credit card, debit card or any similar cards which can be used for financial transactions.",
+ "meta-category": "financial",
+ "uuid": "2b9c57aa-daba-4330-a738-56f18743b0c7",
+ "name": "credit-card"
+}
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 7]
+
+Internet-Draft MISP object template format April 2018
+
+
+2.1.3.2. credential object template
+
+{
+ "requiredOneOf": [
+ "password"
+ ],
+ "attributes": {
+ "text": {
+ "description": "A description of the credential(s)",
+ "disable_correlation": true,
+ "ui-priority": 1,
+ "misp-attribute": "text"
+ },
+ "username": {
+ "description": "Username related to the password(s)",
+ "ui-priority": 1,
+ "misp-attribute": "text"
+ },
+ "password": {
+ "description": "Password",
+ "multiple": true,
+ "ui-priority": 1,
+ "misp-attribute": "text"
+ },
+ "type": {
+ "description": "Type of password(s)",
+ "ui-priority": 1,
+ "misp-attribute": "text",
+ "values_list": [
+ "password",
+ "api-key",
+ "encryption-key",
+ "unknown"
+ ]
+ },
+ "origin": {
+ "description": "Origin of the credential(s)",
+ "ui-priority": 1,
+ "misp-attribute": "text",
+ "sane_default": [
+ "bruteforce-scanning",
+ "malware-analysis",
+ "memory-analysis",
+ "network-analysis",
+ "leak",
+ "unknown"
+ ]
+ },
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 8]
+
+Internet-Draft MISP object template format April 2018
+
+
+ "format": {
+ "description": "Format of the password(s)",
+ "ui-priority": 1,
+ "misp-attribute": "text",
+ "values_list": [
+ "clear-text",
+ "hashed",
+ "encrypted",
+ "unknown"
+ ]
+ },
+ "notification": {
+ "description": "Mention of any notification(s) towards the potential owner(s) of the credential(s)",
+ "ui-priority": 1,
+ "misp-attribute": "text",
+ "multiple": true,
+ "values_list": [
+ "victim-notified",
+ "service-notified",
+ "none"
+ ]
+ }
+ },
+ "version": 2,
+ "description": "Credential describes one or more credential(s) including password(s), api key(s) or decryption key(s).",
+ "meta-category": "misc",
+ "uuid": "a27e98c9-9b0e-414c-8076-d201e039ca09",
+ "name": "credential"
+}
+
+2.1.4. Object Relationships
+
+2.1.4.1. name
+
+ name represents the human-readable relationship type which can be
+ used when creating MISP object relations.
+
+ name is represented as a JSON string. name MUST be present.
+
+2.1.4.2. description
+
+ description is represented as a JSON string and contains the
+ description of the object relationship type. The description field
+ MUST be present.
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 9]
+
+Internet-Draft MISP object template format April 2018
+
+
+2.1.4.3. format
+
+ format is represented by a JSON list containing a list of formats
+ that the relationship type is valid for and can be mapped to. The
+ format field MUST be present.
+
+3. Directory
+
+ The MISP object template directory is publicly available [MISP-O] in
+ a git repository. The repository contains an objects directory,
+ which contains a directory per object type, containing a file named
+ definition.json which contains the definition of the object template
+ in the above described format.
+
+ A relationships directory is also included, containing a
+ definition.json file which contains a list of MISP object relation
+ definitions. There are more than 125 existing templates object
+ documented in [MISP-O-DOC].
+
+3.1. Existing and public MISP object templates
+
+ o tsk-chats - An Object Template to gather information from
+ evidential or interesting exchange of messages identified during a
+ digital forensic investigation.
+
+ o tsk-web-bookmark - An Object Template to add evidential bookmarks
+ identified during a digital forensic investigation.
+
+ o tsk-web-cookie - An TSK-Autopsy Object Template to represent
+ cookies identified during a forensic investigation.
+
+ o tsk-web-downloads - An Object Template to add web-downloads.
+
+ o tsk-web-history - An Object Template to share web history
+ information.
+
+ o tsk-web-search-query - An Object Template to share web search
+ query information.
+
+ o ail-leak - An information leak as defined by the AIL Analysis
+ Information Leak framework.
+
+ o ais-info - Automated Indicator Sharing (AIS) Information Source
+ Markings.
+
+ o android-permission - A set of android permissions - one or more
+ permission(s) which can be linked to other objects (e.g. malware,
+ app).
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 10]
+
+Internet-Draft MISP object template format April 2018
+
+
+ o annotation - An annotation object allowing analysts to add
+ annotations, comments, executive summary to a MISP event, objects
+ or attributes.
+
+ o anonymisation - Anonymisation object describing an anonymisation
+ technique used to encode MISP attribute values. Reference:
+ https://www.caida.org/tools/taxonomy/anonymization.xml [1].
+
+ o asn - Autonomous system object describing an autonomous system
+ which can include one or more network operators management an
+ entity (e.g. ISP) along with their routing policy, routing
+ prefixes or alike.
+
+ o authenticode-signerinfo - Authenticode Signer Info.
+
+ o av-signature - Antivirus detection signature.
+
+ o bank-account - An object describing bank account information based
+ on account description from goAML 4.0.
+
+ o bgp-hijack - Object encapsulating BGP Hijack description as
+ specified, for example, by bgpstream.com.
+
+ o cap-alert - Common Alerting Protocol Version (CAP) alert object.
+
+ o cap-info - Common Alerting Protocol Version (CAP) info object.
+
+ o cap-resource - Common Alerting Protocol Version (CAP) resource
+ object.
+
+ o coin-address - An address used in a cryptocurrency.
+
+ o cookie - An HTTP cookie (web cookie, browser cookie) is a small
+ piece of data that a server sends to the user's web browser. The
+ browser may store it and send it back with the next request to the
+ same server. Typically, it's used to tell if two requests came
+ from the same browser -- keeping a user logged-in, for example.
+ It remembers stateful information for the stateless HTTP protocol.
+ (as defined by the Mozilla foundation.
+
+ o cortex - Cortex object describing a complete cortex analysis.
+ Observables would be attribute with a relationship from this
+ object.
+
+ o cortex-taxonomy - Cortex object describing an Cortex Taxonomy (or
+ mini report).
+
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 11]
+
+Internet-Draft MISP object template format April 2018
+
+
+ o course-of-action - An object describing a specific measure taken
+ to prevent or respond to an attack.
+
+ o cowrie - Cowrie honeypot object template.
+
+ o credential - Credential describes one or more credential(s)
+ including password(s), api key(s) or decryption key(s).
+
+ o credit-card - A payment card like credit card, debit card or any
+ similar cards which can be used for financial transactions.
+
+ o ddos - DDoS object describes a current DDoS activity from a
+ specific or/and to a specific target. Type of DDoS can be
+ attached to the object as a taxonomy.
+
+ o device - An object to define a device.
+
+ o diameter-attack - Attack as seen on diameter authentication
+ against a GSM, UMTS or LTE network.
+
+ o domain-ip - A domain and IP address seen as a tuple in a specific
+ time frame.
+
+ o elf - Object describing a Executable and Linkable Format.
+
+ o elf-section - Object describing a section of an Executable and
+ Linkable Format.
+
+ o email - Email object describing an email with meta-information.
+
+ o exploit-poc - Exploit-poc object describing a proof of concept or
+ exploit of a vulnerability. This object has often a relationship
+ with a vulnerability object.
+
+ o facial-composite - An object which describes a facial composite.
+
+ o fail2ban - Fail2ban event.
+
+ o file - File object describing a file with meta-information.
+
+ o forensic-case - An object template to describe a digital forensic
+ case.
+
+ o forensic-evidence - An object template to describe a digital
+ forensic evidence.
+
+ o geolocation - An object to describe a geographic location.
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 12]
+
+Internet-Draft MISP object template format April 2018
+
+
+ o gtp-attack - GTP attack object as seen on a GSM, UMTS or LTE
+ network.
+
+ o http-request - A single HTTP request header.
+
+ o ilr-impact - Institut Luxembourgeois de Regulation - Impact.
+
+ o ilr-notification-incident - Institut Luxembourgeois de Regulation
+ - Notification d'incident.
+
+ o internal-reference - Internal reference.
+
+ o interpol-notice - An object which describes a Interpol notice.
+
+ o ip-api-address - IP Address information. Useful if you are
+ pulling your ip information from ip-api.com.
+
+ o ip-port - An IP address (or domain or hostname) and a port seen as
+ a tuple (or as a triple) in a specific time frame.
+
+ o irc - An IRC object to describe an IRC server and the associated
+ channels.
+
+ o ja3 - JA3 is a new technique for creating SSL client fingerprints
+ that are easy to produce and can be easily shared for threat
+ intelligence. Fingerprints are composed of Client Hello packet;
+ SSL Version, Accepted Ciphers, List of Extensions, Elliptic
+ Curves, and Elliptic Curve Formats. https://github.com/salesforce/
+ ja3 [2].
+
+ o legal-entity - An object to describe a legal entity.
+
+ o lnk - LNK object describing a Windows LNK binary file (aka Windows
+ shortcut).
+
+ o macho - Object describing a file in Mach-O format.
+
+ o macho-section - Object describing a section of a file in Mach-O
+ format.
+
+ o mactime-timeline-analysis - Mactime template, used in forensic
+ investigations to describe the timeline of a file activity.
+
+ o malware-config - Malware configuration recovered or extracted from
+ a malicious binary.
+
+ o microblog - Microblog post like a Twitter tweet or a post on a
+ Facebook wall.
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 13]
+
+Internet-Draft MISP object template format April 2018
+
+
+ o mutex - Object to describe mutual exclusion locks (mutex) as seen
+ in memory or computer program.
+
+ o netflow - Netflow object describes an network object based on the
+ Netflowv5/v9 minimal definition.
+
+ o network-connection - A local or remote network connection.
+
+ o network-socket - Network socket object describes a local or remote
+ network connections based on the socket data structure.
+
+ o misc - An object which describes an organization.
+
+ o original-imported-file - Object describing the original file used
+ to import data in MISP.
+
+ o passive-dns - Passive DNS records as expressed in draft-dulaunoy-
+ dnsop-passive-dns-cof-01.
+
+ o paste - Paste or similar post from a website allowing to share
+ privately or publicly posts.
+
+ o pcap-metadata - Network packet capture metadata.
+
+ o pe - Object describing a Portable Executable.
+
+ o pe-section - Object describing a section of a Portable Executable.
+
+ o person - An object which describes a person or an identity.
+
+ o phishing - Phishing template to describe a phishing website and
+ its analysis.
+
+ o phishing-kit - Object to describe a phishing-kit.
+
+ o phone - A phone or mobile phone object which describe a phone.
+
+ o process - Object describing a system process.
+
+ o python-etvx-event-log - Event log object template to share
+ information of the activities conducted on a system. .
+
+ o r2graphity - Indicators extracted from files using radare2 and
+ graphml.
+
+ o regexp - An object describing a regular expression (regex or
+ regexp). The object can be linked via a relationship to other
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 14]
+
+Internet-Draft MISP object template format April 2018
+
+
+ attributes or objects to describe how it can be represented as a
+ regular expression.
+
+ o registry-key - Registry key object describing a Windows registry
+ key with value and last-modified timestamp.
+
+ o regripper-NTUser - Regripper Object template designed to present
+ user specific configuration details extracted from the NTUSER.dat
+ hive.
+
+ o regripper-sam-hive-single-user - Regripper Object template
+ designed to present user profile details extracted from the SAM
+ hive.
+
+ o regripper-sam-hive-user-group - Regripper Object template designed
+ to present group profile details extracted from the SAM hive.
+
+ o regripper-software-hive-BHO - Regripper Object template designed
+ to gather information of the browser helper objects installed on
+ the system.
+
+ o regripper-software-hive-appInit-DLLS - Regripper Object template
+ designed to gather information of the DLL files installed on the
+ system.
+
+ o regripper-software-hive-application-paths - Regripper Object
+ template designed to gather information of the application paths.
+
+ o regripper-software-hive-applications-installed - Regripper Object
+ template designed to gather information of the applications
+ installed on the system.
+
+ o regripper-software-hive-command-shell - Regripper Object template
+ designed to gather information of the shell commands executed on
+ the system.
+
+ o regripper-software-hive-windows-general-info - Regripper Object
+ template designed to gather general windows information extracted
+ from the software-hive.
+
+ o regripper-software-hive-software-run - Regripper Object template
+ designed to gather information of the applications set to run on
+ the system.
+
+ o regripper-software-hive-userprofile-winlogon - Regripper Object
+ template designed to gather user profile information when the user
+ logs onto the system, gathered from the software hive.
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 15]
+
+Internet-Draft MISP object template format April 2018
+
+
+ o regripper-system-hive-firewall-configuration - Regripper Object
+ template designed to present firewall configuration information
+ extracted from the system-hive.
+
+ o regripper-system-hive-general-configuration - Regripper Object
+ template designed to present general system properties extracted
+ from the system-hive.
+
+ o regripper-system-hive-network-information. - Regripper object
+ template designed to gather network information from the system-
+ hive.
+
+ o regripper-system-hive-services-drivers - Regripper Object template
+ designed to gather information regarding the services/drivers from
+ the system-hive.
+
+ o report - Metadata used to generate an executive level report.
+
+ o research-scanner - Information related to known scanning activity
+ (e.g. from research projects).
+
+ o rogue-dns - Rogue DNS as defined by CERT.br.
+
+ o rtir - RTIR - Request Tracker for Incident Response.
+
+ o sandbox-report - Sandbox report.
+
+ o sb-signature - Sandbox detection signature.
+
+ o script - Object describing a computer program written to be run in
+ a special run-time environment. The script or shell script can be
+ used for malicious activities but also as support tools for threat
+ analysts.
+
+ o shell-commands - Object describing a series of shell commands
+ executed. This object can be linked with malicious files in order
+ to describe a specific execution of shell commands.
+
+ o short-message-service - Short Message Service (SMS) object
+ template describing one or more SMS message. Restriction of the
+ initial format 3GPP 23.038 GSM character set doesn't apply.
+
+ o shortened-link - Shortened link and its redirect target.
+
+ o splunk - Splunk / Splunk ES object.
+
+ o ss7-attack - SS7 object of an attack seen on a GSM, UMTS or LTE
+ network via SS7 logging.
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 16]
+
+Internet-Draft MISP object template format April 2018
+
+
+ o ssh-authorized-keys - An object to store ssh authorized keys file.
+
+ o stix2-pattern - An object describing a STIX pattern. The object
+ can be linked via a relationship to other attributes or objects to
+ describe how it can be represented as a STIX pattern.
+
+ o suricata - An object describing one or more Suricata rule(s) along
+ with version and contextual information.
+
+ o target-system - Description about an targeted system, this could
+ potentially be a compromissed internal system.
+
+ o threatgrid-report - ThreatGrid report.
+
+ o timecode - Timecode object to describe a start of video sequence
+ (e.g. CCTV evidence) and the end of the video sequence.
+
+ o timesketch-timeline - A timesketch timeline object based on
+ mandatory field in timesketch to describe a log entry.
+
+ o timesketch_message - A timesketch message entry.
+
+ o timestamp - A generic timestamp object to represent time including
+ first time and last time seen. Relationship will then define the
+ kind of time relationship.
+
+ o tor-hiddenservice - Tor hidden service (onion service) object.
+
+ o tor-node - Tor node (which protects your privacy on the internet
+ by hiding the connection between users Internet address and the
+ services used by the users) description which are part of the Tor
+ network at a time.
+
+ o tracking-id - Analytics and tracking ID such as used in Google
+ Analytics or other analytic platform.
+
+ o transaction - An object to describe a financial transaction.
+
+ o url - url object describes an url along with its normalized field
+ (like extracted using faup parsing library) and its metadata.
+
+ o vehicle - Vehicle object template to describe a vehicle
+ information and registration.
+
+ o victim - Victim object describes the target of an attack or abuse.
+
+ o virustotal-report - VirusTotal report.
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 17]
+
+Internet-Draft MISP object template format April 2018
+
+
+ o vulnerability - Vulnerability object describing a common
+ vulnerability enumeration which can describe published,
+ unpublished, under review or embargo vulnerability for software,
+ equipments or hardware.
+
+ o whois - Whois records information for a domain name or an IP
+ address.
+
+ o x509 - x509 object describing a X.509 certificate.
+
+ o yabin - yabin.py generates Yara rules from function prologs, for
+ matching and hunting binaries. ref: https://github.com/AlienVault-
+ OTX/yabin [3].
+
+ o yara - An object describing a YARA rule along with its version.
+
+4. Acknowledgements
+
+ The authors wish to thank all the MISP community who are supporting
+ the creation of open standards in threat intelligence sharing.
+
+5. References
+
+5.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,
+ .
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122,
+ DOI 10.17487/RFC4122, July 2005,
+ .
+
+ [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+ Interchange Format", STD 90, RFC 8259,
+ DOI 10.17487/RFC8259, December 2017,
+ .
+
+5.2. Informative References
+
+ [MISP-O] Community, M., "MISP Objects - shared and common object
+ templates", .
+
+ [MISP-O-DOC]
+ community, M., "MISP objects directory", 2018,
+ .
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 18]
+
+Internet-Draft MISP object template format April 2018
+
+
+5.3. URIs
+
+ [1] https://www.caida.org/tools/taxonomy/anonymization.xml
+
+ [2] https://github.com/salesforce/ja3
+
+ [3] https://github.com/AlienVault-OTX/yabin
+
+Authors' Addresses
+
+ Alexandre Dulaunoy
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1611
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: alexandre.dulaunoy@circl.lu
+
+
+ Andras Iklody
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1611
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: andras.iklody@circl.lu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires October 12, 2018 [Page 19]
diff --git a/rfc/misp-standard-taxonomy-format.html b/rfc/misp-standard-taxonomy-format.html
new file mode 100644
index 0000000..a8b99ee
--- /dev/null
+++ b/rfc/misp-standard-taxonomy-format.html
@@ -0,0 +1,1371 @@
+
+
+
+
+
+
+ MISP taxonomy format
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This document describes the MISP taxonomy format which describes a simple JSON format to represent machine tags (also called triple tags) vocabularies. A public directory of common vocabularies called MISP taxonomies is available and relies on the MISP taxonomy format. MISP taxonomies are used to classify cyber security events, threats, suspicious events, or indicators.
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 https://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."
Copyright (c) 2017 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 (https://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 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.
Sharing threat information became a fundamental requirements on 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. While sharing such indicators or information, classification plays an important role to ensure adequate distribution, understanding, validation or action of the shared information. MISP taxonomies is a public repository of known vocabularies that can be used in threat information sharing.
+
Machine tags were introduced in 2007 [machine-tags] to allow users to be more precise when tagging their pictures with geolocation. So a machine tag is a tag which uses a special syntax to provide more information to users and machines. Machine tags are also known as triple tags due to their format.
+
In the MISP taxonomy context, machine tags help analysts to classify their cybersecurity events, indicators or threats. MISP taxonomies can be used for classification, filtering, triggering actions or visualisation depending on their use in threat intelligence platforms such as MISP [MISP-P].
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].
A machine tag is composed of a namespace (MUST), a predicate (MUST) and an optional value (OPTIONAL).
+
Machine tags are represented as a string. Below listed are a set of sample machine tags for different namespaces such as tlp, admiralty-scale and osint.
The MISP taxonomy format describes how to define a machine tag namespace in a parseable format. The objective is to provide a simple format to describe machine tag (aka triple tag) vocabularies.
The MISP taxonomy format uses the JSON [RFC8259] format. Each namespace is represented as a JSON object with meta information including the following fields: namespace, description, version, type.
+
namespace defines the overall namespace of the machine tag. The namespace is represented as a string and MUST be present. The description is represented as a string and MUST be present. A version is represented as a unsigned integer MUST be present. A type defines where a specific taxonomy is applicable and a type can be applicable at event, user or org level. The type is represented as an array containing one or more type and SHOULD be present. If a type is not mentioned, by default, the taxonomy is applicable at event level only. An exclusive boolean property MAY be present and defines at namespace level if the predicates are mutually exclusive.
+
predicates defines all the predicates available in the namespace defined. predicates is represented as an array of JSON objects. predicates MUST be present and MUST at least content one element.
+
values defines all the values for each predicate in the namespace defined. values SHOULD be present.
The predicates array contains one or more JSON objects which lists all the possible predicates. The JSON object contains two fields: value and expanded. value MUST be present. expanded SHOULD be present. value is represented as a string and describes the predicate value. The predicate value MUST not contain spaces or colons. expanded is represented as a string and describes the human-readable version of the predicate value. An exclusive property MAY be present and defines at namespace level if the values are mutually exclusive.
The values array contain one or more JSON objects which lists all the possible values of a predicate. The JSON object contains two fields: predicate and entry. predicate is represented as a string and describes the predicate value. entry is an array with one or more JSON objects. The JSON object contains two fields: value and expanded. value MUST be present. expanded SHOULD be present. value is represented as a string and describes the machine parsable value. expanded is represented as a string and describes the human-readable version of the value.
colour fields MAY be used at predicates or values level to set a specify colour that MAY be used by the implementation. The colour field is described as an RGB colour fill in hexadecimal representation.
+
Example use of the colour field in the Traffic Light Protocol (TLP):
+
"predicates": [
+ {
+ "colour": "#CC0033",
+ "expanded": "(TLP:RED) Information exclusively and directly
+ given to (a group of) individual recipients.
+ Sharing outside is not legitimate.",
+ "value": "red"
+ },
+ {
+ "colour": "#FFC000",
+ "expanded": "(TLP:AMBER) Information exclusively given
+ to an organization; sharing limited within
+ the organization to be effectively acted upon.",
+ "value": "amber"
+ }...]
+
description fields MAY be used at predicates or values level to add a descriptive and human-readable information about the specific predicate or value. The field is represented as a string. Implementations MAY use the description field to improve more contextual information. The description at the namespace level is a MUST as described above.
numerical_value fields MAY be used at a predicate or value level to add a machine-readable numeric value to a specific predicate or value. The field is represented as a JSON number. Implementations SHOULD use the decimal value provided to support scoring or filtering.
+
The decimal range for numerical_value SHOULD use a range from 0 up to 100. The range is recommended to support common mathematical properties among taxonomies.
+
Example use of the numerical_value in the MISP confidence level:
The MISP taxonomies directory is publicly available [MISP-T] in a git repository. The repository contains a directory per namespace then a file machinetag.json which contains the taxonomy as described in the format above. In the root of the repository, a MANIFEST.json exists containing a list of all the taxonomies.
+
The MANIFEST.json file is composed of an JSON object with metadata like version, license, description, url and path. A taxonomies array describes the taxonomy available with the description, name and version field.
The public directory of MISP taxonomies [MISP-T] contains a variety of taxonomy in various fields such as:
+
+
+
+
CERT-XLM:
+
+ CERT-XLM Security Incident Classification.
+
DML:
+
+ The Detection Maturity Level (DML) model is a capability maturity model for referencing ones maturity in detecting cyber attacks. It's designed for organizations who perform intel-driven detection and response and who put an emphasis on having a mature detection program.
+
PAP:
+
+ The Permissible Actions Protocol - or short: PAP - was designed to indicate how the received information can be used.
+
access-method:
+
+ The access method used to remotely access a system.
+
accessnow:
+
+ Access Now classification to classify an issue (such as security, human rights, youth rights).
+
action-taken:
+
+ Action taken in the case of a security incident (CSIRT perspective).
+
admiralty-scale:
+
+ The Admiralty Scale (also called the NATO System) is used to rank the reliability of a source and the credibility of an information.
+
adversary:
+
+ An overview and description of the adversary infrastructure.
+
ais-marking:
+
+ AIS Marking Schema implementation is maintained by the National Cybersecurity and Communication Integration Center (NCCIC) of the U.S. Department of Homeland Security (DHS)
+
analyst-assessment:
+
+ A series of assessment predicates describing the analyst capabilities to perform analysis. These assessment can be assigned by the analyst him/herself or by another party evaluating the analyst.
+
approved-category-of-action:
+
+ A pre-approved category of action for indicators being shared with partners (MIMIC).
+
binary-class:
+
+ Custom taxonomy for types of binary file.
+
cccs:
+
+ Internal taxonomy for CCCS.
+
circl:
+
+ CIRCL Taxonomy is a simple scheme for incident classification and area topic where the incident took place.
+
collaborative-intelligence:
+
+ Collaborative intelligence support language is a common language to support analysts to perform their analysis to get crowdsourced support when using threat intelligence sharing platform like MISP.
+
common-taxonomy:
+
+ The Common Taxonomy for Law Enforcement and The National Network of CSIRTs bridges the gap between the CSIRTs and international Law Enforcement communities by adding a legislative framework to facilitate the harmonisation of incident reporting to competent authorities, the development of useful statistics and sharing information within the entire cybercrime ecosystem.
+
copine-scale:
+
+ The COPINE Scale is a rating system created in Ireland and used in the United Kingdom to categorise the severity of images of child sex abuse.
+
cryptocurrency-threat:
+
+ Threats targetting cryptocurrency, based on CipherTrace report.
+
csirtcaseclassification:
+
+ FIRST CSIRT Case Classification.
+
cssa:
+
+ The CSSA agreed sharing taxonomy.
+
cyber-threat-framework:
+
+ Cyber Threat Framework was developed by the US Government to enable consistent characterization and categorization of cyber threat events, and to identify trends or changes in the activities of cyber adversaries. https://www.dni.gov/index.php/cyber-threat-framework
+
+
data-classification:
+
+ Data classification for data potentially at risk of exfiltration based on table 2.1 of Solving Cyber Risk book.
+
dcso-sharing:
+
+ DCSO Sharing Taxonomy to classify certain types of MISP events using the DCSO Event Guide
+
ddos:
+
+ Distributed Denial of Service - or short: DDoS - taxonomy supports the description of Denial of Service attacks and especially the types they belong too.
+
de-vs:
+
+ Taxonomy for the handling of protectively marked information in MISP with German (DE) Government classification markings (VS)
+ The Diamond Model for Intrusion Analysis, a phase-based model developed by Lockheed Martin, aims to help categorise and identify the stage of an attack.
+
dni-ism:
+
+ ISM (Information Security Marking Metadata) V13 as described by DNI.gov (Director of National Intelligence - US).
+
domain-abuse:
+
+ Taxonomy to tag domain names used for cybercrime.
+ Estimative language - including likelihood or probability of event based on the Intelligence Community Directive 203 (ICD 203) (6.2.(a)) and JP 2-0, Joint Intelligence.
+
eu-marketop-and-publicadmin:
+
+ Market operators and public administrations that must comply to some notifications requirements under EU NIS directive.
+
eu-nis-sector-and-subsectors:
+
+ Sectors and sub sectors as identified by the NIS Directive.
+
euci:
+
+ EU classified information (EUCI) means any information or material designated by a EU security classification, the unauthorised disclosure of which could cause varying degrees of prejudice to the interests of the European Union or of one or more of the Member States as described in COUNCIL DECISION of 23 September 2013 on the security rules for protecting EU classified information
+
europol-event:
+
+ EUROPOL type of events taxonomy.
+
europol-incident:
+
+ EUROPOL class of incident taxonomy.
+
event-assessment:
+
+ A series of assessment predicates describing the event assessment performed to make judgement(s) under a certain level of uncertainty.
+
event-classification:
+
+ Event Classification.
+
exercise:
+
+ Exercise is a taxonomy to describe if the information is part of one or more cyber or crisis exercise.
+
false-positive:
+
+ This taxonomy aims to ballpark the expected amount of false positives.
+
file-type:
+
+ List of known file types.
+
flesch-reading-ease:
+
+ Flesch Reading Ease is a revised system for determining the comprehension difficulty of written material. The scoring of the flesh score can have a maximum of 121.22 and there is no limit on how low a score can be (negative score are valid).
+
fpf:
+
+ The Future of Privacy Forum (FPF) visual guide to practical de-identification taxonomy is used to evaluate the degree of identifiability of personal data and the types of pseudonymous data, de-identified data and anonymous data. The work of FPF is licensed under a creative commons attribution 4.0 international license.
+
fr-classif:
+
+ French gov information classification system.
+
gdpr:
+
+ Taxonomy related to the REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)
+
gsma-attack-category:
+
+ Taxonomy used by GSMA for their information sharing program with telco describing the attack categories
+
gsma-fraud:
+
+ Taxonomy used by GSMA for their information sharing program with telco describing the various aspects of fraud
+
gsma-network-technology:
+
+ Taxonomy used by GSMA for their information sharing program with telco describing the types of infrastructure. WiP
+ Forum of Incident Response and Security Teams (FIRST) Information Exchange Policy (IEP) framework.
+
ifx-vetting:
+
+ The IFX taxonomy is used to categorise information (MISP events and attributes) to aid in the intelligence vetting process
+
incident-disposition:
+
+ How an incident is classified in its process to be resolved. The taxonomy is inspired from NASA Incident Response and Management Handbook.
+
infoleak:
+
+ A taxonomy describing information leaks and especially information classified as being potentially leaked.
+
information-security-data-source:
+
+ Taxonomy to classify the information security data sources
+
information-security-indicators:
+
+ Information security indicators have been standardized by the ETSI Industrial Specification Group (ISG) ISI. These indicators provide the basis to switch from a qualitative to a quantitative culture in IT Security Scope of measurements: External and internal threats (attempt and success), user's deviant behaviours, nonconformities and/or vulnerabilities (software, configuration, behavioural, general security framework). ETSI GS ISI 001-1 (V1.1.2): ISI Indicators
+
interception-method:
+
+ The interception method used to intercept traffic.
+
kill-chain:
+
+ Cyber Kill Chain from Lockheed Martin as described in Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains.
+
maec-delivery-vectors:
+
+ Vectors used to deliver malware based on MAEC 5.0
+
maec-malware-behavior:
+
+ Malware behaviours based on MAEC 5.0
+
maec-malware-capabilities:
+
+ Malware Capabilities based on MAEC 5.0
+
maec-malware-obfuscation-methods:
+
+ Obfuscation methods used by malware based on MAEC 5.0
+
malware_classification:
+
+ Malware classification based on a SANS whitepaper about malware.
+
misp:
+
+ Internal MISP taxonomy.
+
monarc-threat:
+
+ MONARC threat taxonomy.
+
ms-caro-malware:
+
+ Malware Type and Platform classification based on Microsoft's implementation of the Computer Antivirus Research Organization (CARO) Naming Scheme and Malware Terminology.
+
ms-caro-malware-full:
+
+ Malware Type and Platform classification based on Microsoft's implementation of the Computer Antivirus Research Organization (CARO) Naming Scheme and Malware Terminology.
+
nato:
+
+ Marking of Classified and Unclassified materials as described by the North Atlantic Treaty Organization, NATO.
+ Open Source Intelligence - Classification (MISP taxonomies).
+
passivetotal:
+
+ Tags for RiskIQ's passivetotal service
+
pentest:
+
+ Penetration test (pentest) classification.
+
priority-level:
+
+ After an incident is scored, it is assigned a priority level. The six levels listed below are aligned with NCCIC, DHS, and the CISS to help provide a common lexicon when discussing incidents. This priority assignment drives NCCIC urgency, pre-approved incident response offerings, reporting requirements, and recommendations for leadership escalation. Generally, incident priority distribution should follow a similar pattern to the graph below. Based on https://www.us-cert.gov/NCCIC-Cyber-Incident-Scoring-System.
+ Runtime or software packer used to combine compressed data with the decompression code. The decompression code can add additional obfuscations mechanisms including polymorphic-packer or other obfuscation techniques. This taxonomy lists all the known or official packer used for legitimate use or for packing malicious binaries.
+
smart-airports-threats:
+
+ Threat taxonomy in the scope of securing smart airports by ENISA.
+
stealth_malware:
+
+ Classification based on malware stealth techniques.
+
stix-ttp:
+
+ Representation of the behavior or modus operandi of cyber adversaries (a.k.a TTP) as normalized in STIX
+
targeted-threat-index:
+
+ The Targeted Threat Index is a metric for assigning an overall threat ranking score to email messages that deliver malware to a victim’s computer. The TTI metric was first introduced at SecTor 2013 by Seth Hardy as part of the talk “RATastrophe: Monitoring a Malware Menagerie” along with Katie Kleemola and Greg Wiseman.
+
tlp:
+
+ The Traffic Light Protocol - or short: TLP - was designed with the objective to create a favorable classification scheme for sharing sensitive information while keeping the control over its distribution at the same time. Extended with TLP:EX:CHR.
+
tor:
+
+ Taxonomy to describe Tor network infrastructure
+
type:
+
+ Taxonomy to describe different types of intelligence gathering discipline which can be described the origin of intelligence.
+
use-case-applicability:
+
+ The Use Case Applicability categories reflect standard resolution categories, to clearly display alerting rule configuration problems.
+
veris:
+
+ Vocabulary for Event Recording and Incident Sharing (VERIS).
+
vocabulaire-des-probabilites-estimatives:
+
+ Vocabulaire des probabilités estimatives
+
workflow:
+
+ Workflow support language is a common language to support intelligence analysts to perform their analysis on data and information.
The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP taxonomy document as literally described before. The JSON Schema is used validating a MISP taxonomy. The validation is a MUST if the taxonomy is included in the MISP taxonomies directory.
+
+
+
diff --git a/rfc/misp-standard-taxonomy-format.txt b/rfc/misp-standard-taxonomy-format.txt
new file mode 100644
index 0000000..2c89d5d
--- /dev/null
+++ b/rfc/misp-standard-taxonomy-format.txt
@@ -0,0 +1,1344 @@
+
+
+
+
+Network Working Group A. Dulaunoy
+Internet-Draft A. Iklody
+Expires: June 2, 2018 CIRCL
+ November 29, 2017
+
+
+ MISP taxonomy format
+
+Abstract
+
+ This document describes the MISP taxonomy format which describes a
+ simple JSON format to represent machine tags (also called triple
+ tags) vocabularies. A public directory of common vocabularies called
+ MISP taxonomies is available and relies on the MISP taxonomy format.
+ MISP taxonomies are used to classify cyber security events, threats,
+ suspicious events, or indicators.
+
+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 https://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 June 2, 2018.
+
+Copyright Notice
+
+ Copyright (c) 2017 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
+ (https://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
+ 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.
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 1]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
+ 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. predicates . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.3. values . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.4. optional fields . . . . . . . . . . . . . . . . . . . . . 4
+ 2.4.1. colour . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.4.2. description . . . . . . . . . . . . . . . . . . . . . 5
+ 2.4.3. numerical_value . . . . . . . . . . . . . . . . . . . 5
+ 3. Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Sample Manifest . . . . . . . . . . . . . . . . . . . . . 7
+ 4. Sample Taxonomy in MISP taxonomy format . . . . . . . . . . . 7
+ 4.1. Admiralty Scale Taxonomy . . . . . . . . . . . . . . . . 7
+ 4.2. Open Source Intelligence - Classification . . . . . . . . 9
+ 4.3. Available taxonomies in the public directory . . . . . . 11
+ 5. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 23
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 23
+ 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
+
+1. Introduction
+
+ Sharing threat information became a fundamental requirements on 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. While sharing such indicators or information,
+ classification plays an important role to ensure adequate
+ distribution, understanding, validation or action of the shared
+ information. MISP taxonomies is a public repository of known
+ vocabularies that can be used in threat information sharing.
+
+ Machine tags were introduced in 2007 [machine-tags] to allow users to
+ be more precise when tagging their pictures with geolocation. So a
+ machine tag is a tag which uses a special syntax to provide more
+ information to users and machines. Machine tags are also known as
+ triple tags due to their format.
+
+ In the MISP taxonomy context, machine tags help analysts to classify
+ their cybersecurity events, indicators or threats. MISP taxonomies
+ can be used for classification, filtering, triggering actions or
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 2]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ visualisation depending on their use in threat intelligence platforms
+ such as MISP [MISP-P].
+
+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
+
+ A machine tag is composed of a namespace (MUST), a predicate (MUST)
+ and an optional value (OPTIONAL).
+
+ Machine tags are represented as a string. Below listed are a set of
+ sample machine tags for different namespaces such as tlp, admiralty-
+ scale and osint.
+
+ tlp:amber
+ admiralty-scale:information-credibility="1"
+ osint:source-type="blog-post"
+
+ The MISP taxonomy format describes how to define a machine tag
+ namespace in a parseable format. The objective is to provide a
+ simple format to describe machine tag (aka triple tag) vocabularies.
+
+2.1. Overview
+
+ The MISP taxonomy format uses the JSON [RFC8259] format. Each
+ namespace is represented as a JSON object with meta information
+ including the following fields: namespace, description, version,
+ type.
+
+ namespace defines the overall namespace of the machine tag. The
+ namespace is represented as a string and MUST be present. The
+ description is represented as a string and MUST be present. A
+ version is represented as a unsigned integer MUST be present. A type
+ defines where a specific taxonomy is applicable and a type can be
+ applicable at event, user or org level. The type is represented as
+ an array containing one or more type and SHOULD be present. If a
+ type is not mentioned, by default, the taxonomy is applicable at
+ event level only. An exclusive boolean property MAY be present and
+ defines at namespace level if the predicates are mutually exclusive.
+
+ predicates defines all the predicates available in the namespace
+ defined. predicates is represented as an array of JSON objects.
+ predicates MUST be present and MUST at least content one element.
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 3]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ values defines all the values for each predicate in the namespace
+ defined. values SHOULD be present.
+
+2.2. predicates
+
+ The predicates array contains one or more JSON objects which lists
+ all the possible predicates. The JSON object contains two fields:
+ value and expanded. value MUST be present. expanded SHOULD be
+ present. value is represented as a string and describes the predicate
+ value. The predicate value MUST not contain spaces or colons.
+ expanded is represented as a string and describes the human-readable
+ version of the predicate value. An exclusive property MAY be present
+ and defines at namespace level if the values are mutually exclusive.
+
+2.3. values
+
+ The values array contain one or more JSON objects which lists all the
+ possible values of a predicate. The JSON object contains two fields:
+ predicate and entry. predicate is represented as a string and
+ describes the predicate value. entry is an array with one or more
+ JSON objects. The JSON object contains two fields: value and
+ expanded. value MUST be present. expanded SHOULD be present. value is
+ represented as a string and describes the machine parsable value.
+ expanded is represented as a string and describes the human-readable
+ version of the value.
+
+2.4. optional fields
+
+2.4.1. colour
+
+ colour fields MAY be used at predicates or values level to set a
+ specify colour that MAY be used by the implementation. The colour
+ field is described as an RGB colour fill in hexadecimal
+ representation.
+
+ Example use of the colour field in the Traffic Light Protocol (TLP):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 4]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ "predicates": [
+ {
+ "colour": "#CC0033",
+ "expanded": "(TLP:RED) Information exclusively and directly
+ given to (a group of) individual recipients.
+ Sharing outside is not legitimate.",
+ "value": "red"
+ },
+ {
+ "colour": "#FFC000",
+ "expanded": "(TLP:AMBER) Information exclusively given
+ to an organization; sharing limited within
+ the organization to be effectively acted upon.",
+ "value": "amber"
+ }...]
+
+2.4.2. description
+
+ description fields MAY be used at predicates or values level to add a
+ descriptive and human-readable information about the specific
+ predicate or value. The field is represented as a string.
+ Implementations MAY use the description field to improve more
+ contextual information. The description at the namespace level is a
+ MUST as described above.
+
+2.4.3. numerical_value
+
+ numerical_value fields MAY be used at a predicate or value level to
+ add a machine-readable numeric value to a specific predicate or
+ value. The field is represented as a JSON number. Implementations
+ SHOULD use the decimal value provided to support scoring or
+ filtering.
+
+ The decimal range for numerical_value SHOULD use a range from 0 up to
+ 100. The range is recommended to support common mathematical
+ properties among taxonomies.
+
+ Example use of the numerical_value in the MISP confidence level:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 5]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ {
+ "predicate": "confidence-level",
+ "entry": [
+ {
+ "expanded": "Completely confident",
+ "value": "completely-confident",
+ "numerical_value": 100
+ },
+ {
+ "expanded": "Usually confident",
+ "value": "usually-confident",
+ "numerical_value": 75
+ },
+ {
+ "expanded": "Fairly confident",
+ "value": "fairly-confident",
+ "numerical_value": 50
+ },
+ {
+ "expanded": "Rarely confident",
+ "value": "rarely-confident",
+ "numerical_value": 25
+ },
+ {
+ "expanded": "Unconfident",
+ "value": "unconfident",
+ "numerical_value": 0
+ },
+ {
+ "expanded": "Confidence cannot be evaluated",
+ "value": "confidence-cannot-be-evalued"
+ }
+ ]
+ }
+
+3. Directory
+
+ The MISP taxonomies directory is publicly available [MISP-T] in a git
+ repository. The repository contains a directory per namespace then a
+ file machinetag.json which contains the taxonomy as described in the
+ format above. In the root of the repository, a MANIFEST.json exists
+ containing a list of all the taxonomies.
+
+ The MANIFEST.json file is composed of an JSON object with metadata
+ like version, license, description, url and path. A taxonomies array
+ describes the taxonomy available with the description, name and
+ version field.
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 6]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+3.1. Sample Manifest
+
+ {
+ "version": "20161009",
+ "license": "CC-0",
+ "description": "Manifest file of MISP taxonomies available.",
+ "url":
+ "https://raw.githubusercontent.com/MISP/misp-taxonomies/master/",
+ "path": "machinetag.json",
+ "taxonomies": [
+ {
+ "description": "The Admiralty Scale (also called the NATO System)
+ is used to rank the reliability of a source and
+ the credibility of an information.",
+ "name": "admiralty-scale",
+ "version": 1
+ },
+ {
+ "description": "Open Source Intelligence - Classification.",
+ "name": "osint",
+ "version": 2
+ }]
+ }
+
+4. Sample Taxonomy in MISP taxonomy format
+
+4.1. Admiralty Scale Taxonomy
+
+ "namespace": "admiralty-scale",
+ "description": "The Admiralty Scale (also called the NATO System)
+ is used to rank the reliability of a source and
+ the credibility of an information.",
+ "version": 1,
+ "predicates": [
+ {
+ "value": "source-reliability",
+ "expanded": "Source Reliability"
+ },
+ {
+ "value": "information-credibility",
+ "expanded": "Information Credibility"
+ }
+ ],
+ "values": [
+ {
+ "predicate": "source-reliability",
+ "entry": [
+ {
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 7]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ "value": "a",
+ "expanded": "Completely reliable"
+ },
+ {
+ "value": "b",
+ "expanded": "Usually reliable"
+ },
+ {
+ "value": "c",
+ "expanded": "Fairly reliable"
+ },
+ {
+ "value": "d",
+ "expanded": "Not usually reliable"
+ },
+ {
+ "value": "e",
+ "expanded": "Unreliable"
+ },
+ {
+ "value": "f",
+ "expanded": "Reliability cannot be judged"
+ }
+ ]
+ },
+ {
+ "predicate": "information-credibility",
+ "entry": [
+ {
+ "value": "1",
+ "expanded": "Confirmed by other sources"
+ },
+ {
+ "value": "2",
+ "expanded": "Probably true"
+ },
+ {
+ "value": "3",
+ "expanded": "Possibly true"
+ },
+ {
+ "value": "4",
+ "expanded": "Doubtful"
+ },
+ {
+ "value": "5",
+ "expanded": "Improbable"
+ },
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 8]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ {
+ "value": "6",
+ "expanded": "Truth cannot be judged"
+ }
+ ]
+ }
+ ]
+ }
+
+4.2. Open Source Intelligence - Classification
+
+ {
+ "values": [
+ {
+ "entry": [
+ {
+ "expanded": "Blog post",
+ "value": "blog-post"
+ },
+ {
+ "expanded": "Technical or analysis report",
+ "value": "technical-report"
+ },
+ {
+ "expanded": "News report",
+ "value": "news-report"
+ },
+ {
+ "expanded": "Pastie-like website",
+ "value": "pastie-website"
+ },
+ {
+ "expanded": "Electronic forum",
+ "value": "electronic-forum"
+ },
+ {
+ "expanded": "Mailing-list",
+ "value": "mailing-list"
+ },
+ {
+ "expanded": "Block or Filter List",
+ "value": "block-or-filter-list"
+ },
+ {
+ "expanded": "Expansion",
+ "value": "expansion"
+ }
+ ],
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 9]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ "predicate": "source-type"
+ },
+ {
+ "predicate": "lifetime",
+ "entry": [
+ {
+ "value": "perpetual",
+ "expanded": "Perpetual",
+ "description": "Information available publicly on long-term"
+ },
+ {
+ "value": "ephemeral",
+ "expanded": "Ephemeral",
+ "description": "Information available publicly on short-term"
+ }
+ ]
+ },
+ {
+ "predicate": "certainty",
+ "entry": [
+ {
+ "numerical_value": 100,
+ "value": "100",
+ "expanded": "100% Certainty",
+ "description": "100% Certainty"
+ },
+ {
+ "numerical_value": 93,
+ "value": "93",
+ "expanded": "93% Almost certain",
+ "description": "93% Almost certain"
+ },
+ {
+ "numerical_value": 75,
+ "value": "75",
+ "expanded": "75% Probable",
+ "description": "75% Probable"
+ },
+ {
+ "numerical_value": 50,
+ "value": "50",
+ "expanded": "50% Chances about even",
+ "description": "50% Chances about even"
+ },
+ {
+ "numerical_value": 30,
+ "value": "30",
+ "expanded": "30% Probably not",
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 10]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ "description": "30% Probably not"
+ },
+ {
+ "numerical_value": 7,
+ "value": "7",
+ "expanded": "7% Almost certainly not",
+ "description": "7% Almost certainly not"
+ },
+ {
+ "numerical_value": 0,
+ "value": "0",
+ "expanded": "0% Impossibility",
+ "description": "0% Impossibility"
+ }
+ ]
+ }
+ ],
+ "namespace": "osint",
+ "description": "Open Source Intelligence - Classification",
+ "version": 3,
+ "predicates": [
+ {
+ "value": "source-type",
+ "expanded": "Source Type"
+ },
+ {
+ "value": "lifetime",
+ "expanded": "Lifetime of the information
+ as Open Source Intelligence"
+ },
+ {
+ "value": "certainty",
+ "expanded": "Certainty of the elements mentioned
+ in this Open Source Intelligence"
+ }
+ ]
+ }
+
+
+4.3. Available taxonomies in the public directory
+
+ The public directory of MISP taxonomies [MISP-T] contains a variety
+ of taxonomy in various fields such as:
+
+ CERT-XLM:
+ CERT-XLM Security Incident Classification.
+
+ DML:
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 11]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ The Detection Maturity Level (DML) model is a capability maturity
+ model for referencing ones maturity in detecting cyber attacks.
+ It's designed for organizations who perform intel-driven detection
+ and response and who put an emphasis on having a mature detection
+ program.
+
+ PAP:
+ The Permissible Actions Protocol - or short: PAP - was designed to
+ indicate how the received information can be used.
+
+ access-method:
+ The access method used to remotely access a system.
+
+ accessnow:
+ Access Now classification to classify an issue (such as security,
+ human rights, youth rights).
+
+ action-taken:
+ Action taken in the case of a security incident (CSIRT
+ perspective).
+
+ admiralty-scale:
+ The Admiralty Scale (also called the NATO System) is used to rank
+ the reliability of a source and the credibility of an information.
+
+ adversary:
+ An overview and description of the adversary infrastructure.
+
+ ais-marking:
+ AIS Marking Schema implementation is maintained by the National
+ Cybersecurity and Communication Integration Center (NCCIC) of the
+ U.S. Department of Homeland Security (DHS)
+
+ analyst-assessment:
+ A series of assessment predicates describing the analyst
+ capabilities to perform analysis. These assessment can be
+ assigned by the analyst him/herself or by another party evaluating
+ the analyst.
+
+ approved-category-of-action:
+ A pre-approved category of action for indicators being shared with
+ partners (MIMIC).
+
+ binary-class:
+ Custom taxonomy for types of binary file.
+
+ cccs:
+ Internal taxonomy for CCCS.
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 12]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ circl:
+ CIRCL Taxonomy is a simple scheme for incident classification and
+ area topic where the incident took place.
+
+ collaborative-intelligence:
+ Collaborative intelligence support language is a common language
+ to support analysts to perform their analysis to get crowdsourced
+ support when using threat intelligence sharing platform like MISP.
+
+ common-taxonomy:
+ The Common Taxonomy for Law Enforcement and The National Network
+ of CSIRTs bridges the gap between the CSIRTs and international Law
+ Enforcement communities by adding a legislative framework to
+ facilitate the harmonisation of incident reporting to competent
+ authorities, the development of useful statistics and sharing
+ information within the entire cybercrime ecosystem.
+
+ copine-scale:
+ The COPINE Scale is a rating system created in Ireland and used in
+ the United Kingdom to categorise the severity of images of child
+ sex abuse.
+
+ cryptocurrency-threat:
+ Threats targetting cryptocurrency, based on CipherTrace report.
+
+ csirtcaseclassification:
+ FIRST CSIRT Case Classification.
+
+ cssa:
+ The CSSA agreed sharing taxonomy.
+
+ cyber-threat-framework:
+ Cyber Threat Framework was developed by the US Government to
+ enable consistent characterization and categorization of cyber
+ threat events, and to identify trends or changes in the activities
+ of cyber adversaries. https://www.dni.gov/index.php/cyber-threat-
+ framework [1]
+
+ data-classification:
+ Data classification for data potentially at risk of exfiltration
+ based on table 2.1 of Solving Cyber Risk book.
+
+ dcso-sharing:
+ DCSO Sharing Taxonomy to classify certain types of MISP events
+ using the DCSO Event Guide
+
+ ddos:
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 13]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ Distributed Denial of Service - or short: DDoS - taxonomy supports
+ the description of Denial of Service attacks and especially the
+ types they belong too.
+
+ de-vs:
+ Taxonomy for the handling of protectively marked information in
+ MISP with German (DE) Government classification markings (VS)
+
+ dhs-ciip-sectors:
+ DHS critical sectors as described in https://www.dhs.gov/critical-
+ infrastructure-sectors [2].
+
+ diamond-model:
+ The Diamond Model for Intrusion Analysis, a phase-based model
+ developed by Lockheed Martin, aims to help categorise and identify
+ the stage of an attack.
+
+ dni-ism:
+ ISM (Information Security Marking Metadata) V13 as described by
+ DNI.gov (Director of National Intelligence - US).
+
+ domain-abuse:
+ Taxonomy to tag domain names used for cybercrime.
+
+ drugs:
+ A taxonomy based on the superclass and class of drugs, based on
+ https://www.drugbank.ca/releases/latest [3]
+
+ economical-impact:
+ Economical impact is a taxonomy to describe the financial impact
+ as positive or negative gain to the tagged information.
+
+ ecsirt:
+ eCSIRT incident classification Appendix C of the eCSIRT EU project
+ including IntelMQ updates.
+
+ enisa:
+ ENISA Threat Taxonomy - A tool for structuring threat information
+ as published in https://www.enisa.europa.eu/topics/threat-risk-
+ management/threats-and-trends/enisa-threat-landscape/etl2015/
+ enisa-threat-taxonomy-a-tool-for-structuring-threat-information
+ [4]
+
+ estimative-language:
+ Estimative language - including likelihood or probability of event
+ based on the Intelligence Community Directive 203 (ICD 203)
+ (6.2.(a)) and JP 2-0, Joint Intelligence.
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 14]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ eu-marketop-and-publicadmin:
+ Market operators and public administrations that must comply to
+ some notifications requirements under EU NIS directive.
+
+ eu-nis-sector-and-subsectors:
+ Sectors and sub sectors as identified by the NIS Directive.
+
+ euci:
+ EU classified information (EUCI) means any information or material
+ designated by a EU security classification, the unauthorised
+ disclosure of which could cause varying degrees of prejudice to
+ the interests of the European Union or of one or more of the
+ Member States as described in COUNCIL DECISION of 23 September
+ 2013 on the security rules for protecting EU classified
+ information
+
+ europol-event:
+ EUROPOL type of events taxonomy.
+
+ europol-incident:
+ EUROPOL class of incident taxonomy.
+
+ event-assessment:
+ A series of assessment predicates describing the event assessment
+ performed to make judgement(s) under a certain level of
+ uncertainty.
+
+ event-classification:
+ Event Classification.
+
+ exercise:
+ Exercise is a taxonomy to describe if the information is part of
+ one or more cyber or crisis exercise.
+
+ false-positive:
+ This taxonomy aims to ballpark the expected amount of false
+ positives.
+
+ file-type:
+ List of known file types.
+
+ flesch-reading-ease:
+ Flesch Reading Ease is a revised system for determining the
+ comprehension difficulty of written material. The scoring of the
+ flesh score can have a maximum of 121.22 and there is no limit on
+ how low a score can be (negative score are valid).
+
+ fpf:
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 15]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ The Future of Privacy Forum (FPF) visual guide to practical de-
+ identification [5] taxonomy is used to evaluate the degree of
+ identifiability of personal data and the types of pseudonymous
+ data, de-identified data and anonymous data. The work of FPF is
+ licensed under a creative commons attribution 4.0 international
+ license.
+
+ fr-classif:
+ French gov information classification system.
+
+ gdpr:
+ Taxonomy related to the REGULATION (EU) 2016/679 OF THE EUROPEAN
+ PARLIAMENT AND OF THE COUNCIL on the protection of natural persons
+ with regard to the processing of personal data and on the free
+ movement of such data, and repealing Directive 95/46/EC (General
+ Data Protection Regulation)
+
+ gsma-attack-category:
+ Taxonomy used by GSMA for their information sharing program with
+ telco describing the attack categories
+
+ gsma-fraud:
+ Taxonomy used by GSMA for their information sharing program with
+ telco describing the various aspects of fraud
+
+ gsma-network-technology:
+ Taxonomy used by GSMA for their information sharing program with
+ telco describing the types of infrastructure. WiP
+
+ honeypot-basic:
+ Christian Seifert, Ian Welch, Peter Komisarczuk, 'Taxonomy of
+ Honeypots', Technical Report CS-TR-06/12, VICTORIA UNIVERSITY OF
+ WELLINGTON, School of Mathematical and Computing Sciences, June
+ 2006, http://www.mcs.vuw.ac.nz/comp/Publications/archive/CS-TR-06/
+ CS-TR-06-12.pdf [6]
+
+ iep:
+ Forum of Incident Response and Security Teams (FIRST) Information
+ Exchange Policy (IEP) framework.
+
+ ifx-vetting:
+ The IFX taxonomy is used to categorise information (MISP events
+ and attributes) to aid in the intelligence vetting process
+
+ incident-disposition:
+ How an incident is classified in its process to be resolved. The
+ taxonomy is inspired from NASA Incident Response and Management
+ Handbook.
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 16]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ infoleak:
+ A taxonomy describing information leaks and especially information
+ classified as being potentially leaked.
+
+ information-security-data-source:
+ Taxonomy to classify the information security data sources
+
+ information-security-indicators:
+ Information security indicators have been standardized by the ETSI
+ Industrial Specification Group (ISG) ISI. These indicators
+ provide the basis to switch from a qualitative to a quantitative
+ culture in IT Security Scope of measurements: External and
+ internal threats (attempt and success), user's deviant behaviours,
+ nonconformities and/or vulnerabilities (software, configuration,
+ behavioural, general security framework). ETSI GS ISI 001-1
+ (V1.1.2): ISI Indicators
+
+ interception-method:
+ The interception method used to intercept traffic.
+
+ kill-chain:
+ Cyber Kill Chain from Lockheed Martin as described in
+ Intelligence-Driven Computer Network Defense Informed by Analysis
+ of Adversary Campaigns and Intrusion Kill Chains.
+
+ maec-delivery-vectors:
+ Vectors used to deliver malware based on MAEC 5.0
+
+ maec-malware-behavior:
+ Malware behaviours based on MAEC 5.0
+
+ maec-malware-capabilities:
+ Malware Capabilities based on MAEC 5.0
+
+ maec-malware-obfuscation-methods:
+ Obfuscation methods used by malware based on MAEC 5.0
+
+ malware_classification:
+ Malware classification based on a SANS whitepaper about malware.
+
+ misp:
+ Internal MISP taxonomy.
+
+ monarc-threat:
+ MONARC threat taxonomy.
+
+ ms-caro-malware:
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 17]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ Malware Type and Platform classification based on Microsoft's
+ implementation of the Computer Antivirus Research Organization
+ (CARO) Naming Scheme and Malware Terminology.
+
+ ms-caro-malware-full:
+ Malware Type and Platform classification based on Microsoft's
+ implementation of the Computer Antivirus Research Organization
+ (CARO) Naming Scheme and Malware Terminology.
+
+ nato:
+ Marking of Classified and Unclassified materials as described by
+ the North Atlantic Treaty Organization, NATO.
+
+ nis:
+ NIS Cybersecurity Incident Taxonomy.
+
+ open_threat:
+ Open Threat Taxonomy v1.1 base on James Tarala of SANS ref. -
+ http://www.auditscripts.com/resources/
+ open_threat_taxonomy_v1.1a.pdf [7]
+
+ osint:
+ Open Source Intelligence - Classification (MISP taxonomies).
+
+ passivetotal:
+ Tags for RiskIQ's passivetotal service
+
+ pentest:
+ Penetration test (pentest) classification.
+
+ priority-level:
+ After an incident is scored, it is assigned a priority level. The
+ six levels listed below are aligned with NCCIC, DHS, and the CISS
+ to help provide a common lexicon when discussing incidents. This
+ priority assignment drives NCCIC urgency, pre-approved incident
+ response offerings, reporting requirements, and recommendations
+ for leadership escalation. Generally, incident priority
+ distribution should follow a similar pattern to the graph below.
+ Based on https://www.us-cert.gov/NCCIC-Cyber-Incident-Scoring-
+ System [8].
+
+ rsit:
+ Reference Security Incident Classification Taxonomy.
+
+ rteventstatus:
+ Status of events used in Request Tracker.
+
+ runtime-packer:
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 18]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ Runtime or software packer used to combine compressed data with
+ the decompression code. The decompression code can add additional
+ obfuscations mechanisms including polymorphic-packer or other
+ obfuscation techniques. This taxonomy lists all the known or
+ official packer used for legitimate use or for packing malicious
+ binaries.
+
+ smart-airports-threats:
+ Threat taxonomy in the scope of securing smart airports by ENISA.
+
+ stealth_malware:
+ Classification based on malware stealth techniques.
+
+ stix-ttp:
+ Representation of the behavior or modus operandi of cyber
+ adversaries (a.k.a TTP) as normalized in STIX
+
+ targeted-threat-index:
+ The Targeted Threat Index is a metric for assigning an overall
+ threat ranking score to email messages that deliver malware to a
+ victim's computer. The TTI metric was first introduced at SecTor
+ 2013 by Seth Hardy as part of the talk "RATastrophe: Monitoring a
+ Malware Menagerie" along with Katie Kleemola and Greg Wiseman.
+
+ tlp:
+ The Traffic Light Protocol - or short: TLP - was designed with the
+ objective to create a favorable classification scheme for sharing
+ sensitive information while keeping the control over its
+ distribution at the same time. Extended with TLP:EX:CHR.
+
+ tor:
+ Taxonomy to describe Tor network infrastructure
+
+ type:
+ Taxonomy to describe different types of intelligence gathering
+ discipline which can be described the origin of intelligence.
+
+ use-case-applicability:
+ The Use Case Applicability categories reflect standard resolution
+ categories, to clearly display alerting rule configuration
+ problems.
+
+ veris:
+ Vocabulary for Event Recording and Incident Sharing (VERIS).
+
+ vocabulaire-des-probabilites-estimatives:
+ Vocabulaire des probabilites estimatives
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 19]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ workflow:
+ Workflow support language is a common language to support
+ intelligence analysts to perform their analysis on data and
+ information.
+
+5. JSON Schema
+
+ The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP
+ taxonomy document as literally described before. The JSON Schema is
+ used validating a MISP taxonomy. The validation is a _MUST_ if the
+ taxonomy is included in the MISP taxonomies directory.
+
+ {
+ "$schema": "http://json-schema.org/schema#",
+ "title": "Validator for misp-taxonomies",
+ "id": "https://www.github.com/MISP/misp-taxonomies/schema.json",
+ "defs": {
+ "entry": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "numerical_value": {
+ "type": "number"
+ },
+ "expanded": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "colour": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ },
+ "required": [
+ "value"
+ ]
+ }
+ }
+ },
+ "values": {
+ "type": "array",
+ "uniqueItems": true,
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 20]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ "items": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "entry": {
+ "$ref": "#/defs/entry"
+ },
+ "predicate": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "predicate"
+ ]
+ }
+ },
+ "predicates": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "numerical_value": {
+ "type": "number"
+ },
+ "colour": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "expanded": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ },
+ "exclusive": {
+ "type": "boolean"
+ },
+ "required": [
+ "value"
+ ]
+ }
+ }
+ }
+ },
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 21]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "version": {
+ "type": "integer"
+ },
+ "description": {
+ "type": "string"
+ },
+ "expanded": {
+ "type": "string"
+ },
+ "namespace": {
+ "type": "string"
+ },
+ "exclusive": {
+ "type": "boolean"
+ },
+ "type": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string",
+ "enum": [
+ "org",
+ "user",
+ "attribute",
+ "event"
+ ]
+ }
+ },
+ "refs": {
+ "type": "array",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "predicates": {
+ "$ref": "#/defs/predicates"
+ },
+ "values": {
+ "$ref": "#/defs/values"
+ }
+ },
+ "required": [
+ "namespace",
+ "description",
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 22]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ "version",
+ "predicates"
+ ]
+ }
+
+6. Acknowledgements
+
+ The authors wish to thank all the MISP community who are supporting
+ the creation of open standards in threat intelligence sharing.
+
+7. References
+
+7.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,
+ .
+
+ [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+ Interchange Format", STD 90, RFC 8259,
+ DOI 10.17487/RFC8259, December 2017,
+ .
+
+7.2. Informative References
+
+ [JSON-SCHEMA]
+ Wright, A., "JSON Schema: A Media Type for Describing JSON
+ Documents", 2016,
+ .
+
+ [machine-tags]
+ Cope, A. S., "Machine tags", 2007,
+ .
+
+ [MISP-P] Community, M., "MISP Project - Malware Information Sharing
+ Platform and Threat Sharing", .
+
+ [MISP-T] Community, M., "MISP Taxonomies - shared and common
+ vocabularies of tags",
+ .
+
+7.3. URIs
+
+ [1] https://www.dni.gov/index.php/cyber-threat-framework
+
+ [2] https://www.dhs.gov/critical-infrastructure-sectors
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 23]
+
+Internet-Draft MISP taxonomy format November 2017
+
+
+ [3] https://www.drugbank.ca/releases/latest
+
+ [4] https://www.enisa.europa.eu/topics/threat-risk-management/
+ threats-and-trends/enisa-threat-landscape/etl2015/enisa-threat-
+ taxonomy-a-tool-for-structuring-threat-information
+
+ [5] https://fpf.org/2016/04/25/a-visual-guide-to-practical-data-de-
+ identification/
+
+ [6] http://www.mcs.vuw.ac.nz/comp/Publications/archive/CS-TR-06/CS-
+ TR-06-12.pdf
+
+ [7] http://www.auditscripts.com/resources/
+ open_threat_taxonomy_v1.1a.pdf
+
+ [8] https://www.us-cert.gov/NCCIC-Cyber-Incident-Scoring-System
+
+Authors' Addresses
+
+ Alexandre Dulaunoy
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1611
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: alexandre.dulaunoy@circl.lu
+
+
+ Andras Iklody
+ Computer Incident Response Center Luxembourg
+ 16, bd d'Avranches
+ Luxembourg L-1611
+ Luxembourg
+
+ Phone: +352 247 88444
+ Email: andras.iklody@circl.lu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dulaunoy & Iklody Expires June 2, 2018 [Page 24]
diff --git a/standards.md b/standards.md
new file mode 100644
index 0000000..8b8bd57
--- /dev/null
+++ b/standards.md
@@ -0,0 +1,42 @@
+---
+layout: splash
+title: MISP Standards
+excerpt: "Official Published MISP Standards"
+author_profile: false
+header:
+ overlay_image: /assets/images/misp-long.png
+ overlay_filter: 0.8
+---
+
+
+# MISP Standards
+
+## MISP core format
+
+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 software and other Threat Intelligence Platforms.
+
+Specification: [TXT](https://www.misp-standard.org/rfc/misp-standard-core.txt) - [HTML](https://www.misp-standard.org/rfc/misp-standard-core.html)
+
+## MISP object template format
+
+This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates is available and relies on the MISP object reference format.
+
+Specification: [TXT](https://www.misp-standard.org/rfc/misp-standard-object-template-format.txt) - [HTML](https://www.misp-standard.org/rfc/misp-standard-object-template-format.html)
+
+## MISP taxonomy format
+
+This document describes the MISP taxonomy format which describes a simple JSON format to represent machine tags (also called triple tags) vocabularies. A public directory of common vocabularies called MISP taxonomies is available and relies on the MISP taxonomy format. MISP taxonomies are used to classify cyber security events, threats, suspicious events, or indicators.
+
+Specification: [TXT](https://www.misp-standard.org/rfc/misp-standard-taxonomy-format.txt) - [HTML](https://www.misp-standard.org/rfc/misp-standard-taxonomy-format.html)
+
+## MISP galaxy format
+
+This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
+
+Specification: [TXT](https://www.misp-standard.org/rfc/misp-standard-galaxy-format.txt) - [HTML](https://www.misp-standard.org/rfc/misp-standard-galaxy-format.html)
+
+# Upcoming standards
+
+- MISP warninglist format
+
+