Specifications used in the MISP project including MISP core format
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

3081 lines
92 KiB

Network Working Group A. Dulaunoy
Internet-Draft A. Iklody
Intended status: Informational CIRCL
Expires: April 24, 2021 October 21, 2020
MISP core format
draft-dulaunoy-misp-core-format
Abstract
This document describes the MISP core format used to exchange
indicators and threat information between MISP (Open Source Threat
Intelligence Sharing Platform formerly known as Malware Information
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 April 24, 2021.
Copyright Notice
Copyright (c) 2020 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 & Iklody Expires April 24, 2021 [Page 1]
Internet-Draft MISP core format October 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
5 years ago
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
5 years ago
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1. Event Attributes . . . . . . . . . . . . . . . . . . 4
5 years ago
2.3. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 years ago
2.3.1. Org . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Orgc . . . . . . . . . . . . . . . . . . . . . . . . 8
5 years ago
2.4. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Sample Attribute Object . . . . . . . . . . . . . . . 9
2.4.2. Attribute Attributes . . . . . . . . . . . . . . . . 9
2.5. ShadowAttribute . . . . . . . . . . . . . . . . . . . . . 16
2.5.1. Sample Attribute Object . . . . . . . . . . . . . . . 16
2.5.2. ShadowAttribute Attributes . . . . . . . . . . . . . 16
2.5.3. Org . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6. Object . . . . . . . . . . . . . . . . . . . . . . . . . 23
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. EventReport . . . . . . . . . . . . . . . . . . . . . . . 30
2.8.1. id . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.2. UUID . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.3. event_id . . . . . . . . . . . . . . . . . . . . . . 31
2.8.4. name . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.5. content . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.6. distribution . . . . . . . . . . . . . . . . . . . . 32
2.8.7. sharing_group_id . . . . . . . . . . . . . . . . . . 32
2.8.8. timestamp . . . . . . . . . . . . . . . . . . . . . . 32
2.8.9. deleted . . . . . . . . . . . . . . . . . . . . . . . 33
2.9. Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.9.1. Sample Tag . . . . . . . . . . . . . . . . . . . . . 33
2.10. Sighting . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10.1. Sample Sighting . . . . . . . . . . . . . . . . . . 34
2.11. Galaxy . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.11.1. Sample Galaxy . . . . . . . . . . . . . . . . . . . 35
3. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 37
4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1. Sample Manifest . . . . . . . . . . . . . . . . . . . 52
Dulaunoy & Iklody Expires April 24, 2021 [Page 2]
Internet-Draft MISP core format October 2020
5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 53
6. Security Considerations . . . . . . . . . . . . . . . . . . . 53
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . 54
9.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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
5 years ago
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.
5 years ago
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].
5 years ago
2. Format
2.1. Overview
The MISP core format is in the JSON [RFC8259] format. In MISP, an
5 years ago
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
5 years ago
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.
Dulaunoy & Iklody Expires April 24, 2021 [Page 3]
Internet-Draft MISP core format October 2020
2.2.1. Event Attributes
2.2.1.1. uuid
uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of
the event. The uuid MUST be preserved for any updates or transfer of
the same event. UUID version 4 is RECOMMENDED when assigning it to a
new event.
uuid is represented as a JSON string. uuid MUST be present.
2.2.1.2. id
id represents the human-readable identifier associated to the event
for a specific MISP instance. A human-readable identifier MUST be
represented as an unsigned integer.
id is represented as a JSON string. id SHALL be present.
5 years ago
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.
5 years ago
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.
5 years ago
info is represented as a JSON string. info MUST be present.
5 years ago
2.2.1.5. threat_level_id
threat_level_id represents the threat level.
5 years ago
4:
Undefined
5 years ago
3:
Low
2:
Dulaunoy & Iklody Expires April 24, 2021 [Page 4]
Internet-Draft MISP core format October 2020
Medium
5 years ago
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.
2.2.1.6. analysis
analysis represents the analysis level.
0:
Initial
1:
Ongoing
5 years ago
5 years ago
2:
Complete
5 years ago
If a higher granularity is required, a MISP taxonomy applied as a Tag
SHOULD be preferred.
5 years ago
analysis is represented as a JSON string. analysis SHALL be present.
5 years ago
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.
5 years ago
5 years ago
date is represented as a JSON string. date MUST be present.
5 years ago
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.
Dulaunoy & Iklody Expires April 24, 2021 [Page 5]
Internet-Draft MISP core format October 2020
5 years ago
2.2.1.9. publish_timestamp
5 years ago
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.
5 years ago
5 years ago
publish_timestamp is represented as a JSON string. publish_timestamp
MUST be present.
5 years ago
2.2.1.10. org_id
5 years ago
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.
5 years ago
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.
5 years ago
2.2.1.11. orgc_id
5 years ago
orgc_id represents a human-readable identifier referencing an Orgc
object of the organisation which created the event.
5 years ago
The orgc_id and Org object MUST be preserved for any updates or
5 years ago
transfer of the same event.
orgc_id is represented as a JSON string. orgc_id MUST be present.
5 years ago
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.
5 years ago
2.2.1.13. distribution
5 years ago
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.
Dulaunoy & Iklody Expires April 24, 2021 [Page 6]
Internet-Draft MISP core format October 2020
5 years ago
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
5 years ago
4
Sharing Group
5 years ago
2.2.1.14. sharing_group_id
5 years ago
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.
5 years ago
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".
5 years ago
2.2.1.15. extends_uuid
extends_uuid represents which event is extended by this event. The
4 years ago
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.
5 years ago
2.3. Objects
5 years ago
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.
5 years ago
Dulaunoy & Iklody Expires April 24, 2021 [Page 7]
Internet-Draft MISP core format October 2020
The name is a readable description of the organisation and SHOULD be
5 years ago
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.
5 years ago
5 years ago
uuid, name and id are represented as a JSON string. uuid, name and id
MUST be present.
5 years ago
5 years ago
2.3.1.1. Sample Org Object
5 years ago
"Org": {
"id": "2",
"name": "CIRCL",
"uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f"
}
5 years ago
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.
5 years ago
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.
5 years ago
A MISP document MUST at least includes category-type-value triplet
described in section "Attribute Attributes".
Dulaunoy & Iklody Expires April 24, 2021 [Page 8]
Internet-Draft MISP core format October 2020
2.4.1. Sample Attribute Object
"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
}
5 years ago
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.
5 years ago
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.
5 years ago
Dulaunoy & Iklody Expires April 24, 2021 [Page 9]
Internet-Draft MISP core format October 2020
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
5 years ago
Artifacts dropped
md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
sha3-224, sha3-256, sha3-384, sha3-512, ssdeep, imphash, telfhash,
impfuzzy, authentihash, vhash, cdhash, filename, filename|md5,
filename|sha1, filename|sha224, filename|sha256, filename|sha384,
filename|sha512, filename|sha512/224, filename|sha512/256,
filename|sha3-224, filename|sha3-256, filename|sha3-384,
filename|sha3-512, filename|authentihash, filename|vhash,
filename|ssdeep, filename|tlsh, filename|imphash,
filename|impfuzzy, filename|pehash, regkey, regkey|value, pattern-
in-file, pattern-in-memory, filename-pattern, 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,
kusto-query, mime-type, anonymised, pgp-public-key, pgp-private-
key
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, email
External analysis
md5, sha1, sha256, sha3-224, sha3-256, sha3-384, sha3-512,
filename, filename|md5, filename|sha1, filename|sha256,
filename|sha3-224, filename|sha3-256, filename|sha3-384,
filename|sha3-512, 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, filename-pattern,
vulnerability, cpe, weakness, 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, community-id
Financial fraud
btc, dash, xmr, iban, bic, bank-account-nr, aba-rtn, bin, cc-
number, prtn, phone-number, comment, text, other, hex, anonymised
Dulaunoy & Iklody Expires April 24, 2021 [Page 10]
Internet-Draft MISP core format October 2020
Internal reference
text, link, comment, other, hex, anonymised, git-commit-id
Network activity
ip-src, ip-dst, ip-dst|port, ip-src|port, port, hostname, domain,
domain|ip, mac-address, mac-eui-64, email, email-dst, email-src,
eppn, url, uri, user-agent, http-method, AS, snort, pattern-in-
file, filename-pattern, 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, community-id, email-subject
Other
comment, text, other, size-in-bytes, counter, datetime, cpe, port,
float, hex, phone-number, boolean, anonymised, pgp-public-key,
pgp-private-key
5 years ago
Payload delivery
md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
sha3-224, sha3-256, sha3-384, sha3-512, ssdeep, imphash, telfhash,
impfuzzy, authentihash, vhash, pehash, tlsh, cdhash, filename,
filename|md5, filename|sha1, filename|sha224, filename|sha256,
filename|sha384, filename|sha512, filename|sha512/224,
filename|sha512/256, filename|sha3-224, filename|sha3-256,
filename|sha3-384, filename|sha3-512, filename|authentihash,
filename|vhash, 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,
email-src, email-dst, email-subject, email-attachment, email-body,
url, user-agent, AS, pattern-in-file, pattern-in-traffic,
filename-pattern, stix2-pattern, yara, sigma, mime-type,
attachment, malware-sample, link, malware-type, comment, text,
hex, vulnerability, cpe, weakness, 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, chrome-extension-id,
whois-registrant-email, anonymised
5 years ago
Payload installation
md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256,
sha3-224, sha3-256, sha3-384, sha3-512, ssdeep, imphash, telfhash,
impfuzzy, authentihash, vhash, pehash, tlsh, cdhash, filename,
filename|md5, filename|sha1, filename|sha224, filename|sha256,
filename|sha384, filename|sha512, filename|sha512/224,
filename|sha512/256, filename|sha3-224, filename|sha3-256,
Dulaunoy & Iklody Expires April 24, 2021 [Page 11]
Internet-Draft MISP core format October 2020
filename|sha3-384, filename|sha3-512, filename|authentihash,
filename|vhash, filename|ssdeep, filename|tlsh, filename|imphash,
filename|impfuzzy, filename|pehash, pattern-in-file, pattern-in-
traffic, pattern-in-memory, filename-pattern, stix2-pattern, yara,
sigma, vulnerability, cpe, weakness, attachment, malware-sample,
malware-type, comment, text, hex, x509-fingerprint-sha1, x509-
fingerprint-md5, x509-fingerprint-sha256, mobile-application-id,
chrome-extension-id, other, mime-type, anonymised
5 years ago
Payload type
comment, text, other, anonymised
5 years ago
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, email, pgp-public-key, pgp-private-key
Social network
github-username, github-repository, github-organisation, jabber-
id, twitter-id, email, email-src, email-dst, eppn, comment, text,
other, whois-registrant-email, anonymised, pgp-public-key, pgp-
private-key
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
5 years ago
5 years ago
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.
Dulaunoy & Iklody Expires April 24, 2021 [Page 12]
Internet-Draft MISP core format October 2020
5 years ago
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.
5 years ago
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.
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.
5 years ago
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
Dulaunoy & Iklody Expires April 24, 2021 [Page 13]
Internet-Draft MISP core format October 2020
5 years ago
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.
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".
5 years ago
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.
5 years ago
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".
Dulaunoy & Iklody Expires April 24, 2021 [Page 14]
Internet-Draft MISP core format October 2020
5 years ago
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
5 years ago
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.
5 years ago
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.
5 years ago
2.4.2.15. value
5 years ago
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.
Dulaunoy & Iklody Expires April 24, 2021 [Page 15]
Internet-Draft MISP core format October 2020
last_seen is represented as a JSON string. last_seen MAY be present.
5 years ago
2.5. ShadowAttribute
5 years ago
5 years ago
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.
2.5.1. Sample Attribute Object
5 years ago
"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
5 years ago
}
2.5.2. ShadowAttribute Attributes
5 years ago
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