MISP
/
misp-standard.org
mirror of https://github.com/MISP/misp-standard.org
2
0
Fork 0
Code Issues Releases Wiki Activity

chg: standards are now imported

pull/1/head
Alexandre Dulaunoy 2019-07-16 13:58:45 +02:00
parent d1355bcbeb
commit 6d1ab58a40
No known key found for this signature in database
GPG Key ID: 09E2CD4944E6CBCD
10 changed files with 11971 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
_data/navigation.yml
View File

@ -2,6 +2,8 @@
main:
- title: "About"
url: /about/
- title: "Standards"
url: /standards/
- title: "News"
url: /post/
# - title: "Sample Posts"

2370
rfc/misp-standard-core.html Normal file
View File

File diff suppressed because it is too large Load Diff

2912
rfc/misp-standard-core.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1006
rfc/misp-standard-galaxy-format.html Normal file
View File

File diff suppressed because it is too large Load Diff

896
rfc/misp-standard-galaxy-format.txt Normal file
View File

@ -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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
5.2. Informative References
[CFR] Relations, C. O. F., "Cyber Operations Tracker - Council
on Foreign Relations", 2018,
<https://www.cfr.org/interactive/cyber-operations>.
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,
<https://tools.ietf.org/html/draft-wright-json-schema>.
[MISP-G] Community, M., "MISP Galaxy - Public Repository",
<https://github.com/MISP/misp-galaxy>.
[MISP-G-DOC]
Community, M., "MISP Galaxy - Documentation of the Public
Repository", <https://www.misp-project.org/galaxy.html>.
[MISP-P] Community, M., "MISP Project - Malware Information Sharing
Platform and Threat Sharing", <https://github.com/MISP>.
[MISP-R] Community, M., "MISP Object Relationship Types - common
vocabulary of relationships", <https://github.com/MISP/
misp-objects/tree/master/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]

964
rfc/misp-standard-object-template-format.html Normal file
View File

