idnits 2.17.1 draft-dulaunoy-misp-core-format-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** The abstract seems to contain references ([MISP-P]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2018) is 2269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'MISP-R' is defined on line 2018, but no explicit reference was found in the text == Unused Reference: 'MISP-T' is defined on line 2022, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Dulaunoy 3 Internet-Draft A. Iklody 4 Intended status: Informational CIRCL 5 Expires: August 13, 2018 February 9, 2018 7 MISP core format 8 draft-dulaunoy-misp-core-format-03 10 Abstract 12 This document describes the MISP core format used to exchange 13 indicators and threat information between MISP (Malware Information 14 and threat Sharing Platform) instances. The JSON format includes the 15 overall structure along with the semantic associated for each 16 respective key. The format is described to support other 17 implementations which reuse the format and ensuring an 18 interoperability with existing MISP [MISP-P] software and other 19 Threat Intelligence Platforms. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 13, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 57 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2.1. Event Attributes . . . . . . . . . . . . . . . . . . 3 61 2.3. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3.1. Org . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3.2. Orgc . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.4. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.4.1. Sample Attribute Object . . . . . . . . . . . . . . . 8 66 2.4.2. Attribute Attributes . . . . . . . . . . . . . . . . 8 67 2.5. ShadowAttribute . . . . . . . . . . . . . . . . . . . . . 14 68 2.5.1. Sample Attribute Object . . . . . . . . . . . . . . . 14 69 2.5.2. ShadowAttribute Attributes . . . . . . . . . . . . . 15 70 2.5.3. Org . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 2.6. Object . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 2.6.1. Sample Object object . . . . . . . . . . . . . . . . 21 73 2.6.2. Object Attributes . . . . . . . . . . . . . . . . . . 22 74 2.7. Object References . . . . . . . . . . . . . . . . . . . . 25 75 2.7.1. Sample ObjectReference object . . . . . . . . . . . . 25 76 2.7.2. ObjectReference Attributes . . . . . . . . . . . . . 26 77 2.8. Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 78 2.8.1. Sample Tag . . . . . . . . . . . . . . . . . . . . . 28 79 2.9. Sighting . . . . . . . . . . . . . . . . . . . . . . . . 28 80 2.9.1. Sample Sighting . . . . . . . . . . . . . . . . . . . 30 81 2.10. Galaxy . . . . . . . . . . . . . . . . . . . . . . . . . 30 82 2.10.1. Sample Galaxy . . . . . . . . . . . . . . . . . . . 30 83 3. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 41 85 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 41 86 4.1.1. Sample Manifest . . . . . . . . . . . . . . . . . . . 42 87 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 44 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 90 8. Sample MISP file . . . . . . . . . . . . . . . . . . . . . . 44 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 44 93 9.2. Informative References . . . . . . . . . . . . . . . . . 45 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 96 1. Introduction 98 Sharing threat information became a fundamental requirements in the 99 Internet, security and intelligence community at large. Threat 100 information can include indicators of compromise, malicious file 101 indicators, financial fraud indicators or even detailed information 102 about a threat actor. MISP [MISP-P] started as an open source 103 project in late 2011 and the MISP format started to be widely used as 104 an exchange format within the community in the past years. The aim 105 of this document is to describe the specification and the MISP core 106 format. 108 1.1. Conventions and Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Format 116 2.1. Overview 118 The MISP core format is in the JSON [RFC4627] format. In MISP, an 119 event is composed of a single JSON object. 121 A capitalized key (like Event, Org) represent a data model and a non- 122 capitalised key is just an attribute. This nomenclature can support 123 an implementation to represent the MISP format in another data 124 structure. 126 2.2. Event 128 An event is a simple meta structure scheme where attributes and meta- 129 data are embedded to compose a coherent set of indicators. An event 130 can be composed from an incident, a security analysis report or a 131 specific threat actor analysis. The meaning of an event only depends 132 of the information embedded in the event. 134 2.2.1. Event Attributes 136 2.2.1.1. uuid 138 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 139 the event. The uuid MUST be preserved for any updates or transfer of 140 the same event. UUID version 4 is RECOMMENDED when assigning it to a 141 new event. 143 uuid is represented as a JSON string. uuid MUST be present. 145 2.2.1.2. id 147 id represents the human-readable identifier associated to the event 148 for a specific MISP instance. 150 id is represented as a JSON string. id SHALL be present. 152 2.2.1.3. published 154 published represents the event publication state. If the event was 155 published, the published value MUST be true. In any other 156 publication state, the published value MUST be false. 158 published is represented as a JSON boolean. published MUST be 159 present. 161 2.2.1.4. info 163 info represents the information field of the event. info is a free- 164 text value to provide a human-readable summary of the event. info 165 SHOULD NOT be bigger than 256 characters and SHOULD NOT include new- 166 lines. 168 info is represented as a JSON string. info MUST be present. 170 2.2.1.5. threat_level_id 172 threat_level_id represents the threat level. 174 4: 175 Undefined 177 3: 178 Low 180 2: 181 Medium 183 1: 184 High 186 If a higher granularity is required, a MISP taxonomy applied as a Tag 187 SHOULD be preferred. 189 threat_level_id is represented as a JSON string. threat_level_id 190 SHALL be present. 192 2.2.1.6. analysis 194 analysis represents the analysis level. 196 0: 197 Initial 199 1: 200 Ongoing 202 2: 203 Complete 205 If a higher granularity is required, a MISP taxonomy applied as a Tag 206 SHOULD be preferred. 208 analysis is represented as a JSON string. analysis SHALL be present. 210 2.2.1.7. date 212 date represents a reference date to the event in ISO 8601 format 213 (date only: YYYY-MM-DD). This date corresponds to the date the event 214 occured, which may be in the past. 216 date is represented as a JSON string. date MUST be present. 218 2.2.1.8. timestamp 220 timestamp represents a reference time when the event, or one of the 221 attributes within the event was created, or last updated/edited on 222 the instance. timestamp is expressed in seconds (decimal) since 1st 223 of January 1970 (Unix timestamp). The time zone MUST be UTC. 225 timestamp is represented as a JSON string. timestamp MUST be present. 227 2.2.1.9. publish_timestamp 229 publish_timestamp represents a reference time when the event was 230 published on the instance. published_timestamp is expressed in 231 seconds (decimal) since 1st of January 1970 (Unix timestamp). At 232 each publication of an event, publish_timestamp MUST be updated. The 233 time zone MUST be UTC. 235 publish_timestamp is represented as a JSON string. publish_timestamp 236 MUST be present. 238 2.2.1.10. org_id 240 org_id represents a human-readable identifier referencing an Org 241 object of the organisation which generated the event. 243 The org_id MUST be updated when the event is generated by a new 244 instance. 246 org_id is represented as a JSON string. org_id MUST be present. 248 2.2.1.11. orgc_id 250 orgc_id represents a human-readable identifier referencing an Orgc 251 object of the organisation which created the event. 253 The orgc_id and Orc object MUST be preserved for any updates or 254 transfer of the same event. 256 orgc_id is represented as a JSON string. orgc_id MUST be present. 258 2.2.1.12. attribute_count 260 attribute_count represents the number of attributes in the event. 261 attribute_count is expressed in decimal. 263 attribute_count is represented as a JSON string. attribute_count 264 SHALL be present. 266 2.2.1.13. distribution 268 distribution represents the basic distribution rules of the event. 269 The system must adhere to the distribution setting for access control 270 and for dissemination of the event. 272 distribution is represented by a JSON string. distribution MUST be 273 present and be one of the following options: 275 0 276 Your Organisation Only 278 1 279 This Community Only 281 2 282 Connected Communities 284 3 285 All Communities 287 4 288 Sharing Group 290 2.2.1.14. sharing_group_id 292 sharing_group_id represents a human-readable identifier referencing a 293 Sharing Group object that defines the distribution of the event, if 294 distribution level "4" is set. 296 sharing_group_id is represented by a JSON string and SHOULD be 297 present. If a distribution level other than "4" is chosen the 298 sharing_group_id MUST be set to "0". 300 2.3. Objects 302 2.3.1. Org 304 An Org object is composed of an uuid, name and id. 306 The uuid represents the Universally Unique IDentifier (UUID) 307 [RFC4122] of the organisation. The organisation UUID is globally 308 assigned to an organisation and SHALL be kept overtime. 310 The name is a readable description of the organisation and SHOULD be 311 present. The id is a human-readable identifier generated by the 312 instance and used as reference in the event. 314 uuid, name and id are represented as a JSON string. uuid, name and id 315 MUST be present. 317 2.3.1.1. Sample Org Object 319 "Org": { 320 "id": "2", 321 "name": "CIRCL", 322 "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f" 323 } 325 2.3.2. Orgc 327 An Orgc object is composed of an uuid, name and id. 329 The uuid MUST be preserved for any updates or transfer of the same 330 event. UUID version 4 is RECOMMENDED when assigning it to a new 331 event. The organisation UUID is globally assigned to an organisation 332 and SHALL be kept overtime. 334 The name is a readable description of the organisation and SHOULD be 335 present. The id is a human-readable identifier generated by the 336 instance and used as reference in the event. 338 uuid, name and id are represented as a JSON string. uuid, name and id 339 MUST be present. 341 2.4. Attribute 343 Attributes are used to describe the indicators and contextual data of 344 an event. The main information contained in an attribute is made up 345 of a category-type-value triplet, where the category and type give 346 meaning and context to the value. Through the various category-type 347 combinations a wide range of information can be conveyed. 349 A MISP document MUST at least includes category-type-value triplet 350 described in section "Attribute Attributes". 352 2.4.1. Sample Attribute Object 354 "Attribute": { 355 "id": "346056", 356 "type": "comment", 357 "category": "Other", 358 "to_ids": false, 359 "uuid": "57f4f6d9-cd20-458b-84fd-109ec0a83869", 360 "event_id": "3357", 361 "distribution": "5", 362 "timestamp": "1475679332", 363 "comment": "", 364 "sharing_group_id": "0", 365 "deleted": false, 366 "value": "Hello world", 367 "SharingGroup": [], 368 "ShadowAttribute": [], 369 "RelatedAttribute": [] 370 } 372 2.4.2. Attribute Attributes 374 2.4.2.1. uuid 376 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 377 the event. The uuid MUST be preserved for any updates or transfer of 378 the same event. UUID version 4 is RECOMMENDED when assigning it to a 379 new event. 381 uuid is represented as a JSON string. uuid MUST be present. 383 2.4.2.2. id 385 id represents the human-readable identifier associated to the event 386 for a specific MISP instance. 388 id is represented as a JSON string. id SHALL be present. 390 2.4.2.3. type 392 type represents the means through which an attribute tries to 393 describe the intent of the attribute creator, using a list of pre- 394 defined attribute types. 396 type is represented as a JSON string. type MUST be present and it 397 MUST be a valid selection for the chosen category. The list of valid 398 category-type combinations is as follows: 400 Internal reference 401 text, link, comment, other, hex 403 Targeting data 404 target-user, target-email, target-machine, target-org, target- 405 location, target-external, comment 407 Antivirus detection 408 link, comment, text, hex, attachment, other 410 Payload delivery 411 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 412 ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, filename, 413 filename|md5, filename|sha1, filename|sha224, filename|sha256, 414 filename|sha384, filename|sha512, filename|sha512/224, 415 filename|sha512/256, filename|authentihash, filename|ssdeep, 416 filename|tlsh, filename|imphash, filename|impfuzzy, 417 filename|pehash, ip-src, ip-dst, hostname, domain, email-src, 418 email-dst, email-subject, email-attachment, url, user-agent, AS, 419 pattern-in-file, pattern-in-traffic, yara, attachment, malware- 420 sample, link, malware-type, mime-type, comment, text, 421 vulnerability, x509-fingerprint-sha1, other, ip-dst|port, ip- 422 src|port, hostname|port, email-dst-display-name, email-src- 423 display-name, email-header, email-reply-to, email-x-mailer, email- 424 mime-boundary, email-thread-index, email-message-id, mobile- 425 application-id 427 Artifacts dropped 428 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 429 ssdeep, imphash, impfuzzy, authentihash, filename, filename|md5, 430 filename|sha1, filename|sha224, filename|sha256, filename|sha384, 431 filename|sha512, filename|sha512/224, filename|sha512/256, 432 filename|authentihash, filename|ssdeep, filename|tlsh, 433 filename|imphash, filename|impfuzzy, filename|pehash, regkey, 434 regkey|value, pattern-in-file, pattern-in-memory, pdb, yara, 435 sigma, stix2-pattern, gene, attachment, malware-sample, mime-type, 436 named pipe, mutex, windows-scheduled-task, windows-service-name, 437 windows-service-displayname, comment, text, hex, x509-fingerprint- 438 sha1, other 440 Payload installation 441 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 442 ssdeep, imphash, authentihash, pehash, tlsh, filename, 443 filename|md5, filename|sha1, filename|sha224, filename|sha256, 444 filename|sha384, filename|sha512, filename|sha512/224, 445 filename|sha512/256, filename|authentihash, filename|ssdeep, 446 filename|tlsh, filename|imphash, filename|pehash, pattern-in-file, 447 mime-type, pattern-in-traffic, pattern-in-memory, yara, 448 stix2-pattern, vulnerability, attachment, malware-sample, malware- 449 type, comment, text, hex, x509-fingerprint-sha1, mobile- 450 application-id, other 452 Persistence mechanism 453 filename, regkey, regkey|value, comment, text, other, text 455 Network activity 456 ip-src, ip-dst, hostname, domain, domain|ip, email-dst, url, uri, 457 user-agent, http-method, AS, snort, pattern-in-file, pattern-in- 458 traffic, stix2-pattern, attachment, comment, text, x509- 459 fingerprint-sha1, other, hex, cookie 461 Payload type 462 comment, text, other 464 Attribution 465 threat-actor, campaign-name, campaign-id, whois-registrant-phone, 466 whois-registrant-email, whois-registrant-name, whois-registrar, 467 whois-creation-date, comment, text, x509-fingerprint-sha1, other 469 External analysis 470 md5, sha1, sha256, filename, filename|md5, filename|sha1, 471 filename|sha256, ip-src, ip-dst, hostname, domain, domain|ip, url, 472 user-agent, regkey, regkey|value, AS, snort, pattern-in-file, 473 pattern-in-traffic, pattern-in-memory, vulnerability, attachment, 474 malware-sample, link, comment, text, x509-fingerprint-sha1, 475 github-repository, other 477 Financial fraud 478 btc, iban, bic, bank-account-nr, aba-rtn, bin, cc-number, prtn, 479 phone-number, comment, text, other, hex 481 Support tool 482 attachment, link, comment, text, other, hex 484 Social network 485 github-username, github-repository, github-organisation, jabber- 486 id, twitter-id, email-src, email-dst, comment, text, other 488 Person 489 first-name, middle-name, last-name, date-of-birth, place-of-birth, 490 gender, passport-number, passport-country, passport-expiration, 491 redress-number, nationality, visa-number, issue-date-of-the-visa, 492 primary-residence, country-of-residence, special-service-request, 493 frequent-flyer-number, travel-details, payment-details, place- 494 port-of-original-embarkation, place-port-of-clearance, place-port- 495 of-onward-foreign-destination, passenger-name-record-locator- 496 number, comment, text, other, phone-number, identity-card-number 498 Other 499 comment, text, other, size-in-bytes, counter, datetime, cpe, port, 500 float, hex, phone-number 502 Attributes are based on the usage within their different communities. 503 Attributes can be extended on a regular basis and this reference 504 document is updated accordingly. 506 2.4.2.4. category 508 category represents the intent of what the attribute is describing as 509 selected by the attribute creator, using a list of pre-defined 510 attribute categories. 512 category is represented as a JSON string. category MUST be present 513 and it MUST be a valid selection for the chosen type. The list of 514 valid category-type combinations is mentioned above. 516 2.4.2.5. to_ids 518 to_ids represents whether the attribute is meant to be actionable. 519 Actionable defined attributes that can be used in automated processes 520 as a pattern for detection in Local or Network Intrusion Detection 521 System, log analysis tools or even filtering mechanisms. 523 to_ids is represented as a JSON boolean. to_ids MUST be present. 525 2.4.2.6. event_id 527 event_id represents a human-readable identifier referencing the Event 528 object that the attribute belongs to. 530 The event_id SHOULD be updated when the event is imported to reflect 531 the newly created event's id on the instance. 533 event_id is represented as a JSON string. event_id MUST be present. 535 2.4.2.7. distribution 537 distribution represents the basic distribution rules of the 538 attribute. The system must adhere to the distribution setting for 539 access control and for dissemination of the attribute. 541 distribution is represented by a JSON string. distribution MUST be 542 present and be one of the following options: 544 0 545 Your Organisation Only 547 1 548 This Community Only 550 2 551 Connected Communities 553 3 554 All Communities 556 4 557 Sharing Group 559 5 560 Inherit Event 562 2.4.2.8. timestamp 564 timestamp represents a reference time when the attribute was created 565 or last modified. timestamp is expressed in seconds (decimal) since 566 1st of January 1970 (Unix timestamp). The time zone MUST be UTC. 568 timestamp is represented as a JSON string. timestamp MUST be present. 570 2.4.2.9. comment 572 comment is a contextual comment field. 574 comment is represented by a JSON string. comment MAY be present. 576 2.4.2.10. sharing_group_id 578 sharing_group_id represents a human-readable identifier referencing a 579 Sharing Group object that defines the distribution of the attribute, 580 if distribution level "4" is set. 582 sharing_group_id is represented by a JSON string and SHOULD be 583 present. If a distribution level other than "4" is chosen the 584 sharing_group_id MUST be set to "0". 586 2.4.2.11. deleted 588 deleted represents a setting that allows attributes to be revoked. 589 Revoked attributes are not actionable and exist merely to inform 590 other instances of a revocation. 592 deleted is represented by a JSON boolean. deleted MUST be present. 594 2.4.2.12. data 596 data contains the base64 encoded contents of an attachment or a 597 malware sample. For malware samples, the sample MUST be encrypted 598 using a password protected zip archive, with the password being 599 "infected". 601 data is represented by a JSON string in base64 encoding. data MUST be 602 set for attributes of type malware-sample and attachment. 604 2.4.2.13. RelatedAttribute 606 RelatedAttribute is an array of attributes correlating with the 607 current attribute. Each element in the array represents an JSON 608 object which contains an Attribute dictionnary with the external 609 attributes who correlate. Each Attribute MUST include the id, 610 org_id, info and a value. Only the correlations found on the local 611 instance are shown in RelatedAttribute. 613 RelatedAttribute MAY be present. 615 2.4.2.14. ShadowAttribute 617 ShadowAttribute is an array of shadow attributes that serve as 618 proposals by third parties to alter the containing attribute. The 619 structure of a ShadowAttribute is similar to that of an Attribute, 620 which can be accepted or discarded by the event creator. If 621 accepted, the original attribute containing the shadow attribute is 622 removed and the shadow attribute is converted into an attribute. 624 Each shadow attribute that references an attribute MUST contain the 625 containing attribute's ID in the old_id field and the event's ID in 626 the event_id field. 628 2.4.2.15. value 630 value represents the payload of an attribute. The format of the 631 value is dependent on the type of the attribute. 633 value is represented by a JSON string. value MUST be present. 635 2.5. ShadowAttribute 637 ShadowAttributes are 3rd party created attributes that either propose 638 to add new information to an event or modify existing information. 639 They are not meant to be actionable until the event creator accepts 640 them - at which point they will be converted into attributes or 641 modify an existing attribute. 643 They are similar in structure to Attributes but additionally carry a 644 reference to the creator of the ShadowAttribute as well as a 645 revocation flag. 647 2.5.1. Sample Attribute Object 648 "ShadowAttribute": { 649 "id": "8", 650 "type": "ip-src", 651 "category": "Network activity", 652 "to_ids": false, 653 "uuid": "57d475f1-da78-4569-89de-1458c0a83869", 654 "event_uuid": "57d475e6-41c4-41ca-b450-145ec0a83869", 655 "event_id": "9", 656 "old_id": "319", 657 "comment": "", 658 "org_id": "1", 659 "proposal_to_delete": false, 660 "value": "5.5.5.5", 661 "deleted": false, 662 "Org": { 663 "id": "1", 664 "name": "MISP", 665 "uuid": "568cce5a-0c80-412b-8fdf-1ffac0a83869" 666 } 667 } 669 2.5.2. ShadowAttribute Attributes 671 2.5.2.1. uuid 673 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 674 the event. The uuid MUST be preserved for any updates or transfer of 675 the same event. UUID version 4 is RECOMMENDED when assigning it to a 676 new event. 678 uuid is represented as a JSON string. uuid MUST be present. 680 2.5.2.2. id 682 id represents the human-readable identifier associated to the event 683 for a specific MISP instance. 685 id is represented as a JSON string. id SHALL be present. 687 2.5.2.3. type 689 type represents the means through which an attribute tries to 690 describe the intent of the attribute creator, using a list of pre- 691 defined attribute types. 693 type is represented as a JSON string. type MUST be present and it 694 MUST be a valid selection for the chosen category. The list of valid 695 category-type combinations is as follows: 697 Internal reference 698 text, link, comment, other, hex 700 Targeting data 701 target-user, target-email, target-machine, target-org, target- 702 location, target-external, comment 704 Antivirus detection 705 link, comment, text, hex, attachment, other 707 Payload delivery 708 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 709 ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, filename, 710 filename|md5, filename|sha1, filename|sha224, filename|sha256, 711 filename|sha384, filename|sha512, filename|sha512/224, 712 filename|sha512/256, filename|authentihash, filename|ssdeep, 713 filename|tlsh, filename|imphash, filename|impfuzzy, 714 filename|pehash, ip-src, ip-dst, hostname, domain, email-src, 715 email-dst, email-subject, email-attachment, url, user-agent, AS, 716 pattern-in-file, pattern-in-traffic, yara, attachment, malware- 717 sample, link, malware-type, mime-type, comment, text, 718 vulnerability, x509-fingerprint-sha1, other, ip-dst|port, ip- 719 src|port, hostname|port, email-dst-display-name, email-src- 720 display-name, email-header, email-reply-to, email-x-mailer, email- 721 mime-boundary, email-thread-index, email-message-id, mobile- 722 application-id 724 Artifacts dropped 725 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 726 ssdeep, imphash, impfuzzy, authentihash, filename, filename|md5, 727 filename|sha1, filename|sha224, filename|sha256, filename|sha384, 728 filename|sha512, filename|sha512/224, filename|sha512/256, 729 filename|authentihash, filename|ssdeep, filename|tlsh, 730 filename|imphash, filename|impfuzzy, filename|pehash, regkey, 731 regkey|value, pattern-in-file, pattern-in-memory, pdb, yara, 732 sigma, gene, stix2-pattern, attachment, malware-sample, mime-type, 733 named pipe, mutex, windows-scheduled-task, windows-service-name, 734 windows-service-displayname, comment, text, hex, x509-fingerprint- 735 sha1, other 737 Payload installation 738 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 739 ssdeep, imphash, authentihash, pehash, tlsh, filename, 740 filename|md5, filename|sha1, filename|sha224, filename|sha256, 741 filename|sha384, filename|sha512, filename|sha512/224, 742 filename|sha512/256, filename|authentihash, filename|ssdeep, 743 filename|tlsh, filename|imphash, filename|pehash, mime-type, 744 pattern-in-file, pattern-in-traffic, pattern-in-memory, yara, 745 stix2-pattern, vulnerability, attachment, malware-sample, malware- 746 type, comment, text, hex, x509-fingerprint-sha1, mobile- 747 application-id, other 749 Persistence mechanism 750 filename, regkey, regkey|value, comment, text, other, text 752 Network activity 753 ip-src, ip-dst, hostname, domain, domain|ip, email-dst, url, uri, 754 user-agent, http-method, AS, snort, pattern-in-file, pattern-in- 755 traffic, stix2-pattern, attachment, comment, text, x509- 756 fingerprint-sha1, other, hex, cookie 758 Payload type 759 comment, text, other 761 Attribution 762 threat-actor, campaign-name, campaign-id, whois-registrant-phone, 763 whois-registrant-email, whois-registrant-name, whois-registrant- 764 org, whois-registrar, whois-creation-date, comment, text, x509- 765 fingerprint-sha1, other 767 External analysis 768 md5, sha1, sha256, filename, filename|md5, filename|sha1, 769 filename|sha256, ip-src, ip-dst, hostname, domain, domain|ip, url, 770 user-agent, regkey, regkey|value, AS, snort, pattern-in-file, 771 pattern-in-traffic, pattern-in-memory, vulnerability, attachment, 772 malware-sample, link, comment, text, x509-fingerprint-sha1, 773 github-repository, other 775 Financial fraud 776 btc, iban, bic, bank-account-nr, aba-rtn, bin, cc-number, prtn, 777 phone-number, comment, text, other, hex 779 Support tool 780 attachment, link, comment, text, other, hex 782 Social network 783 github-username, github-repository, github-organisation, jabber- 784 id, twitter-id, email-src, email-dst, comment, text, other 786 Person 787 first-name, middle-name, last-name, date-of-birth, place-of-birth, 788 gender, passport-number, passport-country, passport-expiration, 789 redress-number, nationality, visa-number, issue-date-of-the-visa, 790 primary-residence, country-of-residence, special-service-request, 791 frequent-flyer-number, travel-details, payment-details, place- 792 port-of-original-embarkation, place-port-of-clearance, place-port- 793 of-onward-foreign-destination, passenger-name-record-locator- 794 number, comment, text, other, phone-number, identity-card-number 796 Other 797 comment, text, other, size-in-bytes, counter, datetime, cpe, port, 798 float, hex, phone-number 800 Attributes are based on the usage within their different communities. 801 Attributes can be extended on a regular basis and this reference 802 document is updated accordingly. 804 2.5.2.4. category 806 category represents the intent of what the attribute is describing as 807 selected by the attribute creator, using a list of pre-defined 808 attribute categories. 810 category is represented as a JSON string. category MUST be present 811 and it MUST be a valid selection for the chosen type. The list of 812 valid category-type combinations is mentioned above. 814 2.5.2.5. to_ids 816 to_ids represents whether the Attribute to be created if the 817 ShadowAttribute is accepted is meant to be actionable. Actionable 818 defined attributes that can be used in automated processes as a 819 pattern for detection in Local or Network Intrusion Detection System, 820 log analysis tools or even filtering mechanisms. 822 to_ids is represented as a JSON boolean. to_ids MUST be present. 824 2.5.2.6. event_id 826 event_id represents a human-readable identifier referencing the Event 827 object that the ShadowAttribute belongs to. 829 The event_id SHOULD be updated when the event is imported to reflect 830 the newly created event's id on the instance. 832 event_id is represented as a JSON string. event_id MUST be present. 834 2.5.2.7. old_id 836 old_id represents a human-readable identifier referencing the 837 Attribute object that the ShadowAttribute belongs to. A 838 ShadowAttribute can this way target an existing Attribute, implying 839 that it is a proposal to modify an existing Attribute, or 840 alternatively it can be a proposal to create a new Attribute for the 841 containing Event. 843 The old_id SHOULD be updated when the event is imported to reflect 844 the newly created Attribute's id on the instance. Alternatively, if 845 the ShadowAttribute proposes the creation of a new Attribute, it 846 should be set to 0. 848 old_id is represented as a JSON string. old_id MUST be present. 850 2.5.2.8. timestamp 852 timestamp represents a reference time when the attribute was created 853 or last modified. timestamp is expressed in seconds (decimal) since 854 1st of January 1970 (Unix timestamp). The time zone MUST be UTC. 856 timestamp is represented as a JSON string. timestamp MUST be present. 858 2.5.2.9. comment 860 comment is a contextual comment field. 862 comment is represented by a JSON string. comment MAY be present. 864 2.5.2.10. org_id 866 org_id represents a human-readable identifier referencing the 867 proposal creator's Organisation object. 869 Whilst attributes can only be created by the event creator 870 organisation, shadow attributes can be created by third parties. 871 org_id tracks the creator organisation. 873 org_id is represented by a JSON string and MUST be present. 875 2.5.2.11. proposal_to_delete 877 proposal_to_delete is a boolean flag that sets whether the shadow 878 attribute proposes to alter an attribute, or whether it proposes to 879 remove it completely. 881 Accepting a shadow attribute with this flag set will remove the 882 target attribute. 884 proposal_to_delete is a JSON boolean and it MUST be present. If 885 proposal_to_delete is set to true, old_id MUST NOT be 0. 887 2.5.2.12. deleted 889 deleted represents a setting that allows shadow attributes to be 890 revoked. Revoked shadow attributes only serve to inform other 891 instances that the shadow attribute is no longer active. 893 deleted is represented by a JSON boolean. deleted SHOULD be present. 895 2.5.2.13. data 897 data contains the base64 encoded contents of an attachment or a 898 malware sample. For malware samples, the sample MUST be encrypted 899 using a password protected zip archive, with the password being 900 "infected". 902 data is represented by a JSON string in base64 encoding. data MUST be 903 set for shadow attributes of type malware-sample and attachment. 905 2.5.3. Org 907 An Org object is composed of an uuid, name and id. 909 The uuid represents the Universally Unique IDentifier (UUID) 910 [RFC4122] of the organization. The organization UUID is globally 911 assigned to an organization and SHALL be kept overtime. 913 The name is a readable description of the organization and SHOULD be 914 present. The id is a human-readable identifier generated by the 915 instance and used as reference in the event. 917 uuid, name and id are represented as a JSON string. uuid, name and id 918 MUST be present. 920 2.5.3.1. Sample Org Object 922 "Org": { 923 "id": "2", 924 "name": "CIRCL", 925 "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f" 926 } 928 2.5.3.2. value 930 value represents the payload of an attribute. The format of the 931 value is dependent on the type of the attribute. 933 value is represented by a JSON string. value MUST be present. 935 2.6. Object 937 Objects serve as a contextual bond between a list of attributes 938 within an event. Their main purpose is to describe more complex 939 structures than can be described by a single attribute Each object is 940 created using an Object Template and carries the meta-data of the 941 template used for its creation within. Objects belong to a meta- 942 category and are defined by a name. 944 The schema used is described by the template_uuid and 945 template_version fields. 947 A MISP document containing an Object MUST contain a name, a meta- 948 category, a description, a template_uuid and a template_version as 949 described in the "Object Attributes" section. 951 2.6.1. Sample Object object 952 "Object": { 953 "id": "588", 954 "name": "file", 955 "meta-category": "file", 956 "description": "File object describing a file with meta-information", 957 "template_uuid": "688c46fb-5edb-40a3-8273-1af7923e2215", 958 "template_version": "3", 959 "event_id": "56", 960 "uuid": "398b0094-0384-4c48-9bf0-22b3dff9c4d3", 961 "timestamp": "1505747965", 962 "distribution": "5", 963 "sharing_group_id": "0", 964 "comment": "", 965 "deleted": false, 966 "ObjectReference": [], 967 "Attribute": [ 968 "id": "7822", 969 "type": "filename", 970 "category": "Payload delivery", 971 "to_ids": true, 972 "uuid": "59bfe3fb-bde0-4dfe-b5b1-2b10a07724d1", 973 "event_id": "56", 974 "distribution": "0", 975 "timestamp": "1505747963", 976 "comment": "", 977 "sharing_group_id": "0", 978 "deleted": false, 979 "disable_correlation": false, 980 "object_id": "588", 981 "object_relation": "filename", 982 "value": "StarCraft.exe", 983 "ShadowAttribute": [] 984 ] 985 } 987 2.6.2. Object Attributes 989 2.6.2.1. uuid 991 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 992 the object. The uuid MUST be preserved for any updates or transfer 993 of the same object. UUID version 4 is RECOMMENDED when assigning it 994 to a new object. 996 2.6.2.2. id 998 id represents the human-readable identifier associated to the object 999 for a specific MISP instance. 1001 id is represented as a JSON string. id SHALL be present. 1003 2.6.2.3. name 1005 name represents the human-readable name of the object describing the 1006 intent of the object package. 1008 name is represented as a JSON string. name MUST be present 1010 2.6.2.4. meta-category 1012 meta-category represents the sub-category of objects that the given 1013 object belongs to. meta-categories are not tied to a fixed list of 1014 options but can be created on the fly. 1016 meta-category is represented as a JSON string. meta-category MUST be 1017 present 1019 2.6.2.5. description 1021 description is a human-readable description of the given object type, 1022 as derived from the template used for creation. 1024 description is represented as a JSON string. id SHALL be present. 1026 2.6.2.6. template_uuid 1028 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 1029 the template used to create the object. The uuid MUST be preserved 1030 to preserve the object's association with the correct template used 1031 for creation. UUID version 4 is RECOMMENDED when assigning it to a 1032 new object. 1034 2.6.2.7. template_version 1036 template_version represents a numeric incrementing version of the 1037 template used to create the object. It is used to associate the 1038 object to the correct version of the template and together with the 1039 template_uuid forms an association to the correct template type and 1040 version. 1042 version is represented as a JSON string. version MUST be present. 1044 2.6.2.8. event_id 1046 event_id represents the human-readable identifier of the event that 1047 the object belongs to on a specific MISP instance. 1049 event_id is represented as a JSON string. event_id SHALL be present. 1051 2.6.2.9. timestamp 1053 timestamp represents a reference time when the object was created or 1054 last modified. timestamp is expressed in seconds (decimal) since 1st 1055 of January 1970 (Unix timestamp). The time zone MUST be UTC. 1057 timestamp is represented as a JSON string. timestamp MUST be present. 1059 2.6.2.10. distribution 1061 distribution represents the basic distribution rules of the object. 1062 The system must adhere to the distribution setting for access control 1063 and for dissemination of the object. 1065 distribution is represented by a JSON string. distribution MUST be 1066 present and be one of the following options: 1068 0 1069 Your Organisation Only 1071 1 1072 This Community Only 1074 2 1075 Connected Communities 1077 3 1078 All Communities 1080 4 1081 Sharing Group 1083 2.6.2.11. sharing_group_id 1085 sharing_group_id represents a human-readable identifier referencing a 1086 Sharing Group object that defines the distribution of the object, if 1087 distribution level "4" is set. 1089 sharing_group_id is represented by a JSON string and SHOULD be 1090 present. If a distribution level other than "4" is chosen the 1091 sharing_group_id MUST be set to "0". 1093 2.6.2.12. comment 1095 comment is a contextual comment field. 1097 comment is represented by a JSON string. comment MAY be present. 1099 2.6.2.13. deleted 1101 deleted represents a setting that allows attributes to be revoked. 1102 Revoked attributes are not actionable and exist merely to inform 1103 other instances of a revocation. 1105 deleted is represented by a JSON boolean. deleted MUST be present. 1107 2.6.2.14. Attribute 1109 Attribute is an array of attributes that describe the object with 1110 data. 1112 Each attribute in an object MUST contain the parent event's ID in the 1113 event_id field and the parent object's ID in the object_id field. 1115 2.7. Object References 1117 Object References serve as a logical link between an Object and 1118 another referenced Object or Attribute. The relationship is 1119 categorised by an enumerated value from a fixed vocabulary. 1121 The relationship_type is recommended to be taken from the MISP object 1122 relationship list [[MISP-R]] is RECOMMENDED to ensure a coherent 1123 naming of the tags 1125 All Object References MUST contain an object_uuid, a referenced_uuid 1126 and a relationship type. 1128 2.7.1. Sample ObjectReference object 1129 "ObjectReference": { 1130 "id": "195", 1131 "uuid": "59c21a2c-c0ac-4083-93b3-363da07724d1", 1132 "timestamp": "1505892908", 1133 "object_id": "591", 1134 "event_id": "113", 1135 "referenced_id": "590", 1136 "referenced_type": "1", 1137 "relationship_type": "derived-from", 1138 "comment": "", 1139 "deleted": false, 1140 "object_uuid": "59c1134d-8a40-4c14-ad94-0f7ba07724d1", 1141 "referenced_uuid": "59c1133c-9adc-4d06-a34b-0f7ca07724d1", 1142 } 1144 2.7.2. ObjectReference Attributes 1146 2.7.2.1. uuid 1148 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 1149 the object reference. The uuid MUST be preserved for any updates or 1150 transfer of the same object reference. UUID version 4 is RECOMMENDED 1151 when assigning it to a new object reference. 1153 2.7.2.2. id 1155 id represents the human-readable identifier associated to the object 1156 reference for a specific MISP instance. 1158 id is represented as a JSON string. id SHALL be present. 1160 2.7.2.3. timestamp 1162 timestamp represents a reference time when the object was created or 1163 last modified. timestamp is expressed in seconds (decimal) since 1st 1164 of January 1970 (Unix timestamp). The time zone MUST be UTC. 1166 timestamp is represented as a JSON string. timestamp MUST be present. 1168 2.7.2.4. object_id 1170 object_id represents the human-readable identifier of the object that 1171 the object reference belongs to on a specific MISP instance. 1173 event_id is represented as a JSON string. event_id SHALL be present. 1175 2.7.2.5. event_id 1177 event_id represents the human-readable identifier of the event that 1178 the object reference belongs to on a specific MISP instance. 1180 event_id is represented as a JSON string. event_id SHALL be present. 1182 2.7.2.6. referenced_id 1184 referenced_id represents the human-readable identifier of the object 1185 or attribute that the parent object of the object reference points to 1186 on a specific MISP instance. 1188 referenced_id is represented as a JSON string. referenced_id MAY be 1189 present. 1191 2.7.2.7. referenced_type 1193 referenced_type represents the numeric value describing what the 1194 object reference points to, "0" representing an attribute and "1" 1195 representing an object 1197 referenced_type is represented as a JSON string. referenced_type MAY 1198 be present. 1200 2.7.2.8. relationship_type 1202 relationship_type represents the human-readable context of the 1203 relationship between an object and another object or attribute as 1204 described by the object_reference. 1206 referenced_type is represented as a JSON string. relationship_type 1207 MUST be present. 1209 2.7.2.9. comment 1211 comment is a contextual comment field. 1213 comment is represented by a JSON string. comment MAY be present. 1215 2.7.2.10. deleted 1217 deleted represents a setting that allows object references to be 1218 revoked. Revoked object references are not actionable and exist 1219 merely to inform other instances of a revocation. 1221 deleted is represented by a JSON boolean. deleted MUST be present. 1223 2.7.2.11. object_uuid 1225 object_uuid represents the Universally Unique IDentifier (UUID) 1226 [RFC4122] of the object that the given object reference belongs to. 1227 The object_uuid MUST be preserved to preserve the object reference's 1228 association with the object. 1230 2.7.2.12. referenced_uuid 1232 referenced_uuid represents the Universally Unique IDentifier (UUID) 1233 [RFC4122] of the object or attribute that is being referenced by the 1234 object reference. The referenced_uuid MUST be preserved to preserve 1235 the object reference's association with the object or attribute. 1237 2.8. Tag 1239 A tag is a simple method to classify an event with a simple string. 1240 The tag name can be freely chosen. The tag name can be also chosen 1241 from a fixed machine-tag vocabulary called MISP taxonomies[[MISP-T]]. 1242 When an event is distributed outside an organisation, the use of MISP 1243 taxonomies[[MISP-T]] is RECOMMENDED to ensure a coherent naming of 1244 the tags. A tag is represented as a JSON array where each element 1245 describes each tag associated. A tag array SHALL be at event level 1246 or attribute level. A tag element is described with a name, id, 1247 colour and exportable flag. 1249 exportable represents a setting if the tag is kept local or 1250 exportable to other MISP instances. exportable is represented by a 1251 JSON boolean. id is a human-readable identifier that references the 1252 tag on the local instance. colour represents an RGB value of the tag. 1254 name MUST be present. colour, id and exportable SHALL be present. 1256 2.8.1. Sample Tag 1258 "Tag": [{ 1259 "exportable": true, 1260 "colour": "#ffffff", 1261 "name": "tlp:white", 1262 "id": "2" }] 1264 2.9. Sighting 1266 A sighting is an ascertainment which describes whether an attribute 1267 has been seen under a given set of conditions. The sighting can 1268 include the organisation who sighted the attribute or can be 1269 anonymised. Sighting is composed of a JSON array in which each 1270 element describes one singular instance of a sighting. A sighting 1271 element is a JSON object composed of the following values: 1273 type MUST be present. type describes the type of a sighting. MISP 1274 allows 3 default types: 1276 +------------+------------------------------------------------------+ 1277 | Sighting | Description | 1278 | type | | 1279 +------------+------------------------------------------------------+ 1280 | 0 | denotes an attribute which has been seen | 1281 | 1 | denotes an attribute which has been seen and | 1282 | | confirmed as false-positive | 1283 | 2 | denotes an attribute which will be expired at the | 1284 | | time of the sighting | 1285 +------------+------------------------------------------------------+ 1287 uuid MUST be present. uuid references the uuid of the sighted 1288 attribute. 1290 date_sighting MUST be present. date_sighting is expressed in seconds 1291 (decimal) elapsed since 1st of January 1970 (Unix timestamp). 1292 date_sighting represents when the referenced attribute, designated by 1293 its uuid, is sighted. 1295 source MAY be present. source is represented as a JSON string and 1296 represents the human-readable version of the sighting source, which 1297 can be a given piece of software (e.g. SIEM), device or a specific 1298 analytical process. 1300 id, event_id and attribute_id MAY be present. 1302 id represents the human-readable identifier of the sighting reference 1303 which belongs to a specific MISP instance. event_id represents the 1304 human-readable identifier of the event referenced by the sighting and 1305 belongs to a specific MISP instance. attribute_id represents the 1306 human-readable identifier of the attribute referenced by the sighting 1307 and belongs to a specific MISP instance. 1309 org_id MAY be present along the JSON object describing the 1310 organisation. If the org_id is not present, the sighting is 1311 considered as anonymised. 1313 org_id represents the human-readable identifier of the organisation 1314 which did the sighting and belongs to a specific MISP instance. 1316 2.9.1. Sample Sighting 1318 "Sighting": [ 1319 { 1320 "id": "13599", 1321 "attribute_id": "1201615", 1322 "event_id": "10164", 1323 "org_id": "2", 1324 "date_sighting": "1517581400", 1325 "uuid": "5a747459-41b4-4826-9b29-42dd950d210f", 1326 "source": "M2M-CIRCL", 1327 "type": "0", 1328 "Organisation": { 1329 "id": "2", 1330 "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f", 1331 "name": "CIRCL" 1332 } 1333 }, 1334 { 1335 "id": "13601", 1336 "attribute_id": "1201615", 1337 "event_id": "10164", 1338 "org_id": "2", 1339 "date_sighting": "1517581401", 1340 "uuid": "5a74745a-a190-4d04-b719-4916950d210f", 1341 "source": "M2M-CIRCL", 1342 "type": "0", 1343 "Organisation": { 1344 "id": "2", 1345 "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f", 1346 "name": "CIRCL" 1347 } 1348 } 1349 ] 1351 2.10. Galaxy 1353 A galaxy is a simple method to express a large object called cluster 1354 that can be attached to MISP events. A cluster can be composed of 1355 one or more elements. Elements are expressed as key-values. 1357 2.10.1. Sample Galaxy 1358 "Galaxy": [ { 1359 "id": "18", 1360 "uuid": "698774c7-8022-42c4-917f-8d6e4f06ada3", 1361 "name": "Threat Actor", 1362 "type": "threat-actor", 1363 "description": "Threat actors are characteristics of malicious actors 1364 (or adversaries) representing a cyber attack threat 1365 including presumed intent and historically observed behaviour.", 1366 "version": "1", 1367 "GalaxyCluster": [ 1368 { 1369 "id": "1699", 1370 "uuid": "7cdff317-a673-4474-84ec-4f1754947823", 1371 "type": "threat-actor", 1372 "value": "Anunak", 1373 "tag_name": "misp-galaxy:threat-actor=\"Anunak\"", 1374 "description": "Groups targeting financial organizations 1375 or people with significant financial assets.", 1376 "galaxy_id": "18", 1377 "source": "MISP Project", 1378 "authors": [ 1379 "Alexandre Dulaunoy", 1380 "Florian Roth", 1381 "Thomas Schreck", 1382 "Timo Steffens", 1383 "Various" 1384 ], 1385 "tag_id": "111", 1386 "meta": { 1387 "synonyms": [ 1388 "Carbanak", 1389 "Carbon Spider" 1390 ], 1391 "country": [ 1392 "RU" 1393 ], 1394 "motive": [ 1395 "Cybercrime" 1396 ] 1397 } 1398 } 1399 ] 1400 } 1401 ] 1403 3. JSON Schema 1405 The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP 1406 core format as literally described before. The JSON Schema is used 1407 to validate MISP events at creation time or parsing. 1409 { 1410 "$schema": "http://json-schema.org/draft-04/schema#", 1411 "title": "Validator for misp events", 1412 "id": "https://github.com/MISP/MISP/blob/2.4/format/2.4/schema.json", 1413 "defs": { 1414 "org": { 1415 "type": "object", 1416 "additionalProperties": false, 1417 "properties": { 1418 "id": { 1419 "type": "string" 1420 }, 1421 "name": { 1422 "type": "string" 1423 }, 1424 "uuid": { 1425 "type": "string" 1426 } 1427 }, 1428 "required": [ 1429 "uuid" 1430 ] 1431 }, 1432 "orgc": { 1433 "type": "object", 1434 "additionalProperties": false, 1435 "properties": { 1436 "id": { 1437 "type": "string" 1438 }, 1439 "name": { 1440 "type": "string" 1441 }, 1442 "uuid": { 1443 "type": "string" 1444 } 1445 }, 1446 "required": [ 1447 "uuid" 1448 ] 1449 }, 1450 "sharing_group": { 1451 "type": "object", 1452 "additionalProperties": false, 1453 "properties": { 1454 "id": { 1455 "type": "string" 1456 }, 1457 "name": { 1458 "type": "string" 1459 }, 1460 "releasability": { 1461 "type": "string" 1462 }, 1463 "description": { 1464 "type": "string" 1465 }, 1466 "uuid": { 1467 "type": "string" 1468 }, 1469 "organisation_uuid": { 1470 "type": "string" 1471 }, 1472 "org_id": { 1473 "type": "string" 1474 }, 1475 "sync_user_id": { 1476 "type": "string" 1477 }, 1478 "active": { 1479 "type": "boolean" 1480 }, 1481 "created": { 1482 "type": "string" 1483 }, 1484 "modified": { 1485 "type": "string" 1486 }, 1487 "local": { 1488 "type": "boolean" 1489 }, 1490 "roaming": { 1491 "type": "boolean" 1492 }, 1493 "Organisation": { 1494 "$ref": "#/defs/org" 1495 }, 1496 "SharingGroupOrg": { 1497 "type": "array", 1498 "uniqueItems": true, 1499 "items": { 1500 "$ref": "#/defs/sharing_group_org" 1501 } 1502 }, 1503 "SharingGroupServer": { 1504 "type": "array", 1505 "uniqueItems": true, 1506 "items": { 1507 "$ref": "#/defs/sharing_group_server" 1508 } 1509 }, 1510 "required": [ 1511 "uuid" 1512 ] 1513 }, 1514 "required": [ 1515 "uuid" 1516 ] 1517 }, 1518 "sharing_group_org": { 1519 "type": "object", 1520 "additionalProperties": false, 1521 "properties": { 1522 "id": { 1523 "type": "string" 1524 }, 1525 "sharing_group_id": { 1526 "type": "string" 1527 }, 1528 "org_id": { 1529 "type": "string" 1530 }, 1531 "extend": { 1532 "type": "boolean" 1533 }, 1534 "Organisation": { 1535 "$ref": "#/defs/org" 1536 } 1537 } 1538 }, 1539 "sharing_group_server": { 1540 "type": "object", 1541 "additionalProperties": false, 1542 "properties": { 1543 "id": { 1544 "type": "string" 1545 }, 1546 "sharing_group_id": { 1547 "type": "string" 1548 }, 1549 "server_id": { 1550 "type": "string" 1551 }, 1552 "all_orgs": { 1553 "type": "boolean" 1554 }, 1555 "Server": { 1556 "$ref": "#/defs/server" 1557 } 1558 } 1559 }, 1560 "server": { 1561 "type": "object", 1562 "additionalProperties": false, 1563 "properties": { 1564 "id": { 1565 "type": "string" 1566 }, 1567 "url": { 1568 "type": "string" 1569 }, 1570 "name": { 1571 "type": "string" 1572 } 1573 } 1574 }, 1575 "attribute": { 1576 "type": "object", 1577 "additionalProperties": false, 1578 "properties": { 1579 "id": { 1580 "type": "string" 1581 }, 1582 "type": { 1583 "type": "string" 1584 }, 1585 "category": { 1586 "type": "string" 1587 }, 1588 "to_ids": { 1589 "type": "boolean" 1590 }, 1591 "uuid": { 1592 "type": "string" 1593 }, 1594 "event_id": { 1595 "type": "string" 1596 }, 1597 "distribution": { 1598 "type": "string" 1599 }, 1600 "timestamp": { 1601 "type": "string" 1602 }, 1603 "comment": { 1604 "type": "string" 1605 }, 1606 "sharing_group_id": { 1607 "type": "string" 1608 }, 1609 "deleted": { 1610 "type": "boolean" 1611 }, 1612 "disable_correlation": { 1613 "type": "boolean" 1614 }, 1615 "value": { 1616 "type": "string" 1617 }, 1618 "data": { 1619 "type": "string" 1620 }, 1621 "SharingGroup": { 1622 "$ref": "#/defs/sharing_group" 1623 }, 1624 "ShadowAttribute": { 1625 "type": "array", 1626 "uniqueItems": true, 1627 "items": { 1628 "$ref": "#/defs/attribute" 1629 } 1630 }, 1631 "Tag": { 1632 "type": "array", 1633 "uniqueItems": true, 1634 "items": { 1635 "$ref": "#/defs/tag" 1636 } 1637 } 1638 } 1639 }, 1640 "event": { 1641 "type": "object", 1642 "additionalProperties": false, 1643 "properties": { 1644 "id": { 1645 "type": "string" 1646 }, 1647 "orgc_id": { 1648 "type": "string" 1649 }, 1650 "org_id": { 1651 "type": "string" 1652 }, 1653 "date": { 1654 "type": "string" 1655 }, 1656 "threat_level_id": { 1657 "type": "string" 1658 }, 1659 "info": { 1660 "type": "string" 1661 }, 1662 "published": { 1663 "type": "boolean" 1664 }, 1665 "uuid": { 1666 "type": "string" 1667 }, 1668 "attribute_count": { 1669 "type": "string" 1670 }, 1671 "analysis": { 1672 "type": "string" 1673 }, 1674 "timestamp": { 1675 "type": "string" 1676 }, 1677 "distribution": { 1678 "type": "string" 1679 }, 1680 "proposal_email_lock": { 1681 "type": "boolean" 1682 }, 1683 "locked": { 1684 "type": "boolean" 1685 }, 1686 "publish_timestamp": { 1687 "type": "string" 1688 }, 1689 "sharing_group_id": { 1690 "type": "string" 1692 }, 1693 "disable_correlation": { 1694 "type": "boolean" 1695 }, 1696 "event_creator_email": { 1697 "type": "string" 1698 }, 1699 "Org": { 1700 "$ref": "#/defs/org" 1701 }, 1702 "Orgc": { 1703 "$ref": "#/defs/org" 1704 }, 1705 "SharingGroup": { 1706 "$ref": "#/defs/sharing_group" 1707 }, 1708 "Attribute": { 1709 "type": "array", 1710 "uniqueItems": true, 1711 "items": { 1712 "$ref": "#/defs/attribute" 1713 } 1714 }, 1715 "ShadowAttribute": { 1716 "type": "array", 1717 "uniqueItems": true, 1718 "items": { 1719 "$ref": "#/defs/attribute" 1720 } 1721 }, 1722 "RelatedEvent": { 1723 "type": "array", 1724 "uniqueItems": true, 1725 "items": { 1726 "type": "object", 1727 "additionalProperties": false, 1728 "properties": { 1729 "Event":{ 1730 "$ref": "#/defs/event" 1731 } 1732 } 1733 } 1734 }, 1735 "Galaxy": { 1736 "type": "array", 1737 "uniqueItems": true, 1738 "items": { 1739 "$ref": "#/defs/galaxy" 1741 } 1742 }, 1743 "Tag": { 1744 "type": "array", 1745 "uniqueItems": true, 1746 "items": { 1747 "$ref": "#/defs/tag" 1748 } 1749 } 1750 } 1751 }, 1752 "tag": { 1753 "type": "object", 1754 "additionalProperties": false, 1755 "properties": { 1756 "id": { 1757 "type": "string" 1758 }, 1759 "name": { 1760 "type": "string" 1761 }, 1762 "colour": { 1763 "type": "string" 1764 }, 1765 "exportable": { 1766 "type": "boolean" 1767 }, 1768 "hide_tag": { 1769 "type": "boolean" 1770 } 1771 } 1772 }, 1773 "galaxy": { 1774 "type": "object", 1775 "additionalProperties": false, 1776 "properties": { 1777 "id": { 1778 "type": "string" 1779 }, 1780 "uuid": { 1781 "type": "string" 1782 }, 1783 "name": { 1784 "type": "string" 1785 }, 1786 "type": { 1787 "type": "string" 1788 }, 1789 "description": { 1790 "type": "string" 1791 }, 1792 "version": { 1793 "type": "string" 1794 }, 1795 "GalaxyCluster": { 1796 "type": "array", 1797 "uniqueItems": true, 1798 "items": { 1799 "$ref": "#/defs/galaxy_cluster" 1800 } 1801 } 1802 } 1803 }, 1804 "galaxy_cluster": { 1805 "type": "object", 1806 "additionalProperties": false, 1807 "properties": { 1808 "id": { 1809 "type": "string" 1810 }, 1811 "uuid": { 1812 "type": "string" 1813 }, 1814 "type": { 1815 "type": "string" 1816 }, 1817 "value": { 1818 "type": "string" 1819 }, 1820 "tag_name": { 1821 "type": "string" 1822 }, 1823 "description": { 1824 "type": "string" 1825 }, 1826 "galaxy_id": { 1827 "type": "string" 1828 }, 1829 "source": { 1830 "type": "string" 1831 }, 1832 "authors": { 1833 "type": "array", 1834 "uniqueItems": true, 1835 "items": { 1836 "type": "string" 1838 } 1839 }, 1840 "tag_id": { 1841 "type": "string" 1842 }, 1843 "meta": { 1844 "type": "object" 1845 } 1846 } 1847 } 1848 }, 1849 "type": "object", 1850 "properties": { 1851 "Event": { 1852 "$ref": "#/defs/event" 1853 } 1854 }, 1855 "required": [ 1856 "Event" 1857 ] 1858 } 1860 4. Manifest 1862 MISP events can be shared over an HTTP repository, a file package or 1863 USB key. A manifest file is used to provide an index of MISP events 1864 allowing to only fetch the recently updated files without the need to 1865 parse each json file. 1867 4.1. Format 1869 A manifest file is a simple JSON file named manifest.json in a 1870 directory where the MISP events are located. Each MISP event is a 1871 file located in the same directory with the event uuid as filename 1872 with the json extension. 1874 The manifest format is a JSON object composed of a dictionary where 1875 the field is the uuid of the event. 1877 Each uuid is composed of a JSON object with the following fields 1878 which came from the original event referenced by the same uuid: 1880 o info (MUST) 1882 o Orgc object (MUST) 1884 o analysis (SHALL) 1885 o timestamp (MUST) 1887 o date (MUST) 1889 o threat_level_id (SHALL) 1891 In addition to the fields originating from the event, the following 1892 fields can be added: 1894 o integrity:sha256 represents the SHA256 value in hexadecimal 1895 representation of the associated MISP event file to ensure 1896 integrity of the file. (SHOULD) 1898 o integrity:pgp represents a detached PGP signature [RFC4880] of the 1899 associated MISP event file to ensure integrity of the file. 1900 (SHOULD) 1902 If a detached PGP signature is used for each MISP event, a detached 1903 PGP signature is a MUST to ensure integrity of the manifest file. A 1904 detached PGP signature for a manifest file is a manifest.json.pgp 1905 file containing the PGP signature. 1907 4.1.1. Sample Manifest 1908 { 1909 "57c6ac4c-c60c-4f79-a38f-b666950d210f": { 1910 "info": "Malspam 2016-08-31 (.wsf in .zip) - campaign: Photo", 1911 "Orgc": { 1912 "id": "2", 1913 "name": "CIRCL" 1914 }, 1915 "analysis": "0", 1916 "Tag": [ 1917 { 1918 "colour": "#3d7a00", 1919 "name": "circl:incident-classification=\"malware\"" 1920 }, 1921 { 1922 "colour": "#ffffff", 1923 "name": "tlp:white" 1924 } 1925 ], 1926 "timestamp": "1472638251", 1927 "date": "2016-08-31", 1928 "threat_level_id": "3" 1929 }, 1930 "5720accd-dd28-45f8-80e5-4605950d210f": { 1931 "info": "Malspam 2016-04-27 - Locky", 1932 "Orgc": { 1933 "id": "2", 1934 "name": "CIRCL" 1935 }, 1936 "analysis": "2", 1937 "Tag": [ 1938 { 1939 "colour": "#ffffff", 1940 "name": "tlp:white" 1941 }, 1942 { 1943 "colour": "#3d7a00", 1944 "name": "circl:incident-classification=\"malware\"" 1945 }, 1946 { 1947 "colour": "#2c4f00", 1948 "name": "malware_classification:malware-category=\"Ransomware\"" 1949 } 1950 ], 1951 "timestamp": "1461764231", 1952 "date": "2016-04-27", 1953 "threat_level_id": "3" 1954 } 1955 } 1956 5. Implementation 1958 MISP format is implemented by different software including the MISP 1959 threat sharing platform and libraries like PyMISP [MISP-P]. 1960 Implementations use the format as an export/import mechanism, staging 1961 transport format or synchronisation format as used in the MISP core 1962 platform. MISP format doesn't impose any restriction on the data 1963 representation of the format in data-structure of other 1964 implementations. 1966 6. Security Considerations 1968 MISP events might contain sensitive or confidential information. 1969 Adequate access control and encryption measures shall be implemented 1970 to ensure the confidentiality of the MISP events. 1972 Adversaries might include malicious content in MISP events and 1973 attributes. Implementation MUST consider the input of malicious 1974 inputs beside the standard threat information that might already 1975 include malicious intended inputs. 1977 7. Acknowledgements 1979 The authors wish to thank all the MISP community who are supporting 1980 the creation of open standards in threat intelligence sharing. 1982 8. Sample MISP file 1984 9. References 1986 9.1. Normative References 1988 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1989 Requirement Levels", BCP 14, RFC 2119, 1990 DOI 10.17487/RFC2119, March 1997, 1991 . 1993 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1994 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1995 DOI 10.17487/RFC4122, July 2005, 1996 . 1998 [RFC4627] Crockford, D., "The application/json Media Type for 1999 JavaScript Object Notation (JSON)", RFC 4627, 2000 DOI 10.17487/RFC4627, July 2006, 2001 . 2003 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2004 Thayer, "OpenPGP Message Format", RFC 4880, 2005 DOI 10.17487/RFC4880, November 2007, 2006 . 2008 9.2. Informative References 2010 [JSON-SCHEMA] 2011 "JSON Schema: A Media Type for Describing JSON Documents", 2012 2016, 2013 . 2015 [MISP-P] MISP, "MISP Project - Malware Information Sharing Platform 2016 and Threat Sharing", . 2018 [MISP-R] MISP, "MISP Object Relationship Types - common vocabulary 2019 of relationships", . 2022 [MISP-T] MISP, "MISP Taxonomies - shared and common vocabularies of 2023 tags", . 2025 Authors' Addresses 2027 Alexandre Dulaunoy 2028 Computer Incident Response Center Luxembourg 2029 16, bd d'Avranches 2030 Luxembourg L-1160 2031 Luxembourg 2033 Phone: +352 247 88444 2034 Email: alexandre.dulaunoy@circl.lu 2036 Andras Iklody 2037 Computer Incident Response Center Luxembourg 2038 16, bd d'Avranches 2039 Luxembourg L-1160 2040 Luxembourg 2042 Phone: +352 247 88444 2043 Email: andras.iklody@circl.lu