idnits 2.17.1 draft-dulaunoy-misp-taxonomy-format-07.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 a Security Considerations section. ** 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 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The predicates array contains one or more JSON objects which lists all the possible predicates. The JSON object contains two fields: value and expanded. value MUST be present. expanded SHOULD be present. value is represented as a string and describes the predicate value. The predicate value MUST not contain spaces or colons. expanded is represented as a string and describes the human-readable version of the predicate value. An exclusive property MAY be present and defines at namespace level if the values are mutually exclusive. -- The document date (April 8, 2019) is 1839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1086 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: October 10, 2019 April 8, 2019 7 MISP taxonomy format 8 draft-dulaunoy-misp-taxonomy-format-07 10 Abstract 12 This document describes the MISP taxonomy format which describes a 13 simple JSON format to represent machine tags (also called triple 14 tags) vocabularies. A public directory of common vocabularies called 15 MISP taxonomies is available and relies on the MISP taxonomy format. 16 MISP taxonomies are used to classify cyber security events, threats, 17 suspicious events, or indicators. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 10, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 55 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. predicates . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. values . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.4. optional fields . . . . . . . . . . . . . . . . . . . . . 4 60 2.4.1. colour . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.4.2. description . . . . . . . . . . . . . . . . . . . . . 5 62 2.4.3. numerical_value . . . . . . . . . . . . . . . . . . . 5 63 3. Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Sample Manifest . . . . . . . . . . . . . . . . . . . . . 7 65 4. Sample Taxonomy in MISP taxonomy format . . . . . . . . . . . 7 66 4.1. Admiralty Scale Taxonomy . . . . . . . . . . . . . . . . 7 67 4.2. Open Source Intelligence - Classification . . . . . . . . 9 68 4.3. Available taxonomies in the public directory . . . . . . 11 69 5. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 73 7.2. Informative References . . . . . . . . . . . . . . . . . 23 74 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 77 1. Introduction 79 Sharing threat information became a fundamental requirements on the 80 Internet, security and intelligence community at large. Threat 81 information can include indicators of compromise, malicious file 82 indicators, financial fraud indicators or even detailed information 83 about a threat actor. While sharing such indicators or information, 84 classification plays an important role to ensure adequate 85 distribution, understanding, validation or action of the shared 86 information. MISP taxonomies is a public repository of known 87 vocabularies that can be used in threat information sharing. 89 Machine tags were introduced in 2007 [machine-tags] to allow users to 90 be more precise when tagging their pictures with geolocation. So a 91 machine tag is a tag which uses a special syntax to provide more 92 information to users and machines. Machine tags are also known as 93 triple tags due to their format. 95 In the MISP taxonomy context, machine tags help analysts to classify 96 their cybersecurity events, indicators or threats. MISP taxonomies 97 can be used for classification, filtering, triggering actions or 98 visualisation depending on their use in threat intelligence platforms 99 such as MISP [MISP-P]. 101 1.1. Conventions and Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. Format 109 A machine tag is composed of a namespace (MUST), a predicate (MUST) 110 and an optional value (OPTIONAL). 112 Machine tags are represented as a string. Below listed are a set of 113 sample machine tags for different namespaces such as tlp, admiralty- 114 scale and osint. 116 tlp:amber 117 admiralty-scale:information-credibility="1" 118 osint:source-type="blog-post" 120 The MISP taxonomy format describes how to define a machine tag 121 namespace in a parseable format. The objective is to provide a 122 simple format to describe machine tag (aka triple tag) vocabularies. 124 2.1. Overview 126 The MISP taxonomy format uses the JSON [RFC4627] format. Each 127 namespace is represented as a JSON object with meta information 128 including the following fields: namespace, description, version, 129 type. 131 namespace defines the overall namespace of the machine tag. The 132 namespace is represented as a string and MUST be present. The 133 description is represented as a string and MUST be present. A 134 version is represented as a unsigned integer MUST be present. A type 135 defines where a specific taxonomy is applicable and a type can be 136 applicable at event, user or org level. The type is represented as 137 an array containing one or more type and SHOULD be present. If a 138 type is not mentioned, by default, the taxonomy is applicable at 139 event level only. An exclusive boolean property MAY be present and 140 defines at namespace level if the predicates are mutually exclusive. 142 predicates defines all the predicates available in the namespace 143 defined. predicates is represented as an array of JSON objects. 144 predicates MUST be present and MUST at least content one element. 146 values defines all the values for each predicate in the namespace 147 defined. values SHOULD be present. 149 2.2. predicates 151 The predicates array contains one or more JSON objects which lists 152 all the possible predicates. The JSON object contains two fields: 153 value and expanded. value MUST be present. expanded SHOULD be 154 present. value is represented as a string and describes the predicate 155 value. The predicate value MUST not contain spaces or colons. 156 expanded is represented as a string and describes the human-readable 157 version of the predicate value. An exclusive property MAY be present 158 and defines at namespace level if the values are mutually exclusive. 160 2.3. values 162 The values array contain one or more JSON objects which lists all the 163 possible values of a predicate. The JSON object contains two fields: 164 predicate and entry. predicate is represented as a string and 165 describes the predicate value. entry is an array with one or more 166 JSON objects. The JSON object contains two fields: value and 167 expanded. value MUST be present. expanded SHOULD be present. value is 168 represented as a string and describes the machine parsable value. 169 expanded is represented as a string and describes the human-readable 170 version of the value. 172 2.4. optional fields 174 2.4.1. colour 176 colour fields MAY be used at predicates or values level to set a 177 specify colour that MAY be used by the implementation. The colour 178 field is described as an RGB colour fill in hexadecimal 179 representation. 181 Example use of the colour field in the Traffic Light Protocol (TLP): 183 "predicates": [ 184 { 185 "colour": "#CC0033", 186 "expanded": "(TLP:RED) Information exclusively and directly 187 given to (a group of) individual recipients. 188 Sharing outside is not legitimate.", 189 "value": "red" 190 }, 191 { 192 "colour": "#FFC000", 193 "expanded": "(TLP:AMBER) Information exclusively given 194 to an organization; sharing limited within 195 the organization to be effectively acted upon.", 196 "value": "amber" 197 }...] 199 2.4.2. description 201 description fields MAY be used at predicates or values level to add a 202 descriptive and human-readable information about the specific 203 predicate or value. The field is represented as a string. 204 Implementations MAY use the description field to improve more 205 contextual information. The description at the namespace level is a 206 MUST as described above. 208 2.4.3. numerical_value 210 numerical_value fields MAY be used at a predicate or value level to 211 add a machine-readable numeric value to a specific predicate or 212 value. The field is represented as a JSON number. Implementations 213 SHOULD use the decimal value provided to support scoring or 214 filtering. 216 The decimal range for numerical_value SHOULD use a range from 0 up to 217 100. The range is recommended to support common mathematical 218 properties among taxonomies. 220 Example use of the numerical_value in the MISP confidence level: 222 { 223 "predicate": "confidence-level", 224 "entry": [ 225 { 226 "expanded": "Completely confident", 227 "value": "completely-confident", 228 "numerical_value": 100 229 }, 230 { 231 "expanded": "Usually confident", 232 "value": "usually-confident", 233 "numerical_value": 75 234 }, 235 { 236 "expanded": "Fairly confident", 237 "value": "fairly-confident", 238 "numerical_value": 50 239 }, 240 { 241 "expanded": "Rarely confident", 242 "value": "rarely-confident", 243 "numerical_value": 25 244 }, 245 { 246 "expanded": "Unconfident", 247 "value": "unconfident", 248 "numerical_value": 0 249 }, 250 { 251 "expanded": "Confidence cannot be evaluated", 252 "value": "confidence-cannot-be-evalued" 253 } 254 ] 255 } 257 3. Directory 259 The MISP taxonomies directory is publicly available [MISP-T] in a git 260 repository. The repository contains a directory per namespace then a 261 file machinetag.json which contains the taxonomy as described in the 262 format above. In the root of the repository, a MANIFEST.json exists 263 containing a list of all the taxonomies. 265 The MANIFEST.json file is composed of an JSON object with metadata 266 like version, license, description, url and path. A taxonomies array 267 describes the taxonomy available with the description, name and 268 version field. 270 3.1. Sample Manifest 272 { 273 "version": "20161009", 274 "license": "CC-0", 275 "description": "Manifest file of MISP taxonomies available.", 276 "url": 277 "https://raw.githubusercontent.com/MISP/misp-taxonomies/master/", 278 "path": "machinetag.json", 279 "taxonomies": [ 280 { 281 "description": "The Admiralty Scale (also called the NATO System) 282 is used to rank the reliability of a source and 283 the credibility of an information.", 284 "name": "admiralty-scale", 285 "version": 1 286 }, 287 { 288 "description": "Open Source Intelligence - Classification.", 289 "name": "osint", 290 "version": 2 291 }] 292 } 294 4. Sample Taxonomy in MISP taxonomy format 296 4.1. Admiralty Scale Taxonomy 298 "namespace": "admiralty-scale", 299 "description": "The Admiralty Scale (also called the NATO System) 300 is used to rank the reliability of a source and 301 the credibility of an information.", 302 "version": 1, 303 "predicates": [ 304 { 305 "value": "source-reliability", 306 "expanded": "Source Reliability" 307 }, 308 { 309 "value": "information-credibility", 310 "expanded": "Information Credibility" 311 } 312 ], 313 "values": [ 314 { 315 "predicate": "source-reliability", 316 "entry": [ 317 { 318 "value": "a", 319 "expanded": "Completely reliable" 320 }, 321 { 322 "value": "b", 323 "expanded": "Usually reliable" 324 }, 325 { 326 "value": "c", 327 "expanded": "Fairly reliable" 328 }, 329 { 330 "value": "d", 331 "expanded": "Not usually reliable" 332 }, 333 { 334 "value": "e", 335 "expanded": "Unreliable" 336 }, 337 { 338 "value": "f", 339 "expanded": "Reliability cannot be judged" 340 } 341 ] 342 }, 343 { 344 "predicate": "information-credibility", 345 "entry": [ 346 { 347 "value": "1", 348 "expanded": "Confirmed by other sources" 349 }, 350 { 351 "value": "2", 352 "expanded": "Probably true" 353 }, 354 { 355 "value": "3", 356 "expanded": "Possibly true" 357 }, 358 { 359 "value": "4", 360 "expanded": "Doubtful" 361 }, 362 { 363 "value": "5", 364 "expanded": "Improbable" 365 }, 366 { 367 "value": "6", 368 "expanded": "Truth cannot be judged" 369 } 370 ] 371 } 372 ] 373 } 375 4.2. Open Source Intelligence - Classification 377 { 378 "values": [ 379 { 380 "entry": [ 381 { 382 "expanded": "Blog post", 383 "value": "blog-post" 384 }, 385 { 386 "expanded": "Technical or analysis report", 387 "value": "technical-report" 388 }, 389 { 390 "expanded": "News report", 391 "value": "news-report" 392 }, 393 { 394 "expanded": "Pastie-like website", 395 "value": "pastie-website" 396 }, 397 { 398 "expanded": "Electronic forum", 399 "value": "electronic-forum" 400 }, 401 { 402 "expanded": "Mailing-list", 403 "value": "mailing-list" 404 }, 405 { 406 "expanded": "Block or Filter List", 407 "value": "block-or-filter-list" 408 }, 409 { 410 "expanded": "Expansion", 411 "value": "expansion" 412 } 413 ], 414 "predicate": "source-type" 415 }, 416 { 417 "predicate": "lifetime", 418 "entry": [ 419 { 420 "value": "perpetual", 421 "expanded": "Perpetual", 422 "description": "Information available publicly on long-term" 423 }, 424 { 425 "value": "ephemeral", 426 "expanded": "Ephemeral", 427 "description": "Information available publicly on short-term" 428 } 429 ] 430 }, 431 { 432 "predicate": "certainty", 433 "entry": [ 434 { 435 "numerical_value": 100, 436 "value": "100", 437 "expanded": "100% Certainty", 438 "description": "100% Certainty" 439 }, 440 { 441 "numerical_value": 93, 442 "value": "93", 443 "expanded": "93% Almost certain", 444 "description": "93% Almost certain" 445 }, 446 { 447 "numerical_value": 75, 448 "value": "75", 449 "expanded": "75% Probable", 450 "description": "75% Probable" 451 }, 452 { 453 "numerical_value": 50, 454 "value": "50", 455 "expanded": "50% Chances about even", 456 "description": "50% Chances about even" 457 }, 458 { 459 "numerical_value": 30, 460 "value": "30", 461 "expanded": "30% Probably not", 462 "description": "30% Probably not" 463 }, 464 { 465 "numerical_value": 7, 466 "value": "7", 467 "expanded": "7% Almost certainly not", 468 "description": "7% Almost certainly not" 469 }, 470 { 471 "numerical_value": 0, 472 "value": "0", 473 "expanded": "0% Impossibility", 474 "description": "0% Impossibility" 475 } 476 ] 477 } 478 ], 479 "namespace": "osint", 480 "description": "Open Source Intelligence - Classification", 481 "version": 3, 482 "predicates": [ 483 { 484 "value": "source-type", 485 "expanded": "Source Type" 486 }, 487 { 488 "value": "lifetime", 489 "expanded": "Lifetime of the information 490 as Open Source Intelligence" 491 }, 492 { 493 "value": "certainty", 494 "expanded": "Certainty of the elements mentioned 495 in this Open Source Intelligence" 496 } 497 ] 498 } 500 4.3. Available taxonomies in the public directory 502 The public directory of MISP taxonomies [MISP-T] contains a variety 503 of taxonomy in various fields such as: 505 CERT-XLM: 506 CERT-XLM Security Incident Classification. 508 DML: 510 The Detection Maturity Level (DML) model is a capability maturity 511 model for referencing ones maturity in detecting cyber attacks. 512 It's designed for organizations who perform intel-driven detection 513 and response and who put an emphasis on having a mature detection 514 program. 516 PAP: 517 The Permissible Actions Protocol - or short: PAP - was designed to 518 indicate how the received information can be used. 520 access-method: 521 The access method used to remotely access a system. 523 accessnow: 524 Access Now classification to classify an issue (such as security, 525 human rights, youth rights). 527 action-taken: 528 Action taken in the case of a security incident (CSIRT 529 perspective). 531 admiralty-scale: 532 The Admiralty Scale (also called the NATO System) is used to rank 533 the reliability of a source and the credibility of an information. 535 adversary: 536 An overview and description of the adversary infrastructure. 538 ais-marking: 539 AIS Marking Schema implementation is maintained by the National 540 Cybersecurity and Communication Integration Center (NCCIC) of the 541 U.S. Department of Homeland Security (DHS) 543 analyst-assessment: 544 A series of assessment predicates describing the analyst 545 capabilities to perform analysis. These assessment can be 546 assigned by the analyst him/herself or by another party evaluating 547 the analyst. 549 approved-category-of-action: 550 A pre-approved category of action for indicators being shared with 551 partners (MIMIC). 553 binary-class: 554 Custom taxonomy for types of binary file. 556 cccs: 557 Internal taxonomy for CCCS. 559 circl: 560 CIRCL Taxonomy is a simple scheme for incident classification and 561 area topic where the incident took place. 563 collaborative-intelligence: 564 Collaborative intelligence support language is a common language 565 to support analysts to perform their analysis to get crowdsourced 566 support when using threat intelligence sharing platform like MISP. 568 common-taxonomy: 569 The Common Taxonomy for Law Enforcement and The National Network 570 of CSIRTs bridges the gap between the CSIRTs and international Law 571 Enforcement communities by adding a legislative framework to 572 facilitate the harmonisation of incident reporting to competent 573 authorities, the development of useful statistics and sharing 574 information within the entire cybercrime ecosystem. 576 copine-scale: 577 The COPINE Scale is a rating system created in Ireland and used in 578 the United Kingdom to categorise the severity of images of child 579 sex abuse. 581 cryptocurrency-threat: 582 Threats targetting cryptocurrency, based on CipherTrace report. 584 csirt_case_classification: 585 FIRST CSIRT Case Classification. 587 cssa: 588 The CSSA agreed sharing taxonomy. 590 cyber-threat-framework: 591 Cyber Threat Framework was developed by the US Government to 592 enable consistent characterization and categorization of cyber 593 threat events, and to identify trends or changes in the activities 594 of cyber adversaries. 597 data-classification: 598 Data classification for data potentially at risk of exfiltration 599 based on table 2.1 of Solving Cyber Risk book. 601 dcso-sharing: 602 DCSO Sharing Taxonomy to classify certain types of MISP events 603 using the DCSO Event Guide 605 ddos: 607 Distributed Denial of Service - or short: DDoS - taxonomy supports 608 the description of Denial of Service attacks and especially the 609 types they belong too. 611 de-vs: 612 Taxonomy for the handling of protectively marked information in 613 MISP with German (DE) Government classification markings (VS) 615 dhs-ciip-sectors: 616 DHS critical sectors as described in . 619 diamond-model: 620 The Diamond Model for Intrusion Analysis, a phase-based model 621 developed by Lockheed Martin, aims to help categorise and identify 622 the stage of an attack. 624 dni-ism: 625 ISM (Information Security Marking Metadata) V13 as described by 626 DNI.gov (Director of National Intelligence - US). 628 domain-abuse: 629 Taxonomy to tag domain names used for cybercrime. 631 drugs: 632 A taxonomy based on the superclass and class of drugs, based on 633 635 economical-impact: 636 Economical impact is a taxonomy to describe the financial impact 637 as positive or negative gain to the tagged information. 639 ecsirt: 640 eCSIRT incident classification Appendix C of the eCSIRT EU project 641 including IntelMQ updates. 643 enisa: 644 ENISA Threat Taxonomy - A tool for structuring threat information 645 as published in 649 estimative-language: 650 Estimative language - including likelihood or probability of event 651 based on the Intelligence Community Directive 203 (ICD 203) 652 (6.2.(a)) and JP 2-0, Joint Intelligence. 654 eu-marketop-and-publicadmin: 656 Market operators and public administrations that must comply to 657 some notifications requirements under EU NIS directive. 659 eu-nis-sector-and-subsectors: 660 Sectors and sub sectors as identified by the NIS Directive. 662 euci: 663 EU classified information (EUCI) means any information or material 664 designated by a EU security classification, the unauthorised 665 disclosure of which could cause varying degrees of prejudice to 666 the interests of the European Union or of one or more of the 667 Member States as described in COUNCIL DECISION of 23 September 668 2013 on the security rules for protecting EU classified 669 information 671 europol-event: 672 EUROPOL type of events taxonomy. 674 europol-incident: 675 EUROPOL class of incident taxonomy. 677 event-assessment: 678 A series of assessment predicates describing the event assessment 679 performed to make judgement(s) under a certain level of 680 uncertainty. 682 event-classification: 683 Event Classification. 685 exercise: 686 Exercise is a taxonomy to describe if the information is part of 687 one or more cyber or crisis exercise. 689 false-positive: 690 This taxonomy aims to ballpark the expected amount of false 691 positives. 693 file-type: 694 List of known file types. 696 flesch-reading-ease: 697 Flesch Reading Ease is a revised system for determining the 698 comprehension difficulty of written material. The scoring of the 699 flesh score can have a maximum of 121.22 and there is no limit on 700 how low a score can be (negative score are valid). 702 fpf: 704 The Future of Privacy Forum (FPF) visual guide to practical de- 705 identification [1] taxonomy is used to evaluate the degree of 706 identifiability of personal data and the types of pseudonymous 707 data, de-identified data and anonymous data. The work of FPF is 708 licensed under a creative commons attribution 4.0 international 709 license. 711 fr-classif: 712 French gov information classification system. 714 gdpr: 715 Taxonomy related to the REGULATION (EU) 2016/679 OF THE EUROPEAN 716 PARLIAMENT AND OF THE COUNCIL on the protection of natural persons 717 with regard to the processing of personal data and on the free 718 movement of such data, and repealing Directive 95/46/EC (General 719 Data Protection Regulation) 721 gsma-attack-category: 722 Taxonomy used by GSMA for their information sharing program with 723 telco describing the attack categories 725 gsma-fraud: 726 Taxonomy used by GSMA for their information sharing program with 727 telco describing the various aspects of fraud 729 gsma-network-technology: 730 Taxonomy used by GSMA for their information sharing program with 731 telco describing the types of infrastructure. WiP 733 honeypot-basic: 734 Christian Seifert, Ian Welch, Peter Komisarczuk, 'Taxonomy of 735 Honeypots', Technical Report CS-TR-06/12, VICTORIA UNIVERSITY OF 736 WELLINGTON, School of Mathematical and Computing Sciences, June 737 2006, 740 iep: 741 Forum of Incident Response and Security Teams (FIRST) Information 742 Exchange Policy (IEP) framework. 744 ifx-vetting: 745 The IFX taxonomy is used to categorise information (MISP events 746 and attributes) to aid in the intelligence vetting process 748 incident-disposition: 749 How an incident is classified in its process to be resolved. The 750 taxonomy is inspired from NASA Incident Response and Management 751 Handbook. 753 infoleak: 754 A taxonomy describing information leaks and especially information 755 classified as being potentially leaked. 757 information-security-data-source: 758 Taxonomy to classify the information security data sources 760 information-security-indicators: 761 Information security indicators have been standardized by the ETSI 762 Industrial Specification Group (ISG) ISI. These indicators 763 provide the basis to switch from a qualitative to a quantitative 764 culture in IT Security Scope of measurements: External and 765 internal threats (attempt and success), user's deviant behaviours, 766 nonconformities and/or vulnerabilities (software, configuration, 767 behavioural, general security framework). ETSI GS ISI 001-1 768 (V1.1.2): ISI Indicators 770 interception-method: 771 The interception method used to intercept traffic. 773 kill-chain: 774 Cyber Kill Chain from Lockheed Martin as described in 775 Intelligence-Driven Computer Network Defense Informed by Analysis 776 of Adversary Campaigns and Intrusion Kill Chains. 778 maec-delivery-vectors: 779 Vectors used to deliver malware based on MAEC 5.0 781 maec-malware-behavior: 782 Malware behaviours based on MAEC 5.0 784 maec-malware-capabilities: 785 Malware Capabilities based on MAEC 5.0 787 maec-malware-obfuscation-methods: 788 Obfuscation methods used by malware based on MAEC 5.0 790 malware_classification: 791 Malware classification based on a SANS whitepaper about malware. 793 misp: 794 Internal MISP taxonomy. 796 monarc-threat: 797 MONARC threat taxonomy. 799 ms-caro-malware: 801 Malware Type and Platform classification based on Microsoft's 802 implementation of the Computer Antivirus Research Organization 803 (CARO) Naming Scheme and Malware Terminology. 805 ms-caro-malware-full: 806 Malware Type and Platform classification based on Microsoft's 807 implementation of the Computer Antivirus Research Organization 808 (CARO) Naming Scheme and Malware Terminology. 810 nato: 811 Marking of Classified and Unclassified materials as described by 812 the North Atlantic Treaty Organization, NATO. 814 nis: 815 NIS Cybersecurity Incident Taxonomy. 817 open_threat: 818 Open Threat Taxonomy v1.1 base on James Tarala of SANS ref. - 819 822 osint: 823 Open Source Intelligence - Classification (MISP taxonomies). 825 passivetotal: 826 Tags for RiskIQ's passivetotal service 828 pentest: 829 Penetration test (pentest) classification. 831 priority-level: 832 After an incident is scored, it is assigned a priority level. The 833 six levels listed below are aligned with NCCIC, DHS, and the CISS 834 to help provide a common lexicon when discussing incidents. This 835 priority assignment drives NCCIC urgency, pre-approved incident 836 response offerings, reporting requirements, and recommendations 837 for leadership escalation. Generally, incident priority 838 distribution should follow a similar pattern to the graph below. 839 Based on . 842 rsit: 843 Reference Security Incident Classification Taxonomy. 845 rt_event_status: 846 Status of events used in Request Tracker. 848 runtime-packer: 850 Runtime or software packer used to combine compressed data with 851 the decompression code. The decompression code can add additional 852 obfuscations mechanisms including polymorphic-packer or other 853 obfuscation techniques. This taxonomy lists all the known or 854 official packer used for legitimate use or for packing malicious 855 binaries. 857 smart-airports-threats: 858 Threat taxonomy in the scope of securing smart airports by ENISA. 860 stealth_malware: 861 Classification based on malware stealth techniques. 863 stix-ttp: 864 Representation of the behavior or modus operandi of cyber 865 adversaries (a.k.a TTP) as normalized in STIX 867 targeted-threat-index: 868 The Targeted Threat Index is a metric for assigning an overall 869 threat ranking score to email messages that deliver malware to a 870 victim's computer. The TTI metric was first introduced at SecTor 871 2013 by Seth Hardy as part of the talk "RATastrophe: Monitoring a 872 Malware Menagerie" along with Katie Kleemola and Greg Wiseman. 874 tlp: 875 The Traffic Light Protocol - or short: TLP - was designed with the 876 objective to create a favorable classification scheme for sharing 877 sensitive information while keeping the control over its 878 distribution at the same time. Extended with TLP:EX:CHR. 880 tor: 881 Taxonomy to describe Tor network infrastructure 883 type: 884 Taxonomy to describe different types of intelligence gathering 885 discipline which can be described the origin of intelligence. 887 use-case-applicability: 888 The Use Case Applicability categories reflect standard resolution 889 categories, to clearly display alerting rule configuration 890 problems. 892 veris: 893 Vocabulary for Event Recording and Incident Sharing (VERIS). 895 vocabulaire-des-probabilites-estimatives: 896 Vocabulaire des probabilites estimatives 898 workflow: 899 Workflow support language is a common language to support 900 intelligence analysts to perform their analysis on data and 901 information. 903 5. JSON Schema 905 The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP 906 taxonomy document as literally described before. The JSON Schema is 907 used validating a MISP taxonomy. The validation is a _MUST_ if the 908 taxonomy is included in the MISP taxonomies directory. 910 { 911 "$schema": "http://json-schema.org/schema#", 912 "title": "Validator for misp-taxonomies", 913 "id": "https://www.github.com/MISP/misp-taxonomies/schema.json", 914 "defs": { 915 "entry": { 916 "type": "array", 917 "uniqueItems": true, 918 "items": { 919 "type": "object", 920 "additionalProperties": false, 921 "properties": { 922 "numerical_value": { 923 "type": "number" 924 }, 925 "expanded": { 926 "type": "string" 927 }, 928 "description": { 929 "type": "string" 930 }, 931 "colour": { 932 "type": "string" 933 }, 934 "value": { 935 "type": "string" 936 }, 937 "required": [ 938 "value" 939 ] 940 } 941 } 942 }, 943 "values": { 944 "type": "array", 945 "uniqueItems": true, 946 "items": { 947 "type": "object", 948 "additionalProperties": false, 949 "properties": { 950 "entry": { 951 "$ref": "#/defs/entry" 952 }, 953 "predicate": { 954 "type": "string" 955 } 956 }, 957 "required": [ 958 "predicate" 959 ] 960 } 961 }, 962 "predicates": { 963 "type": "array", 964 "uniqueItems": true, 965 "items": { 966 "type": "object", 967 "additionalProperties": false, 968 "properties": { 969 "numerical_value": { 970 "type": "number" 971 }, 972 "colour": { 973 "type": "string" 974 }, 975 "description": { 976 "type": "string" 977 }, 978 "expanded": { 979 "type": "string" 980 }, 981 "value": { 982 "type": "string" 983 }, 984 "exclusive": { 985 "type": "boolean" 986 }, 987 "required": [ 988 "value" 989 ] 990 } 991 } 992 } 993 }, 994 "type": "object", 995 "additionalProperties": false, 996 "properties": { 997 "version": { 998 "type": "integer" 999 }, 1000 "description": { 1001 "type": "string" 1002 }, 1003 "expanded": { 1004 "type": "string" 1005 }, 1006 "namespace": { 1007 "type": "string" 1008 }, 1009 "exclusive": { 1010 "type": "boolean" 1011 }, 1012 "type": { 1013 "type": "array", 1014 "uniqueItems": true, 1015 "items": { 1016 "type": "string", 1017 "enum": [ 1018 "org", 1019 "user", 1020 "attribute", 1021 "event" 1022 ] 1023 } 1024 }, 1025 "refs": { 1026 "type": "array", 1027 "uniqueItems": true, 1028 "items": { 1029 "type": "string" 1030 } 1031 }, 1032 "predicates": { 1033 "$ref": "#/defs/predicates" 1034 }, 1035 "values": { 1036 "$ref": "#/defs/values" 1037 } 1038 }, 1039 "required": [ 1040 "namespace", 1041 "description", 1042 "version", 1043 "predicates" 1044 ] 1045 } 1047 6. Acknowledgements 1049 The authors wish to thank all the MISP community who are supporting 1050 the creation of open standards in threat intelligence sharing. 1052 7. References 1054 7.1. Normative References 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14, RFC 2119, 1058 DOI 10.17487/RFC2119, March 1997, 1059 . 1061 [RFC4627] Crockford, D., "The application/json Media Type for 1062 JavaScript Object Notation (JSON)", RFC 4627, 1063 DOI 10.17487/RFC4627, July 2006, 1064 . 1066 7.2. Informative References 1068 [JSON-SCHEMA] 1069 "JSON Schema: A Media Type for Describing JSON Documents", 1070 2016, 1071 . 1073 [machine-tags] 1074 "Machine tags", 2007, 1075 . 1078 [MISP-P] MISP, "MISP Project - Malware Information Sharing Platform 1079 and Threat Sharing", . 1081 [MISP-T] MISP, "MISP Taxonomies - shared and common vocabularies of 1082 tags", . 1084 7.3. URIs 1086 [1] https://fpf.org/2016/04/25/a-visual-guide-to-practical-data-de- 1087 identification/ 1089 Authors' Addresses 1091 Alexandre Dulaunoy 1092 Computer Incident Response Center Luxembourg 1093 16, bd d'Avranches 1094 Luxembourg L-1611 1095 Luxembourg 1097 Phone: +352 247 88444 1098 Email: alexandre.dulaunoy@circl.lu 1100 Andras Iklody 1101 Computer Incident Response Center Luxembourg 1102 16, bd d'Avranches 1103 Luxembourg L-1611 1104 Luxembourg 1106 Phone: +352 247 88444 1107 Email: andras.iklody@circl.lu