@ -0,0 +1,964 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>MISP object template format</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Conventions and Terminology">
<link href="#rfc.section.2" rel="Chapter" title="2 Format">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Overview">
<link href="#rfc.section.2.1.1" rel="Chapter" title="2.1.1 Object Template">
<link href="#rfc.section.2.1.2" rel="Chapter" title="2.1.2 attributes">
<link href="#rfc.section.2.1.3" rel="Chapter" title="2.1.3 Sample Object Template object">
<link href="#rfc.section.2.1.4" rel="Chapter" title="2.1.4 Object Relationships">
<link href="#rfc.section.3" rel="Chapter" title="3 Directory">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Existing and public MISP object templates">
<link href="#rfc.section.4" rel="Chapter" title="4 Acknowledgements">
<link href="#rfc.references" rel="Chapter" title="5 References">
<link href="#rfc.references.1" rel="Chapter" title="5.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="5.2 Informative References">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.23.1 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Dulaunoy, A. and A. Iklody" />
<meta name="dct.identifier" content="urn:ietf:id:" />
<meta name="dct.issued" scheme="ISO8601" content="2018-04-10" />
<meta name="dct.abstract" content="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." />
<meta name="description" content="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." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">A. Dulaunoy</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">A. Iklody</td>
</tr>
<tr>
<td class="left">Expires: October 12, 2018</td>
<td class="right">CIRCL</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">April 10, 2018</td>
</tr>
</tbody>
</table>
<p class="title">MISP object template format<br />
<span class="filename"></span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>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 <a href="#MISP-O" class="xref">[MISP-O]</a> is available and relies on the MISP object reference format.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>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/.</p>
<p>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."</p>
<p>This Internet-Draft will expire on October 12, 2018.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>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.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Conventions and Terminology</a>
</li>
</ul><li>2. <a href="#rfc.section.2">Format</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Overview</a>
</li>
<ul><li>2.1.1. <a href="#rfc.section.2.1.1">Object Template</a>
</li>
<li>2.1.2. <a href="#rfc.section.2.1.2">attributes</a>
</li>
<li>2.1.3. <a href="#rfc.section.2.1.3">Sample Object Template object</a>
</li>
<li>2.1.4. <a href="#rfc.section.2.1.4">Object Relationships</a>
</li>
</ul></ul><li>3. <a href="#rfc.section.3">Directory</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">Existing and public MISP object templates</a>
</li>
</ul><li>4. <a href="#rfc.section.4">Acknowledgements</a>
</li>
<li>5. <a href="#rfc.references">References</a>
</li>
<ul><li>5.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>5.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">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.</p>
<p id="rfc.section.1.p.2">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.</p>
<p id="rfc.section.1.p.3">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.</p>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#conventions-and-terminology" id="conventions-and-terminology">Conventions and Terminology</a>
</h1>
<p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" class="xref">[RFC2119]</a>.</p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#format" id="format">Format</a>
</h1>
<p id="rfc.section.2.p.1">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.</p>
<p id="rfc.section.2.p.2">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).</p>
<p id="rfc.section.2.p.3">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).</p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#overview" id="overview">Overview</a>
</h1>
<p id="rfc.section.2.1.p.1">The MISP object template format uses the JSON <a href="#RFC8259" class="xref">[RFC8259]</a> format. Each template is represented as a JSON object with meta information including the following fields: uuid, requiredOneOf, description, version, meta-category, name.</p>
<h1 id="rfc.section.2.1.1">
<a href="#rfc.section.2.1.1">2.1.1.</a> <a href="#object-template" id="object-template">Object Template</a>
</h1>
<h1 id="rfc.section.2.1.1.1">
<a href="#rfc.section.2.1.1.1">2.1.1.1.</a> <a href="#uuid" id="uuid">uuid</a>
</h1>
<p id="rfc.section.2.1.1.1.p.1">uuid represents the Universally Unique IDentifier (UUID) <a href="#RFC4122" class="xref">[RFC4122]</a> 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.</p>
<p id="rfc.section.2.1.1.1.p.2">uuid is represented as a JSON string. uuid MUST be present.</p>
<h1 id="rfc.section.2.1.1.2">
<a href="#rfc.section.2.1.1.2">2.1.1.2.</a> <a href="#requiredoneof" id="requiredoneof">requiredOneOf</a>
</h1>
<p id="rfc.section.2.1.1.2.p.1">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.</p>
<h1 id="rfc.section.2.1.1.3">
<a href="#rfc.section.2.1.1.3">2.1.1.3.</a> <a href="#required" id="required">required</a>
</h1>
<p id="rfc.section.2.1.1.3.p.1">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.</p>
<h1 id="rfc.section.2.1.1.4">
<a href="#rfc.section.2.1.1.4">2.1.1.4.</a> <a href="#description" id="description">description</a>
</h1>
<p id="rfc.section.2.1.1.4.p.1">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.</p>
<h1 id="rfc.section.2.1.1.5">
<a href="#rfc.section.2.1.1.5">2.1.1.5.</a> <a href="#version" id="version">version</a>
</h1>
<p id="rfc.section.2.1.1.5.p.1">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.</p>
<p id="rfc.section.2.1.1.5.p.2">version is represented as a JSON string. version MUST be present.</p>
<h1 id="rfc.section.2.1.1.6">
<a href="#rfc.section.2.1.1.6">2.1.1.6.</a> <a href="#meta-category" id="meta-category">meta-category</a>
</h1>
<p id="rfc.section.2.1.1.6.p.1">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.</p>
<p id="rfc.section.2.1.1.6.p.2">meta-category is represented as a JSON string. meta-category MUST be present.</p>
<h1 id="rfc.section.2.1.1.7">
<a href="#rfc.section.2.1.1.7">2.1.1.7.</a> <a href="#name" id="name">name</a>
</h1>
<p id="rfc.section.2.1.1.7.p.1">name represents the human-readable name of the objects created using the given template, describing the intent of the object package.</p>
<p id="rfc.section.2.1.1.7.p.2">name is represented as a JSON string. name MUST be present</p>
<h1 id="rfc.section.2.1.2">
<a href="#rfc.section.2.1.2">2.1.2.</a> <a href="#attributes" id="attributes">attributes</a>
</h1>
<p id="rfc.section.2.1.2.p.1">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.</p>
<p id="rfc.section.2.1.2.p.2">attributes is represented as a JSON list. attributes MUST be present.</p>
<h1 id="rfc.section.2.1.2.1">
<a href="#rfc.section.2.1.2.1">2.1.2.1.</a> <a href="#description-1" id="description-1">description</a>
</h1>
<p id="rfc.section.2.1.2.1.p.1">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.</p>
<h1 id="rfc.section.2.1.2.2">
<a href="#rfc.section.2.1.2.2">2.1.2.2.</a> <a href="#ui-priority" id="ui-priority">ui-priority</a>
</h1>
<p id="rfc.section.2.1.2.2.p.1">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.</p>
<h1 id="rfc.section.2.1.2.3">
<a href="#rfc.section.2.1.2.3">2.1.2.3.</a> <a href="#misp-attribute" id="misp-attribute">misp-attribute</a>
</h1>
<p id="rfc.section.2.1.2.3.p.1">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.</p>
<p id="rfc.section.2.1.2.3.p.2">The misp-attribute field MUST be present.</p>
<h1 id="rfc.section.2.1.2.4">
<a href="#rfc.section.2.1.2.4">2.1.2.4.</a> <a href="#disable-correlation" id="disable-correlation">disable_correlation</a>
</h1>
<p id="rfc.section.2.1.2.4.p.1">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.</p>
<p id="rfc.section.2.1.2.4.p.2">The misp-attribute field MAY be present.</p>
<h1 id="rfc.section.2.1.2.5">
<a href="#rfc.section.2.1.2.5">2.1.2.5.</a> <a href="#categories" id="categories">categories</a>
</h1>
<p id="rfc.section.2.1.2.5.p.1">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.</p>
<p id="rfc.section.2.1.2.5.p.2">The categories field MAY be present.</p>
<h1 id="rfc.section.2.1.2.6">
<a href="#rfc.section.2.1.2.6">2.1.2.6.</a> <a href="#multiple" id="multiple">multiple</a>
</h1>
<p id="rfc.section.2.1.2.6.p.1">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.</p>
<p id="rfc.section.2.1.2.6.p.2">The multiple field MAY be present.</p>
<h1 id="rfc.section.2.1.2.7">
<a href="#rfc.section.2.1.2.7">2.1.2.7.</a> <a href="#sane-default" id="sane-default">sane_default</a>
</h1>
<p id="rfc.section.2.1.2.7.p.1">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.</p>
<p id="rfc.section.2.1.2.7.p.2">The sane_default field MAY be present.</p>
<h1 id="rfc.section.2.1.2.8">
<a href="#rfc.section.2.1.2.8">2.1.2.8.</a> <a href="#values-list" id="values-list">values_list</a>
</h1>
<p id="rfc.section.2.1.2.8.p.1">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.</p>
<p id="rfc.section.2.1.2.8.p.2">The value_list field MAY be present.</p>
<h1 id="rfc.section.2.1.3">
<a href="#rfc.section.2.1.3">2.1.3.</a> <a href="#sample-object-template-object" id="sample-object-template-object">Sample Object Template object</a>
</h1>
<p id="rfc.section.2.1.3.p.1">The MISP object template directory is publicly available <a href="#MISP-O" class="xref">[MISP-O]</a> in a git repository and contains more than 60 object templates. As illustration, two sample objects templates are included.</p>
<h1 id="rfc.section.2.1.3.1">
<a href="#rfc.section.2.1.3.1">2.1.3.1.</a> <a href="#credit-card-object-template" id="credit-card-object-template">credit-card object template</a>
</h1>
<pre>{
"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"
}
</pre>
<h1 id="rfc.section.2.1.3.2">
<a href="#rfc.section.2.1.3.2">2.1.3.2.</a> <a href="#credential-object-template" id="credential-object-template">credential object template</a>
</h1>
<pre>{
"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"
]
},
"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"
}
</pre>
<h1 id="rfc.section.2.1.4">
<a href="#rfc.section.2.1.4">2.1.4.</a> <a href="#object-relationships" id="object-relationships">Object Relationships</a>
</h1>
<h1 id="rfc.section.2.1.4.1">
<a href="#rfc.section.2.1.4.1">2.1.4.1.</a> <a href="#name-1" id="name-1">name</a>
</h1>
<p id="rfc.section.2.1.4.1.p.1">name represents the human-readable relationship type which can be used when creating MISP object relations.</p>
<p id="rfc.section.2.1.4.1.p.2">name is represented as a JSON string. name MUST be present.</p>
<h1 id="rfc.section.2.1.4.2">
<a href="#rfc.section.2.1.4.2">2.1.4.2.</a> <a href="#description-2" id="description-2">description</a>
</h1>
<p id="rfc.section.2.1.4.2.p.1">description is represented as a JSON string and contains the description of the object relationship type. The description field MUST be present.</p>
<h1 id="rfc.section.2.1.4.3">
<a href="#rfc.section.2.1.4.3">2.1.4.3.</a> <a href="#format-1" id="format-1">format</a>
</h1>
<p id="rfc.section.2.1.4.3.p.1">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.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#directory" id="directory">Directory</a>
</h1>
<p id="rfc.section.3.p.1">The MISP object template directory is publicly available <a href="#MISP-O" class="xref">[MISP-O]</a> 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.</p>
<p id="rfc.section.3.p.2">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 <a href="#MISP-O-DOC" class="xref">[MISP-O-DOC]</a>.</p>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#existing-and-public-misp-object-templates" id="existing-and-public-misp-object-templates">Existing and public MISP object templates</a>
</h1>
<p></p>
<ul>
<li>tsk-chats - An Object Template to gather information from evidential or interesting exchange of messages identified during a digital forensic investigation.</li>
<li>tsk-web-bookmark - An Object Template to add evidential bookmarks identified during a digital forensic investigation.</li>
<li>tsk-web-cookie - An TSK-Autopsy Object Template to represent cookies identified during a forensic investigation.</li>
<li>tsk-web-downloads - An Object Template to add web-downloads.</li>
<li>tsk-web-history - An Object Template to share web history information.</li>
<li>tsk-web-search-query - An Object Template to share web search query information.</li>
<li>ail-leak - An information leak as defined by the AIL Analysis Information Leak framework.</li>
<li>ais-info - Automated Indicator Sharing (AIS) Information Source Markings.</li>
<li>android-permission - A set of android permissions - one or more permission(s) which can be linked to other objects (e.g. malware, app).</li>
<li>annotation - An annotation object allowing analysts to add annotations, comments, executive summary to a MISP event, objects or attributes.</li>
<li>anonymisation - Anonymisation object describing an anonymisation technique used to encode MISP attribute values. Reference: <a href="https://www.caida.org/tools/taxonomy/anonymization.xml">https://www.caida.org/tools/taxonomy/anonymization.xml</a>.</li>
<li>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.</li>
<li>authenticode-signerinfo - Authenticode Signer Info.</li>
<li>av-signature - Antivirus detection signature.</li>
<li>bank-account - An object describing bank account information based on account description from goAML 4.0.</li>
<li>bgp-hijack - Object encapsulating BGP Hijack description as specified, for example, by bgpstream.com.</li>
<li>cap-alert - Common Alerting Protocol Version (CAP) alert object.</li>
<li>cap-info - Common Alerting Protocol Version (CAP) info object.</li>
<li>cap-resource - Common Alerting Protocol Version (CAP) resource object.</li>
<li>coin-address - An address used in a cryptocurrency.</li>
<li>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 &#8212; keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol. (as defined by the Mozilla foundation.</li>
<li>cortex - Cortex object describing a complete cortex analysis. Observables would be attribute with a relationship from this object.</li>
<li>cortex-taxonomy - Cortex object describing an Cortex Taxonomy (or mini report).</li>
<li>course-of-action - An object describing a specific measure taken to prevent or respond to an attack.</li>
<li>cowrie - Cowrie honeypot object template.</li>
<li>credential - Credential describes one or more credential(s) including password(s), api key(s) or decryption key(s).</li>
<li>credit-card - A payment card like credit card, debit card or any similar cards which can be used for financial transactions.</li>
<li>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.</li>
<li>device - An object to define a device.</li>
<li>diameter-attack - Attack as seen on diameter authentication against a GSM, UMTS or LTE network.</li>
<li>domain-ip - A domain and IP address seen as a tuple in a specific time frame.</li>
<li>elf - Object describing a Executable and Linkable Format.</li>
<li>elf-section - Object describing a section of an Executable and Linkable Format.</li>
<li>email - Email object describing an email with meta-information.</li>
<li>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.</li>
<li>facial-composite - An object which describes a facial composite.</li>
<li>fail2ban - Fail2ban event.</li>
<li>file - File object describing a file with meta-information.</li>
<li>forensic-case - An object template to describe a digital forensic case.</li>
<li>forensic-evidence - An object template to describe a digital forensic evidence.</li>
<li>geolocation - An object to describe a geographic location.</li>
<li>gtp-attack - GTP attack object as seen on a GSM, UMTS or LTE network.</li>
<li>http-request - A single HTTP request header.</li>
<li>ilr-impact - Institut Luxembourgeois de Regulation - Impact.</li>
<li>ilr-notification-incident - Institut Luxembourgeois de Regulation - Notification d'incident.</li>
<li