idnits 2.17.1 draft-dulaunoy-misp-core-format-02.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 7 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 (September 20, 2017) is 2409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'MISP-R' is defined on line 1925, but no explicit reference was found in the text == Unused Reference: 'MISP-T' is defined on line 1929, 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: March 24, 2018 September 20, 2017 7 MISP core format 8 draft-dulaunoy-misp-core-format-02 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 March 24, 2018. 38 Copyright Notice 40 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 2.6.1. Sample Object object . . . . . . . . . . . . . . . . 21 73 2.6.2. Object Attributes . . . . . . . . . . . . . . . . . . 21 74 2.7. Object References . . . . . . . . . . . . . . . . . . . . 24 75 2.7.1. Sample ObjectReference object . . . . . . . . . . . . 24 76 2.7.2. ObjectReference Attributes . . . . . . . . . . . . . 25 77 2.8. Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 78 2.8.1. Sample Tag . . . . . . . . . . . . . . . . . . . . . 27 79 2.9. Galaxy . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 2.9.1. Sample Galaxy . . . . . . . . . . . . . . . . . . . . 28 81 3. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 38 83 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 38 84 4.1.1. Sample Manifest . . . . . . . . . . . . . . . . . . . 39 85 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 41 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 88 8. Sample MISP file . . . . . . . . . . . . . . . . . . . . . . 41 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 41 91 9.2. Informative References . . . . . . . . . . . . . . . . . 42 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 94 1. Introduction 96 Sharing threat information became a fundamental requirements in the 97 Internet, security and intelligence community at large. Threat 98 information can include indicators of compromise, malicious file 99 indicators, financial fraud indicators or even detailed information 100 about a threat actor. MISP [MISP-P] started as an open source 101 project in late 2011 and the MISP format started to be widely used as 102 an exchange format within the community in the past years. The aim 103 of this document is to describe the specification and the MISP core 104 format. 106 1.1. Conventions and Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Format 114 2.1. Overview 116 The MISP core format is in the JSON [RFC4627] format. In MISP, an 117 event is composed of a single JSON object. 119 A capitalized key (like Event, Org) represent a data model and a non- 120 capitalized key is just an attribute. This nomenclature can support 121 an implementation to represent the MISP format in another data 122 structure. 124 2.2. Event 126 An event is a simple meta structure scheme where attributes and meta- 127 data are embedded to compose a coherent set of indicators. An event 128 can be composed from an incident, a security analysis report or a 129 specific threat actor analysis. The meaning of an event only depends 130 of the information embedded in the event. 132 2.2.1. Event Attributes 134 2.2.1.1. uuid 136 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 137 the event. The uuid MUST be preserved for any updates or transfer of 138 the same event. UUID version 4 is RECOMMENDED when assigning it to a 139 new event. 141 uuid is represented as a JSON string. uuid MUST be present. 143 2.2.1.2. id 145 id represents the human-readable identifier associated to the event 146 for a specific MISP instance. 148 id is represented as a JSON string. id SHALL be present. 150 2.2.1.3. published 152 published represents the event publication state. If the event was 153 published, the published value MUST be true. In any other 154 publication state, the published value MUST be false. 156 published is represented as a JSON boolean. published MUST be 157 present. 159 2.2.1.4. info 161 info represents the information field of the event. info is a free- 162 text value to provide a human-readable summary of the event. info 163 SHOULD NOT be bigger than 256 characters and SHOULD NOT include new- 164 lines. 166 info is represented as a JSON string. info MUST be present. 168 2.2.1.5. threat_level_id 170 threat_level_id represents the threat level. 172 4: 173 Undefined 175 3: 176 Low 178 2: 179 Medium 181 1: 182 High 184 If a higher granularity is required, a MISP taxonomy applied as a Tag 185 SHOULD be preferred. 187 threat_level_id is represented as a JSON string. threat_level_id 188 SHALL be present. 190 2.2.1.6. analysis 192 analysis represents the analysis level. 194 0: 195 Initial 197 1: 198 Ongoing 200 2: 201 Complete 203 If a higher granularity is required, a MISP taxonomy applied as a Tag 204 SHOULD be preferred. 206 analysis is represented as a JSON string. analysis SHALL be present. 208 2.2.1.7. date 210 date represents a reference date to the event in ISO 8601 format 211 (date only: YYYY-MM-DD). This date corresponds to the date the event 212 occured, which may be in the past. 214 date is represented as a JSON string. date MUST be present. 216 2.2.1.8. timestamp 218 timestamp represents a reference time when the event, or one of the 219 attributes within the event was created, or last updated/edited on 220 the instance. timestamp is expressed in seconds (decimal) since 1st 221 of January 1970 (Unix timestamp). The time zone MUST be UTC. 223 timestamp is represented as a JSON string. timestamp MUST be present. 225 2.2.1.9. publish_timestamp 227 publish_timestamp represents a reference time when the event was 228 published on the instance. published_timestamp is expressed in 229 seconds (decimal) since 1st of January 1970 (Unix timestamp). At 230 each publication of an event, publish_timestamp MUST be updated. The 231 time zone MUST be UTC. 233 publish_timestamp is represented as a JSON string. publish_timestamp 234 MUST be present. 236 2.2.1.10. org_id 238 org_id represents a human-readable identifier referencing an Org 239 object of the organization which generated the event. 241 The org_id MUST be updated when the event is generated by a new 242 instance. 244 org_id is represented as a JSON string. org_id MUST be present. 246 2.2.1.11. orgc_id 248 orgc_id represents a human-readable identifier referencing an Orgc 249 object of the organization which created the event. 251 The orgc_id and Orc object MUST be preserved for any updates or 252 transfer of the same event. 254 orgc_id is represented as a JSON string. orgc_id MUST be present. 256 2.2.1.12. attribute_count 258 attribute_count represents the number of attributes in the event. 259 attribute_count is expressed in decimal. 261 attribute_count is represented as a JSON string. attribute_count 262 SHALL be present. 264 2.2.1.13. distribution 266 distribution represents the basic distribution rules of the event. 267 The system must adhere to the distribution setting for access control 268 and for dissemination of the event. 270 distribution is represented by a JSON string. distribution MUST be 271 present and be one of the following options: 273 0 274 Your Organisation Only 276 1 277 This Community Only 279 2 280 Connected Communities 282 3 283 All Communities 285 4 286 Sharing Group 288 2.2.1.14. sharing_group_id 290 sharing_group_id represents a human-readable identifier referencing a 291 Sharing Group object that defines the distribution of the event, if 292 distribution level "4" is set. 294 sharing_group_id is represented by a JSON string and SHOULD be 295 present. If a distribution level other than "4" is chosen the 296 sharing_group_id MUST be set to "0". 298 2.3. Objects 300 2.3.1. Org 302 An Org object is composed of an uuid, name and id. 304 The uuid represents the Universally Unique IDentifier (UUID) 305 [RFC4122] of the organization. The organization UUID is globally 306 assigned to an organization and SHALL be kept overtime. 308 The name is a readable description of the organization and SHOULD be 309 present. The id is a human-readable identifier generated by the 310 instance and used as reference in the event. 312 uuid, name and id are represented as a JSON string. uuid, name and id 313 MUST be present. 315 2.3.1.1. Sample Org Object 317 "Org": { 318 "id": "2", 319 "name": "CIRCL", 320 "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f" 321 } 323 2.3.2. Orgc 325 An Orgc object is composed of an uuid, name and id. 327 The uuid MUST be preserved for any updates or transfer of the same 328 event. UUID version 4 is RECOMMENDED when assigning it to a new 329 event. The organization UUID is globally assigned to an organization 330 and SHALL be kept overtime. 332 The name is a readable description of the organization and SHOULD be 333 present. The id is a human-readable identifier generated by the 334 instance and used as reference in the event. 336 uuid, name and id are represented as a JSON string. uuid, name and id 337 MUST be present. 339 2.4. Attribute 341 Attributes are used to describe the indicators and contextual data of 342 an event. The main information contained in an attribute is made up 343 of a category-type-value triplet, where the category and type give 344 meaning and context to the value. Through the various category-type 345 combinations a wide range of information can be conveyed. 347 A MISP document MUST at least includes category-type-value triplet 348 described in section "Attribute Attributes". 350 2.4.1. Sample Attribute Object 352 "Attribute": { 353 "id": "346056", 354 "type": "comment", 355 "category": "Other", 356 "to_ids": false, 357 "uuid": "57f4f6d9-cd20-458b-84fd-109ec0a83869", 358 "event_id": "3357", 359 "distribution": "5", 360 "timestamp": "1475679332", 361 "comment": "", 362 "sharing_group_id": "0", 363 "deleted": false, 364 "value": "Hello world", 365 "SharingGroup": [], 366 "ShadowAttribute": [], 367 "RelatedAttribute": [] 368 } 370 2.4.2. Attribute Attributes 372 2.4.2.1. uuid 374 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 375 the event. The uuid MUST be preserved for any updates or transfer of 376 the same event. UUID version 4 is RECOMMENDED when assigning it to a 377 new event. 379 uuid is represented as a JSON string. uuid MUST be present. 381 2.4.2.2. id 383 id represents the human-readable identifier associated to the event 384 for a specific MISP instance. 386 id is represented as a JSON string. id SHALL be present. 388 2.4.2.3. type 390 type represents the means through which an attribute tries to 391 describe the intent of the attribute creator, using a list of pre- 392 defined attribute types. 394 type is represented as a JSON string. type MUST be present and it 395 MUST be a valid selection for the chosen category. The list of valid 396 category-type combinations is as follows: 398 Internal reference 399 text, link, comment, other, hex 401 Targeting data 402 target-user, target-email, target-machine, target-org, target- 403 location, target-external, comment 405 Antivirus detection 406 link, comment, text, hex, attachment, other 408 Payload delivery 409 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 410 ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, filename, 411 filename|md5, filename|sha1, filename|sha224, filename|sha256, 412 filename|sha384, filename|sha512, filename|sha512/224, 413 filename|sha512/256, filename|authentihash, filename|ssdeep, 414 filename|tlsh, filename|imphash, filename|impfuzzy, 415 filename|pehash, ip-src, ip-dst, hostname, domain, email-src, 416 email-dst, email-subject, email-attachment, url, user-agent, AS, 417 pattern-in-file, pattern-in-traffic, yara, attachment, malware- 418 sample, link, malware-type, comment, text, vulnerability, x509- 419 fingerprint-sha1, other, ip-dst|port, ip-src|port, hostname|port, 420 email-dst-display-name, email-src-display-name, email-header, 421 email-reply-to, email-x-mailer, email-mime-boundary, email-thread- 422 index, email-message-id, mobile-application-id 424 Artifacts dropped 425 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 426 ssdeep, imphash, impfuzzy, authentihash, filename, filename|md5, 427 filename|sha1, filename|sha224, filename|sha256, filename|sha384, 428 filename|sha512, filename|sha512/224, filename|sha512/256, 429 filename|authentihash, filename|ssdeep, filename|tlsh, 430 filename|imphash, filename|impfuzzy, filename|pehash, regkey, 431 regkey|value, pattern-in-file, pattern-in-memory, pdb, yara, 432 sigma, attachment, malware-sample, named pipe, mutex, windows- 433 scheduled-task, windows-service-name, windows-service-displayname, 434 comment, text, hex, x509-fingerprint-sha1, other 436 Payload installation 437 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 438 ssdeep, imphash, authentihash, pehash, tlsh, filename, 439 filename|md5, filename|sha1, filename|sha224, filename|sha256, 440 filename|sha384, filename|sha512, filename|sha512/224, 441 filename|sha512/256, filename|authentihash, filename|ssdeep, 442 filename|tlsh, filename|imphash, filename|pehash, pattern-in-file, 443 pattern-in-traffic, pattern-in-memory, yara, vulnerability, 444 attachment, malware-sample, malware-type, comment, text, hex, 445 x509-fingerprint-sha1, mobile-application-id, other 447 Persistence mechanism 448 filename, regkey, regkey|value, comment, text, other, text 450 Network activity 451 ip-src, ip-dst, hostname, domain, domain|ip, email-dst, url, uri, 452 user-agent, http-method, AS, snort, pattern-in-file, pattern-in- 453 traffic, attachment, comment, text, x509-fingerprint-sha1, other, 454 hex, cookie 456 Payload type 457 comment, text, other 459 Attribution 460 threat-actor, campaign-name, campaign-id, whois-registrant-phone, 461 whois-registrant-email, whois-registrant-name, whois-registrar, 462 whois-creation-date, comment, text, x509-fingerprint-sha1, other 464 External analysis 465 md5, sha1, sha256, filename, filename|md5, filename|sha1, 466 filename|sha256, ip-src, ip-dst, hostname, domain, domain|ip, url, 467 user-agent, regkey, regkey|value, AS, snort, pattern-in-file, 468 pattern-in-traffic, pattern-in-memory, vulnerability, attachment, 469 malware-sample, link, comment, text, x509-fingerprint-sha1, 470 github-repository, other 472 Financial fraud 473 btc, iban, bic, bank-account-nr, aba-rtn, bin, cc-number, prtn, 474 phone-number, comment, text, other, hex 476 Support tool 477 attachment, link, comment, text, other, hex 479 Social network 480 github-username, github-repository, github-organisation, jabber- 481 id, twitter-id, email-src, email-dst, comment, text, other 483 Person 484 first-name, middle-name, last-name, date-of-birth, place-of-birth, 485 gender, passport-number, passport-country, passport-expiration, 486 redress-number, nationality, visa-number, issue-date-of-the-visa, 487 primary-residence, country-of-residence, special-service-request, 488 frequent-flyer-number, travel-details, payment-details, place- 489 port-of-original-embarkation, place-port-of-clearance, place-port- 490 of-onward-foreign-destination, passenger-name-record-locator- 491 number, comment, text, other, phone-number 493 Other 494 comment, text, other, size-in-bytes, counter, datetime, cpe, port, 495 float, hex, phone-number 497 Attributes are based on the usage within their different communities. 498 Attributes can be extended on a regular basis and this reference 499 document is updated accordingly. 501 2.4.2.4. category 503 category represents the intent of what the attribute is describing as 504 selected by the attribute creator, using a list of pre-defined 505 attribute categories. 507 category is represented as a JSON string. category MUST be present 508 and it MUST be a valid selection for the chosen type. The list of 509 valid category-type combinations is mentioned above. 511 2.4.2.5. to_ids 513 to_ids represents whether the attribute is meant to be actionable. 514 Actionable defined attributes that can be used in automated processes 515 as a pattern for detection in Local or Network Intrusion Detection 516 System, log analysis tools or even filtering mechanisms. 518 to_ids is represented as a JSON boolean. to_ids MUST be present. 520 2.4.2.6. event_id 522 event_id represents a human-readable identifier referencing the Event 523 object that the attribute belongs to. 525 The event_id SHOULD be updated when the event is imported to reflect 526 the newly created event's id on the instance. 528 event_id is represented as a JSON string. event_id MUST be present. 530 2.4.2.7. distribution 532 distribution represents the basic distribution rules of the 533 attribute. The system must adhere to the distribution setting for 534 access control and for dissemination of the attribute. 536 distribution is represented by a JSON string. distribution MUST be 537 present and be one of the following options: 539 0 540 Your Organisation Only 542 1 543 This Community Only 545 2 546 Connected Communities 548 3 549 All Communities 551 4 552 Sharing Group 554 5 555 Inherit Event 557 2.4.2.8. timestamp 559 timestamp represents a reference time when the attribute was created 560 or last modified. timestamp is expressed in seconds (decimal) since 561 1st of January 1970 (Unix timestamp). The time zone MUST be UTC. 563 timestamp is represented as a JSON string. timestamp MUST be present. 565 2.4.2.9. comment 567 comment is a contextual comment field. 569 comment is represented by a JSON string. comment MAY be present. 571 2.4.2.10. sharing_group_id 573 sharing_group_id represents a human-readable identifier referencing a 574 Sharing Group object that defines the distribution of the attribute, 575 if distribution level "4" is set. 577 sharing_group_id is represented by a JSON string and SHOULD be 578 present. If a distribution level other than "4" is chosen the 579 sharing_group_id MUST be set to "0". 581 2.4.2.11. deleted 583 deleted represents a setting that allows attributes to be revoked. 584 Revoked attributes are not actionable and exist merely to inform 585 other instances of a revocation. 587 deleted is represented by a JSON boolean. deleted MUST be present. 589 2.4.2.12. data 591 data contains the base64 encoded contents of an attachment or a 592 malware sample. For malware samples, the sample MUST be encrypted 593 using a password protected zip archive, with the password being 594 "infected". 596 data is represented by a JSON string in base64 encoding. data MUST be 597 set for attributes of type malware-sample and attachment. 599 2.4.2.13. RelatedAttribute 601 RelatedAttribute is an array of attributes correlating with the 602 current attribute. Each element in the array represents an JSON 603 object which contains an Attribute dictionnary with the external 604 attributes who correlate. Each Attribute MUST include the id, 605 org_id, info and a value. Only the correlations found on the local 606 instance are shown in RelatedAttribute. 608 RelatedAttribute MAY be present. 610 2.4.2.14. ShadowAttribute 612 ShadowAttribute is an array of shadow attributes that serve as 613 proposals by third parties to alter the containing attribute. The 614 structure of a ShadowAttribute is similar to that of an Attribute, 615 which can be accepted or discarded by the event creator. If 616 accepted, the original attribute containing the shadow attribute is 617 removed and the shadow attribute is converted into an attribute. 619 Each shadow attribute that references an attribute MUST contain the 620 containing attribute's ID in the old_id field and the event's ID in 621 the event_id field. 623 2.4.2.15. value 625 value represents the payload of an attribute. The format of the 626 value is dependent on the type of the attribute. 628 value is represented by a JSON string. value MUST be present. 630 2.5. ShadowAttribute 632 ShadowAttributes are 3rd party created attributes that either propose 633 to add new information to an event or modify existing information. 634 They are not meant to be actionable until the event creator accepts 635 them - at which point they will be converted into attributes or 636 modify an existing attribute. 638 They are similar in structure to Attributes but additionally carry a 639 reference to the creator of the ShadowAttribute as well as a 640 revocation flag. 642 2.5.1. Sample Attribute Object 644 "ShadowAttribute": { 645 "id": "8", 646 "type": "ip-src", 647 "category": "Network activity", 648 "to_ids": false, 649 "uuid": "57d475f1-da78-4569-89de-1458c0a83869", 650 "event_uuid": "57d475e6-41c4-41ca-b450-145ec0a83869", 651 "event_id": "9", 652 "old_id": "319", 653 "comment": "", 654 "org_id": "1", 655 "proposal_to_delete": false, 656 "value": "5.5.5.5", 657 "deleted": false, 658 "Org": { 659 "id": "1", 660 "name": "MISP", 661 "uuid": "568cce5a-0c80-412b-8fdf-1ffac0a83869" 662 } 663 } 665 2.5.2. ShadowAttribute Attributes 667 2.5.2.1. uuid 669 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 670 the event. The uuid MUST be preserved for any updates or transfer of 671 the same event. UUID version 4 is RECOMMENDED when assigning it to a 672 new event. 674 uuid is represented as a JSON string. uuid MUST be present. 676 2.5.2.2. id 678 id represents the human-readable identifier associated to the event 679 for a specific MISP instance. 681 id is represented as a JSON string. id SHALL be present. 683 2.5.2.3. type 685 type represents the means through which an attribute tries to 686 describe the intent of the attribute creator, using a list of pre- 687 defined attribute types. 689 type is represented as a JSON string. type MUST be present and it 690 MUST be a valid selection for the chosen category. The list of valid 691 category-type combinations is as follows: 693 Internal reference 694 text, link, comment, other, hex 696 Targeting data 697 target-user, target-email, target-machine, target-org, target- 698 location, target-external, comment 700 Antivirus detection 701 link, comment, text, hex, attachment, other 703 Payload delivery 704 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 705 ssdeep, imphash, impfuzzy, authentihash, pehash, tlsh, filename, 706 filename|md5, filename|sha1, filename|sha224, filename|sha256, 707 filename|sha384, filename|sha512, filename|sha512/224, 708 filename|sha512/256, filename|authentihash, filename|ssdeep, 709 filename|tlsh, filename|imphash, filename|impfuzzy, 710 filename|pehash, ip-src, ip-dst, hostname, domain, email-src, 711 email-dst, email-subject, email-attachment, url, user-agent, AS, 712 pattern-in-file, pattern-in-traffic, yara, attachment, malware- 713 sample, link, malware-type, comment, text, vulnerability, x509- 714 fingerprint-sha1, other, ip-dst|port, ip-src|port, hostname|port, 715 email-dst-display-name, email-src-display-name, email-header, 716 email-reply-to, email-x-mailer, email-mime-boundary, email-thread- 717 index, email-message-id, mobile-application-id 719 Artifacts dropped 720 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 721 ssdeep, imphash, impfuzzy, authentihash, filename, filename|md5, 722 filename|sha1, filename|sha224, filename|sha256, filename|sha384, 723 filename|sha512, filename|sha512/224, filename|sha512/256, 724 filename|authentihash, filename|ssdeep, filename|tlsh, 725 filename|imphash, filename|impfuzzy, filename|pehash, regkey, 726 regkey|value, pattern-in-file, pattern-in-memory, pdb, yara, 727 sigma, attachment, malware-sample, named pipe, mutex, windows- 728 scheduled-task, windows-service-name, windows-service-displayname, 729 comment, text, hex, x509-fingerprint-sha1, other 731 Payload installation 732 md5, sha1, sha224, sha256, sha384, sha512, sha512/224, sha512/256, 733 ssdeep, imphash, authentihash, pehash, tlsh, filename, 734 filename|md5, filename|sha1, filename|sha224, filename|sha256, 735 filename|sha384, filename|sha512, filename|sha512/224, 736 filename|sha512/256, filename|authentihash, filename|ssdeep, 737 filename|tlsh, filename|imphash, filename|pehash, pattern-in-file, 738 pattern-in-traffic, pattern-in-memory, yara, vulnerability, 739 attachment, malware-sample, malware-type, comment, text, hex, 740 x509-fingerprint-sha1, mobile-application-id, other 742 Persistence mechanism 743 filename, regkey, regkey|value, comment, text, other, text 745 Network activity 746 ip-src, ip-dst, hostname, domain, domain|ip, email-dst, url, uri, 747 user-agent, http-method, AS, snort, pattern-in-file, pattern-in- 748 traffic, attachment, comment, text, x509-fingerprint-sha1, other, 749 hex, cookie 751 Payload type 752 comment, text, other 754 Attribution 755 threat-actor, campaign-name, campaign-id, whois-registrant-phone, 756 whois-registrant-email, whois-registrant-name, whois-registrar, 757 whois-creation-date, comment, text, x509-fingerprint-sha1, other 759 External analysis 760 md5, sha1, sha256, filename, filename|md5, filename|sha1, 761 filename|sha256, ip-src, ip-dst, hostname, domain, domain|ip, url, 762 user-agent, regkey, regkey|value, AS, snort, pattern-in-file, 763 pattern-in-traffic, pattern-in-memory, vulnerability, attachment, 764 malware-sample, link, comment, text, x509-fingerprint-sha1, 765 github-repository, other 767 Financial fraud 768 btc, iban, bic, bank-account-nr, aba-rtn, bin, cc-number, prtn, 769 phone-number, comment, text, other, hex 771 Support tool 772 attachment, link, comment, text, other, hex 774 Social network 775 github-username, github-repository, github-organisation, jabber- 776 id, twitter-id, email-src, email-dst, comment, text, other 778 Person 779 first-name, middle-name, last-name, date-of-birth, place-of-birth, 780 gender, passport-number, passport-country, passport-expiration, 781 redress-number, nationality, visa-number, issue-date-of-the-visa, 782 primary-residence, country-of-residence, special-service-request, 783 frequent-flyer-number, travel-details, payment-details, place- 784 port-of-original-embarkation, place-port-of-clearance, place-port- 785 of-onward-foreign-destination, passenger-name-record-locator- 786 number, comment, text, other, phone-number 788 Other 789 comment, text, other, size-in-bytes, counter, datetime, cpe, port, 790 float, hex, phone-number 792 Attributes are based on the usage within their different communities. 793 Attributes can be extended on a regular basis and this reference 794 document is updated accordingly. 796 2.5.2.4. category 798 category represents the intent of what the attribute is describing as 799 selected by the attribute creator, using a list of pre-defined 800 attribute categories. 802 category is represented as a JSON string. category MUST be present 803 and it MUST be a valid selection for the chosen type. The list of 804 valid category-type combinations is mentioned above. 806 2.5.2.5. to_ids 808 to_ids represents whether the Attribute to be created if the 809 ShadowAttribute is accepted is meant to be actionable. Actionable 810 defined attributes that can be used in automated processes as a 811 pattern for detection in Local or Network Intrusion Detection System, 812 log analysis tools or even filtering mechanisms. 814 to_ids is represented as a JSON boolean. to_ids MUST be present. 816 2.5.2.6. event_id 818 event_id represents a human-readable identifier referencing the Event 819 object that the ShadowAttribute belongs to. 821 The event_id SHOULD be updated when the event is imported to reflect 822 the newly created event's id on the instance. 824 event_id is represented as a JSON string. event_id MUST be present. 826 2.5.2.7. old_id 828 old_id represents a human-readable identifier referencing the 829 Attribute object that the ShadowAttribute belongs to. A 830 ShadowAttribute can this way target an existing Attribute, implying 831 that it is a proposal to modify an existing Attribute, or 832 alternatively it can be a proposal to create a new Attribute for the 833 containing Event. 835 The old_id SHOULD be updated when the event is imported to reflect 836 the newly created Attribute's id on the instance. Alternatively, if 837 the ShadowAttribute proposes the creation of a new Attribute, it 838 should be set to 0. 840 old_id is represented as a JSON string. old_id MUST be present. 842 2.5.2.8. timestamp 844 timestamp represents a reference time when the attribute was created 845 or last modified. timestamp is expressed in seconds (decimal) since 846 1st of January 1970 (Unix timestamp). The time zone MUST be UTC. 848 timestamp is represented as a JSON string. timestamp MUST be present. 850 2.5.2.9. comment 852 comment is a contextual comment field. 854 comment is represented by a JSON string. comment MAY be present. 856 2.5.2.10. org_id 858 org_id represents a human-readable identifier referencing the 859 proposal creator's Organisation object. 861 Whilst attributes can only be created by the event creator 862 organisation, shadow attributes can be created by third parties. 863 org_id tracks the creator organisation. 865 org_id is represented by a JSON string and MUST be present. 867 2.5.2.11. proposal_to_delete 869 proposal_to_delete is a boolean flag that sets whether the shadow 870 attribute proposes to alter an attribute, or whether it proposes to 871 remove it completely. 873 Accepting a shadow attribute with this flag set will remove the 874 target attribute. 876 proposal_to_delete is a JSON boolean and it MUST be present. If 877 proposal_to_delete is set to true, old_id MUST NOT be 0. 879 2.5.2.12. deleted 881 deleted represents a setting that allows shadow attributes to be 882 revoked. Revoked shadow attributes only serve to inform other 883 instances that the shadow attribute is no longer active. 885 deleted is represented by a JSON boolean. deleted SHOULD be present. 887 2.5.2.13. data 889 data contains the base64 encoded contents of an attachment or a 890 malware sample. For malware samples, the sample MUST be encrypted 891 using a password protected zip archive, with the password being 892 "infected". 894 data is represented by a JSON string in base64 encoding. data MUST be 895 set for shadow attributes of type malware-sample and attachment. 897 2.5.3. Org 899 An Org object is composed of an uuid, name and id. 901 The uuid represents the Universally Unique IDentifier (UUID) 902 [RFC4122] of the organization. The organization UUID is globally 903 assigned to an organization and SHALL be kept overtime. 905 The name is a readable description of the organization and SHOULD be 906 present. The id is a human-readable identifier generated by the 907 instance and used as reference in the event. 909 uuid, name and id are represented as a JSON string. uuid, name and id 910 MUST be present. 912 2.5.3.1. Sample Org Object 914 "Org": { 915 "id": "2", 916 "name": "CIRCL", 917 "uuid": "55f6ea5e-2c60-40e5-964f-47a8950d210f" 918 } 920 2.5.3.2. value 922 value represents the payload of an attribute. The format of the 923 value is dependent on the type of the attribute. 925 value is represented by a JSON string. value MUST be present. 927 2.6. Object 929 Objects serve as a contextual bond between a list of attributes 930 within an event. Their main purpose is to describe more complex 931 structures than can be described by a single attribute Each object is 932 created using an Object Template and carries the meta-data of the 933 template used for its creation within. Objects belong to a meta- 934 category and are defined by a name. 936 The schema used is described by the template_uuid and 937 template_version fields. 939 A MISP document containing an Object MUST contain a name, a meta- 940 category, a description, a template_uuid and a template_version as 941 described in the "Object Attributes" section. 943 2.6.1. Sample Object object 945 "Object": { 946 "id": "588", 947 "name": "file", 948 "meta-category": "file", 949 "description": "File object describing a file with meta-information", 950 "template_uuid": "688c46fb-5edb-40a3-8273-1af7923e2215", 951 "template_version": "3", 952 "event_id": "56", 953 "uuid": "398b0094-0384-4c48-9bf0-22b3dff9c4d3", 954 "timestamp": "1505747965", 955 "distribution": "5", 956 "sharing_group_id": "0", 957 "comment": "", 958 "deleted": false, 959 "ObjectReference": [], 960 "Attribute": [ 961 "id": "7822", 962 "type": "filename", 963 "category": "Payload delivery", 964 "to_ids": true, 965 "uuid": "59bfe3fb-bde0-4dfe-b5b1-2b10a07724d1", 966 "event_id": "56", 967 "distribution": "0", 968 "timestamp": "1505747963", 969 "comment": "", 970 "sharing_group_id": "0", 971 "deleted": false, 972 "disable_correlation": false, 973 "object_id": "588", 974 "object_relation": "filename", 975 "value": "StarCraft.exe", 976 "ShadowAttribute": [] 977 ] 978 } 980 2.6.2. Object Attributes 982 2.6.2.1. uuid 984 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 985 the object. The uuid MUST be preserved for any updates or transfer 986 of the same object. UUID version 4 is RECOMMENDED when assigning it 987 to a new object. 989 2.6.2.2. id 991 id represents the human-readable identifier associated to the object 992 for a specific MISP instance. 994 id is represented as a JSON string. id SHALL be present. 996 2.6.2.3. name 998 name represents the human-readable name of the object describing the 999 intent of the object package. 1001 name is represented as a JSON string. name MUST be present 1003 2.6.2.4. meta-category 1005 meta-category represents the sub-category of objects that the given 1006 object belongs to. meta-categories are not tied to a fixed list of 1007 options but can be created on the fly. 1009 meta-category is represented as a JSON string. meta-category MUST be 1010 present 1012 2.6.2.5. description 1014 description is a human-readable description of the given object type, 1015 as derived from the template used for creation. 1017 description is represented as a JSON string. id SHALL be present. 1019 2.6.2.6. template_uuid 1021 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 1022 the template used to create the object. The uuid MUST be preserved 1023 to preserve the object's association with the correct template used 1024 for creation. UUID version 4 is RECOMMENDED when assigning it to a 1025 new object. 1027 2.6.2.7. template_version 1029 template_version represents a numeric incrementing version of the 1030 template used to create the object. It is used to associate the 1031 object to the correct version of the template and together with the 1032 template_uuid forms an association to the correct template type and 1033 version. 1035 version is represented as a JSON string. version MUST be present. 1037 2.6.2.8. event_id 1039 event_id represents the human-readable identifier of the event that 1040 the object belongs to on a specific MISP instance. 1042 event_id is represented as a JSON string. event_id SHALL be present. 1044 2.6.2.9. timestamp 1046 timestamp represents a reference time when the object was created or 1047 last modified. timestamp is expressed in seconds (decimal) since 1st 1048 of January 1970 (Unix timestamp). The time zone MUST be UTC. 1050 timestamp is represented as a JSON string. timestamp MUST be present. 1052 2.6.2.10. distribution 1054 distribution represents the basic distribution rules of the object. 1055 The system must adhere to the distribution setting for access control 1056 and for dissemination of the object. 1058 distribution is represented by a JSON string. distribution MUST be 1059 present and be one of the following options: 1061 0 1062 Your Organisation Only 1064 1 1065 This Community Only 1067 2 1068 Connected Communities 1070 3 1071 All Communities 1073 4 1074 Sharing Group 1076 2.6.2.11. sharing_group_id 1078 sharing_group_id represents a human-readable identifier referencing a 1079 Sharing Group object that defines the distribution of the object, if 1080 distribution level "4" is set. 1082 sharing_group_id is represented by a JSON string and SHOULD be 1083 present. If a distribution level other than "4" is chosen the 1084 sharing_group_id MUST be set to "0". 1086 2.6.2.12. comment 1088 comment is a contextual comment field. 1090 comment is represented by a JSON string. comment MAY be present. 1092 2.6.2.13. deleted 1094 deleted represents a setting that allows attributes to be revoked. 1095 Revoked attributes are not actionable and exist merely to inform 1096 other instances of a revocation. 1098 deleted is represented by a JSON boolean. deleted MUST be present. 1100 2.6.2.14. Attribute 1102 Attribute is an array of attributes that describe the object with 1103 data. 1105 Each attribute in an object MUST contain the parent event's ID in the 1106 event_id field and the parent object's ID in the object_id field. 1108 2.7. Object References 1110 Object References serve as a logical link between an Object and 1111 another referenced Object or Attribute. The relationship is 1112 categorised by an enumerated value from a fixed vocabulary. 1114 The relationship_type is recommended to be taken from the MISP object 1115 relationship list [[MISP-R]] is RECOMMENDED to ensure a coherent 1116 naming of the tags 1118 All Object References MUST contain an object_uuid, a referenced_uuid 1119 and a relationship type. 1121 2.7.1. Sample ObjectReference object 1122 "ObjectReference": { 1123 "id": "195", 1124 "uuid": "59c21a2c-c0ac-4083-93b3-363da07724d1", 1125 "timestamp": "1505892908", 1126 "object_id": "591", 1127 "event_id": "113", 1128 "referenced_id": "590", 1129 "referenced_type": "1", 1130 "relationship_type": "derived-from", 1131 "comment": "", 1132 "deleted": false, 1133 "object_uuid": "59c1134d-8a40-4c14-ad94-0f7ba07724d1", 1134 "referenced_uuid": "59c1133c-9adc-4d06-a34b-0f7ca07724d1", 1135 } 1137 2.7.2. ObjectReference Attributes 1139 2.7.2.1. uuid 1141 uuid represents the Universally Unique IDentifier (UUID) [RFC4122] of 1142 the object reference. The uuid MUST be preserved for any updates or 1143 transfer of the same object reference. UUID version 4 is RECOMMENDED 1144 when assigning it to a new object reference. 1146 2.7.2.2. id 1148 id represents the human-readable identifier associated to the object 1149 reference for a specific MISP instance. 1151 id is represented as a JSON string. id SHALL be present. 1153 2.7.2.3. timestamp 1155 timestamp represents a reference time when the object was created or 1156 last modified. timestamp is expressed in seconds (decimal) since 1st 1157 of January 1970 (Unix timestamp). The time zone MUST be UTC. 1159 timestamp is represented as a JSON string. timestamp MUST be present. 1161 2.7.2.4. object_id 1163 object_id represents the human-readable identifier of the object that 1164 the object reference belongs to on a specific MISP instance. 1166 event_id is represented as a JSON string. event_id SHALL be present. 1168 2.7.2.5. event_id 1170 event_id represents the human-readable identifier of the event 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.6. referenced_id 1177 referenced_id represents the human-readable identifier of the object 1178 or attribute that the parent object of the object reference points to 1179 on a specific MISP instance. 1181 referenced_id is represented as a JSON string. referenced_id MAY be 1182 present. 1184 2.7.2.7. referenced_type 1186 referenced_type represents the numeric value describing what the 1187 object reference points to, "0" representing an attribute and "1" 1188 representing an object 1190 referenced_type is represented as a JSON string. referenced_type MAY 1191 be present. 1193 2.7.2.8. relationship_type 1195 relationship_type represents the human-readable context of the 1196 relationship between an object and another object or attribute as 1197 described by the object_reference. 1199 referenced_type is represented as a JSON string. relationship_type 1200 MUST be present. 1202 2.7.2.9. comment 1204 comment is a contextual comment field. 1206 comment is represented by a JSON string. comment MAY be present. 1208 2.7.2.10. deleted 1210 deleted represents a setting that allows object references to be 1211 revoked. Revoked object references are not actionable and exist 1212 merely to inform other instances of a revocation. 1214 deleted is represented by a JSON boolean. deleted MUST be present. 1216 2.7.2.11. object_uuid 1218 object_uuid represents the Universally Unique IDentifier (UUID) 1219 [RFC4122] of the object that the given object reference belongs to. 1220 The object_uuid MUST be preserved to preserve the object reference's 1221 association with the object. 1223 2.7.2.12. referenced_uuid 1225 referenced_uuid represents the Universally Unique IDentifier (UUID) 1226 [RFC4122] of the object or attribute that is being referenced by the 1227 object reference. The referenced_uuid MUST be preserved to preserve 1228 the object reference's association with the object or attribute. 1230 2.8. Tag 1232 A tag is a simple method to classify an event with a simple string. 1233 The tag name can be freely chosen. The tag name can be also chosen 1234 from a fixed machine-tag vocabulary called MISP taxonomies[[MISP-T]]. 1235 When an event is distributed outside an organisation, the use of MISP 1236 taxonomies[[MISP-T]] is RECOMMENDED to ensure a coherent naming of 1237 the tags. A tag is represented as a JSON array where each element 1238 describes each tag associated. A tag array SHALL be at event level 1239 or attribute level. A tag element is described with a name, id, 1240 colour and exportable flag. 1242 exportable represents a setting if the tag is kept local or 1243 exportable to other MISP instances. exportable is represented by a 1244 JSON boolean. id is a human-readable identifier that references the 1245 tag on the local instance. colour represents an RGB value of the tag. 1247 name MUST be present. colour, id and exportable SHALL be present. 1249 2.8.1. Sample Tag 1251 "Tag": [{ 1252 "exportable": true, 1253 "colour": "#ffffff", 1254 "name": "tlp:white", 1255 "id": "2" }] 1257 2.9. Galaxy 1259 A galaxy is a simple method to express a large object called cluster 1260 that can be attached to MISP events. A cluster can be composed of 1261 one or more elements. Elements are expressed as key-values. 1263 2.9.1. Sample Galaxy 1265 "Galaxy": [ { 1266 "id": "18", 1267 "uuid": "698774c7-8022-42c4-917f-8d6e4f06ada3", 1268 "name": "Threat Actor", 1269 "type": "threat-actor", 1270 "description": "Threat actors are characteristics of malicious actors 1271 (or adversaries) representing a cyber attack threat 1272 including presumed intent and historically observed behaviour.", 1273 "version": "1", 1274 "GalaxyCluster": [ 1275 { 1276 "id": "1699", 1277 "uuid": "7cdff317-a673-4474-84ec-4f1754947823", 1278 "type": "threat-actor", 1279 "value": "Anunak", 1280 "tag_name": "misp-galaxy:threat-actor=\"Anunak\"", 1281 "description": "Groups targeting financial organizations 1282 or people with significant financial assets.", 1283 "galaxy_id": "18", 1284 "source": "MISP Project", 1285 "authors": [ 1286 "Alexandre Dulaunoy", 1287 "Florian Roth", 1288 "Thomas Schreck", 1289 "Timo Steffens", 1290 "Various" 1291 ], 1292 "tag_id": "111", 1293 "meta": { 1294 "synonyms": [ 1295 "Carbanak", 1296 "Carbon Spider" 1297 ], 1298 "country": [ 1299 "RU" 1300 ], 1301 "motive": [ 1302 "Cybercrime" 1303 ] 1304 } 1305 } 1306 ] 1307 } 1308 ] 1310 3. JSON Schema 1312 The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP 1313 core format as literally described before. The JSON Schema is used 1314 to validate MISP events at creation time or parsing. 1316 { 1317 "$schema": "http://json-schema.org/draft-04/schema#", 1318 "title": "Validator for misp events", 1319 "id": "https://github.com/MISP/MISP/blob/2.4/format/2.4/schema.json", 1320 "defs": { 1321 "org": { 1322 "type": "object", 1323 "additionalProperties": false, 1324 "properties": { 1325 "id": { 1326 "type": "string" 1327 }, 1328 "name": { 1329 "type": "string" 1330 }, 1331 "uuid": { 1332 "type": "string" 1333 } 1334 }, 1335 "required": [ 1336 "uuid" 1337 ] 1338 }, 1339 "orgc": { 1340 "type": "object", 1341 "additionalProperties": false, 1342 "properties": { 1343 "id": { 1344 "type": "string" 1345 }, 1346 "name": { 1347 "type": "string" 1348 }, 1349 "uuid": { 1350 "type": "string" 1351 } 1352 }, 1353 "required": [ 1354 "uuid" 1355 ] 1356 }, 1357 "sharing_group": { 1358 "type": "object", 1359 "additionalProperties": false, 1360 "properties": { 1361 "id": { 1362 "type": "string" 1363 }, 1364 "name": { 1365 "type": "string" 1366 }, 1367 "releasability": { 1368 "type": "string" 1369 }, 1370 "description": { 1371 "type": "string" 1372 }, 1373 "uuid": { 1374 "type": "string" 1375 }, 1376 "organisation_uuid": { 1377 "type": "string" 1378 }, 1379 "org_id": { 1380 "type": "string" 1381 }, 1382 "sync_user_id": { 1383 "type": "string" 1384 }, 1385 "active": { 1386 "type": "boolean" 1387 }, 1388 "created": { 1389 "type": "string" 1390 }, 1391 "modified": { 1392 "type": "string" 1393 }, 1394 "local": { 1395 "type": "boolean" 1396 }, 1397 "roaming": { 1398 "type": "boolean" 1399 }, 1400 "Organisation": { 1401 "$ref": "#/defs/org" 1402 }, 1403 "SharingGroupOrg": { 1404 "type": "array", 1405 "uniqueItems": true, 1406 "items": { 1407 "$ref": "#/defs/sharing_group_org" 1408 } 1409 }, 1410 "SharingGroupServer": { 1411 "type": "array", 1412 "uniqueItems": true, 1413 "items": { 1414 "$ref": "#/defs/sharing_group_server" 1415 } 1416 }, 1417 "required": [ 1418 "uuid" 1419 ] 1420 }, 1421 "required": [ 1422 "uuid" 1423 ] 1424 }, 1425 "sharing_group_org": { 1426 "type": "object", 1427 "additionalProperties": false, 1428 "properties": { 1429 "id": { 1430 "type": "string" 1431 }, 1432 "sharing_group_id": { 1433 "type": "string" 1434 }, 1435 "org_id": { 1436 "type": "string" 1437 }, 1438 "extend": { 1439 "type": "boolean" 1440 }, 1441 "Organisation": { 1442 "$ref": "#/defs/org" 1443 } 1444 } 1445 }, 1446 "sharing_group_server": { 1447 "type": "object", 1448 "additionalProperties": false, 1449 "properties": { 1450 "id": { 1451 "type": "string" 1452 }, 1453 "sharing_group_id": { 1454 "type": "string" 1455 }, 1456 "server_id": { 1457 "type": "string" 1458 }, 1459 "all_orgs": { 1460 "type": "boolean" 1461 }, 1462 "Server": { 1463 "$ref": "#/defs/server" 1464 } 1465 } 1466 }, 1467 "server": { 1468 "type": "object", 1469 "additionalProperties": false, 1470 "properties": { 1471 "id": { 1472 "type": "string" 1473 }, 1474 "url": { 1475 "type": "string" 1476 }, 1477 "name": { 1478 "type": "string" 1479 } 1480 } 1481 }, 1482 "attribute": { 1483 "type": "object", 1484 "additionalProperties": false, 1485 "properties": { 1486 "id": { 1487 "type": "string" 1488 }, 1489 "type": { 1490 "type": "string" 1491 }, 1492 "category": { 1493 "type": "string" 1494 }, 1495 "to_ids": { 1496 "type": "boolean" 1497 }, 1498 "uuid": { 1499 "type": "string" 1500 }, 1501 "event_id": { 1502 "type": "string" 1503 }, 1504 "distribution": { 1505 "type": "string" 1506 }, 1507 "timestamp": { 1508 "type": "string" 1509 }, 1510 "comment": { 1511 "type": "string" 1512 }, 1513 "sharing_group_id": { 1514 "type": "string" 1515 }, 1516 "deleted": { 1517 "type": "boolean" 1518 }, 1519 "disable_correlation": { 1520 "type": "boolean" 1521 }, 1522 "value": { 1523 "type": "string" 1524 }, 1525 "data": { 1526 "type": "string" 1527 }, 1528 "SharingGroup": { 1529 "$ref": "#/defs/sharing_group" 1530 }, 1531 "ShadowAttribute": { 1532 "type": "array", 1533 "uniqueItems": true, 1534 "items": { 1535 "$ref": "#/defs/attribute" 1536 } 1537 }, 1538 "Tag": { 1539 "type": "array", 1540 "uniqueItems": true, 1541 "items": { 1542 "$ref": "#/defs/tag" 1543 } 1544 } 1545 } 1546 }, 1547 "event": { 1548 "type": "object", 1549 "additionalProperties": false, 1550 "properties": { 1551 "id": { 1552 "type": "string" 1553 }, 1554 "orgc_id": { 1555 "type": "string" 1556 }, 1557 "org_id": { 1558 "type": "string" 1559 }, 1560 "date": { 1561 "type": "string" 1562 }, 1563 "threat_level_id": { 1564 "type": "string" 1565 }, 1566 "info": { 1567 "type": "string" 1568 }, 1569 "published": { 1570 "type": "boolean" 1571 }, 1572 "uuid": { 1573 "type": "string" 1574 }, 1575 "attribute_count": { 1576 "type": "string" 1577 }, 1578 "analysis": { 1579 "type": "string" 1580 }, 1581 "timestamp": { 1582 "type": "string" 1583 }, 1584 "distribution": { 1585 "type": "string" 1586 }, 1587 "proposal_email_lock": { 1588 "type": "boolean" 1589 }, 1590 "locked": { 1591 "type": "boolean" 1592 }, 1593 "publish_timestamp": { 1594 "type": "string" 1595 }, 1596 "sharing_group_id": { 1597 "type": "string" 1599 }, 1600 "disable_correlation": { 1601 "type": "boolean" 1602 }, 1603 "event_creator_email": { 1604 "type": "string" 1605 }, 1606 "Org": { 1607 "$ref": "#/defs/org" 1608 }, 1609 "Orgc": { 1610 "$ref": "#/defs/org" 1611 }, 1612 "SharingGroup": { 1613 "$ref": "#/defs/sharing_group" 1614 }, 1615 "Attribute": { 1616 "type": "array", 1617 "uniqueItems": true, 1618 "items": { 1619 "$ref": "#/defs/attribute" 1620 } 1621 }, 1622 "ShadowAttribute": { 1623 "type": "array", 1624 "uniqueItems": true, 1625 "items": { 1626 "$ref": "#/defs/attribute" 1627 } 1628 }, 1629 "RelatedEvent": { 1630 "type": "array", 1631 "uniqueItems": true, 1632 "items": { 1633 "type": "object", 1634 "additionalProperties": false, 1635 "properties": { 1636 "Event":{ 1637 "$ref": "#/defs/event" 1638 } 1639 } 1640 } 1641 }, 1642 "Galaxy": { 1643 "type": "array", 1644 "uniqueItems": true, 1645 "items": { 1646 "$ref": "#/defs/galaxy" 1648 } 1649 }, 1650 "Tag": { 1651 "type": "array", 1652 "uniqueItems": true, 1653 "items": { 1654 "$ref": "#/defs/tag" 1655 } 1656 } 1657 } 1658 }, 1659 "tag": { 1660 "type": "object", 1661 "additionalProperties": false, 1662 "properties": { 1663 "id": { 1664 "type": "string" 1665 }, 1666 "name": { 1667 "type": "string" 1668 }, 1669 "colour": { 1670 "type": "string" 1671 }, 1672 "exportable": { 1673 "type": "boolean" 1674 }, 1675 "hide_tag": { 1676 "type": "boolean" 1677 } 1678 } 1679 }, 1680 "galaxy": { 1681 "type": "object", 1682 "additionalProperties": false, 1683 "properties": { 1684 "id": { 1685 "type": "string" 1686 }, 1687 "uuid": { 1688 "type": "string" 1689 }, 1690 "name": { 1691 "type": "string" 1692 }, 1693 "type": { 1694 "type": "string" 1695 }, 1696 "description": { 1697 "type": "string" 1698 }, 1699 "version": { 1700 "type": "string" 1701 }, 1702 "GalaxyCluster": { 1703 "type": "array", 1704 "uniqueItems": true, 1705 "items": { 1706 "$ref": "#/defs/galaxy_cluster" 1707 } 1708 } 1709 } 1710 }, 1711 "galaxy_cluster": { 1712 "type": "object", 1713 "additionalProperties": false, 1714 "properties": { 1715 "id": { 1716 "type": "string" 1717 }, 1718 "uuid": { 1719 "type": "string" 1720 }, 1721 "type": { 1722 "type": "string" 1723 }, 1724 "value": { 1725 "type": "string" 1726 }, 1727 "tag_name": { 1728 "type": "string" 1729 }, 1730 "description": { 1731 "type": "string" 1732 }, 1733 "galaxy_id": { 1734 "type": "string" 1735 }, 1736 "source": { 1737 "type": "string" 1738 }, 1739 "authors": { 1740 "type": "array", 1741 "uniqueItems": true, 1742 "items": { 1743 "type": "string" 1745 } 1746 }, 1747 "tag_id": { 1748 "type": "string" 1749 }, 1750 "meta": { 1751 "type": "object" 1752 } 1753 } 1754 } 1755 }, 1756 "type": "object", 1757 "properties": { 1758 "Event": { 1759 "$ref": "#/defs/event" 1760 } 1761 }, 1762 "required": [ 1763 "Event" 1764 ] 1765 } 1767 4. Manifest 1769 MISP events can be shared over an HTTP repository, a file package or 1770 USB key. A manifest file is used to provide an index of MISP events 1771 allowing to only fetch the recently updated files without the need to 1772 parse each json file. 1774 4.1. Format 1776 A manifest file is a simple JSON file named manifest.json in a 1777 directory where the MISP events are located. Each MISP event is a 1778 file located in the same directory with the event uuid as filename 1779 with the json extension. 1781 The manifest format is a JSON object composed of a dictionary where 1782 the field is the uuid of the event. 1784 Each uuid is composed of a JSON object with the following fields 1785 which came from the original event referenced by the same uuid: 1787 o info (MUST) 1789 o Orgc object (MUST) 1791 o analysis (SHALL) 1792 o timestamp (MUST) 1794 o date (MUST) 1796 o threat_level_id (SHALL) 1798 In addition to the fields originating from the event, the following 1799 fields can be added: 1801 o integrity:sha256 represents the SHA256 value in hexadecimal 1802 representation of the associated MISP event file to ensure 1803 integrity of the file. (SHOULD) 1805 o integrity:pgp represents a detached PGP signature [RFC4880] of the 1806 associated MISP event file to ensure integrity of the file. 1807 (SHOULD) 1809 If a detached PGP signature is used for each MISP event, a detached 1810 PGP signature is a MUST to ensure integrity of the manifest file. A 1811 detached PGP signature for a manifest file is a manifest.json.pgp 1812 file containing the PGP signature. 1814 4.1.1. Sample Manifest 1815 { 1816 "57c6ac4c-c60c-4f79-a38f-b666950d210f": { 1817 "info": "Malspam 2016-08-31 (.wsf in .zip) - campaign: Photo", 1818 "Orgc": { 1819 "id": "2", 1820 "name": "CIRCL" 1821 }, 1822 "analysis": "0", 1823 "Tag": [ 1824 { 1825 "colour": "#3d7a00", 1826 "name": "circl:incident-classification=\"malware\"" 1827 }, 1828 { 1829 "colour": "#ffffff", 1830 "name": "tlp:white" 1831 } 1832 ], 1833 "timestamp": "1472638251", 1834 "date": "2016-08-31", 1835 "threat_level_id": "3" 1836 }, 1837 "5720accd-dd28-45f8-80e5-4605950d210f": { 1838 "info": "Malspam 2016-04-27 - Locky", 1839 "Orgc": { 1840 "id": "2", 1841 "name": "CIRCL" 1842 }, 1843 "analysis": "2", 1844 "Tag": [ 1845 { 1846 "colour": "#ffffff", 1847 "name": "tlp:white" 1848 }, 1849 { 1850 "colour": "#3d7a00", 1851 "name": "circl:incident-classification=\"malware\"" 1852 }, 1853 { 1854 "colour": "#2c4f00", 1855 "name": "malware_classification:malware-category=\"Ransomware\"" 1856 } 1857 ], 1858 "timestamp": "1461764231", 1859 "date": "2016-04-27", 1860 "threat_level_id": "3" 1861 } 1862 } 1863 5. Implementation 1865 MISP format is implemented by different software including the MISP 1866 threat sharing platform and libraries like PyMISP [MISP-P]. 1867 Implementations use the format as an export/import mechanism, staging 1868 transport format or synchronisation format as used in the MISP core 1869 platform. MISP format doesn't impose any restriction on the data 1870 representation of the format in data-structure of other 1871 implementations. 1873 6. Security Considerations 1875 MISP events might contain sensitive or confidential information. 1876 Adequate access control and encryption measures shall be implemented 1877 to ensure the confidentiality of the MISP events. 1879 Adversaries might include malicious content in MISP events and 1880 attributes. Implementation MUST consider the input of malicious 1881 inputs beside the standard threat information that might already 1882 include malicious intended inputs. 1884 7. Acknowledgements 1886 The authors wish to thank all the MISP community who are supporting 1887 the creation of open standards in threat intelligence sharing. 1889 8. Sample MISP file 1891 9. References 1893 9.1. Normative References 1895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1896 Requirement Levels", BCP 14, RFC 2119, 1897 DOI 10.17487/RFC2119, March 1997, 1898 . 1900 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1901 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1902 DOI 10.17487/RFC4122, July 2005, 1903 . 1905 [RFC4627] Crockford, D., "The application/json Media Type for 1906 JavaScript Object Notation (JSON)", RFC 4627, 1907 DOI 10.17487/RFC4627, July 2006, 1908 . 1910 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1911 Thayer, "OpenPGP Message Format", RFC 4880, 1912 DOI 10.17487/RFC4880, November 2007, 1913 . 1915 9.2. Informative References 1917 [JSON-SCHEMA] 1918 "JSON Schema: A Media Type for Describing JSON Documents", 1919 2016, 1920 . 1922 [MISP-P] MISP, "MISP Project - Malware Information Sharing Platform 1923 and Threat Sharing", . 1925 [MISP-R] MISP, "MISP Object Relationship Types - common vocabulary 1926 of relationships", . 1929 [MISP-T] MISP, "MISP Taxonomies - shared and common vocabularies of 1930 tags", . 1932 Authors' Addresses 1934 Alexandre Dulaunoy 1935 Computer Incident Response Center Luxembourg 1936 16, bd d'Avranches 1937 Luxembourg L-1160 1938 Luxembourg 1940 Phone: +352 247 88444 1941 Email: alexandre.dulaunoy@circl.lu 1943 Andras Iklody 1944 Computer Incident Response Center Luxembourg 1945 16, bd d'Avranches 1946 Luxembourg L-1160 1947 Luxembourg 1949 Phone: +352 247 88444 1950 Email: andras.iklody@circl.lu