idnits 2.17.1 draft-dulaunoy-misp-taxonomy-format-06.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 (November 30, 2018) is 1975 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1041 ** 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: June 3, 2019 November 30, 2018 7 MISP taxonomy format 8 draft-dulaunoy-misp-taxonomy-format-06 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 June 3, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 73 7.2. Informative References . . . . . . . . . . . . . . . . . 22 74 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 decimal and 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 copine-scale: 569 The COPINE Scale is a rating system created in Ireland and used in 570 the United Kingdom to categorise the severity of images of child 571 sex abuse. 573 csirt_case_classification: 574 FIRST CSIRT Case Classification. 576 cssa: 577 The CSSA agreed sharing taxonomy. 579 cyber-threat-framework: 580 Cyber Threat Framework was developed by the US Government to 581 enable consistent characterization and categorization of cyber 582 threat events, and to identify trends or changes in the activities 583 of cyber adversaries. 586 ddos: 587 Distributed Denial of Service - or short: DDoS - taxonomy supports 588 the description of Denial of Service attacks and especially the 589 types they belong too. 591 de-vs: 592 Taxonomy for the handling of protectively marked information in 593 MISP with German (DE) Government classification markings (VS) 595 dhs-ciip-sectors: 596 DHS critical sectors as described in . 599 diamond-model: 600 The Diamond Model for Intrusion Analysis, a phase-based model 601 developed by Lockheed Martin, aims to help categorise and identify 602 the stage of an attack. 604 dni-ism: 605 ISM (Information Security Marking Metadata) V13 as described by 606 DNI.gov (Director of National Intelligence - US). 608 domain-abuse: 609 Taxonomy to tag domain names used for cybercrime. 611 economical-impact: 612 Economical impact is a taxonomy to describe the financial impact 613 as positive or negative gain to the tagged information. 615 ecsirt: 616 eCSIRT incident classification Appendix C of the eCSIRT EU project 617 including IntelMQ updates. 619 enisa: 620 ENISA Threat Taxonomy - A tool for structuring threat information 621 as published in 625 estimative-language: 626 Estimative language - including likelihood or probability of event 627 based on the Intelligence Community Directive 203 (ICD 203) 628 (6.2.(a)) and JP 2-0, Joint Intelligence. 630 eu-marketop-and-publicadmin: 631 Market operators and public administrations that must comply to 632 some notifications requirements under EU NIS directive. 634 eu-nis-sector-and-subsectors: 635 Sectors and sub sectors as identified by the NIS Directive. 637 euci: 638 EU classified information (EUCI) means any information or material 639 designated by a EU security classification, the unauthorised 640 disclosure of which could cause varying degrees of prejudice to 641 the interests of the European Union or of one or more of the 642 Member States as described in CELEX 32013D0488 644 europol-event: 645 EUROPOL type of events taxonomy. 647 europol-incident: 648 EUROPOL class of incident taxonomy. 650 event-assessment: 651 A series of assessment predicates describing the event assessment 652 performed to make judgement(s) under a certain level of 653 uncertainty. 655 event-classification: 657 Event Classification. 659 exercise: 660 Exercise is a taxonomy to describe if the information is part of 661 one or more cyber or crisis exercise 663 false-positive: 664 This taxonomy aims to ballpark the expected amount of false 665 positives. 667 file-type: 668 List of known file types. 670 fpf: 671 The Future of Privacy Forum (FPF) visual guide to practical de- 672 identification [1] taxonomy is used to evaluate the degree of 673 identifiability of personal data and the types of pseudonymous 674 data, de-identified data and anonymous data. The work of FPF is 675 licensed under a creative commons attribution 4.0 international 676 license. 678 fr-classif: 679 French gov information classification system. 681 gdpr: 682 Taxonomy related to the REGULATION (EU) 2016/679 OF THE EUROPEAN 683 PARLIAMENT AND OF THE COUNCIL on the protection of natural persons 684 with regard to the processing of personal data and on the free 685 movement of such data, and repealing Directive 95/46/EC (General 686 Data Protection Regulation) 688 gsma-attack-category: 689 Taxonomy used by GSMA for their information sharing program with 690 telco describing the attack categories 692 gsma-fraud: 693 Taxonomy used by GSMA for their information sharing program with 694 telco describing the various aspects of fraud 696 gsma-network-technology: 697 Taxonomy used by GSMA for their information sharing program with 698 telco describing the types of infrastructure. WiP 700 honeypot-basic: 701 Christian Seifert, Ian Welch, Peter Komisarczuk, 'Taxonomy of 702 Honeypots', Technical Report CS-TR-06/12, VICTORIA UNIVERSITY OF 703 WELLINGTON, School of Mathematical and Computing Sciences, June 704 2006, 707 iep: 708 Forum of Incident Response and Security Teams (FIRST) Information 709 Exchange Policy (IEP) framework. 711 ifx-vetting: 712 The IFX taxonomy is used to categorise information (MISP events 713 and attributes) to aid in the intelligence vetting process 715 incident-disposition: 716 How an incident is classified in its process to be resolved. The 717 taxonomy is inspired from NASA Incident Response and Management 718 Handbook. 720 infoleak: 721 A taxonomy describing information leaks and especially information 722 classified as being potentially leaked. 724 information-security-indicators: 725 Information security indicators have been standardized by the ETSI 726 Industrial Specification Group (ISG) ISI. These indicators 727 provide the basis to switch from a qualitative to a quantitative 728 culture in IT Security Scope of measurements: External and 729 internal threats (attempt and success), user's deviant behaviours, 730 nonconformities and/or vulnerabilities (software, configuration, 731 behavioural, general security framework). ETSI GS ISI 001-1 732 (V1.1.2): ISI Indicators 734 interception-method: 735 The interception method used to intercept traffic. 737 kill-chain: 738 Cyber Kill Chain from Lockheed Martin as described in 739 Intelligence-Driven Computer Network Defense Informed by Analysis 740 of Adversary Campaigns and Intrusion Kill Chains. 742 maec-delivery-vectors: 743 Vectors used to deliver malware based on MAEC 5.0 745 maec-malware-behavior: 746 Malware behaviours based on MAEC 5.0 748 maec-malware-capabilities: 749 Malware Capabilities based on MAEC 5.0 751 maec-malware-obfuscation-methods: 753 Obfuscation methods used by malware based on MAEC 5.0 755 malware_classification: 756 Malware classification based on a SANS whitepaper about malware. 758 misp: 759 Internal MISP taxonomy. 761 monarc-threat: 762 MONARC threat taxonomy. 764 ms-caro-malware: 765 Malware Type and Platform classification based on Microsoft's 766 implementation of the Computer Antivirus Research Organization 767 (CARO) Naming Scheme and Malware Terminology. 769 ms-caro-malware-full: 770 Malware Type and Platform classification based on Microsoft's 771 implementation of the Computer Antivirus Research Organization 772 (CARO) Naming Scheme and Malware Terminology. 774 nato: 775 Marking of Classified and Unclassified materials as described by 776 the North Atlantic Treaty Organization, NATO. 778 nis: 779 NIS Cybersecurity Incident Taxonomy. 781 open_threat: 782 Open Threat Taxonomy v1.1 base on James Tarala of SANS ref. - 783 786 osint: 787 Open Source Intelligence - Classification (MISP taxonomies). 789 passivetotal: 790 Tags for RiskIQ's passivetotal service 792 pentest: 793 Penetration test (pentest) classification. 795 priority-level: 796 After an incident is scored, it is assigned a priority level. The 797 six levels listed below are aligned with NCCIC, DHS, and the CISS 798 to help provide a common lexicon when discussing incidents. This 799 priority assignment drives NCCIC urgency, pre-approved incident 800 response offerings, reporting requirements, and recommendations 801 for leadership escalation. Generally, incident priority 802 distribution should follow a similar pattern to the graph below. 803 Based on . 806 rsit: 807 Reference Security Incident Classification Taxonomy. 809 rt_event_status: 810 Status of events used in Request Tracker. 812 runtime-packer: 813 Runtime or software packer used to combine compressed data with 814 the decompression code. The decompression code can add additional 815 obfuscations mechanisms including polymorphic-packer or other 816 obfuscation techniques. This taxonomy lists all the known or 817 official packer used for legitimate use or for packing malicious 818 binaries. 820 smart-airports-threats: 821 Threat taxonomy in the scope of securing smart airports by ENISA. 823 stealth_malware: 824 Classification based on malware stealth techniques. 826 stix-ttp: 827 Representation of the behavior or modus operandi of cyber 828 adversaries (a.k.a TTP) as normalized in STIX 830 targeted-threat-index: 831 The Targeted Threat Index is a metric for assigning an overall 832 threat ranking score to email messages that deliver malware to a 833 victim's computer. The TTI metric was first introduced at SecTor 834 2013 by Seth Hardy as part of the talk "RATastrophe: Monitoring a 835 Malware Menagerie" along with Katie Kleemola and Greg Wiseman. 837 tlp: 838 The Traffic Light Protocol - or short: TLP - was designed with the 839 objective to create a favorable classification scheme for sharing 840 sensitive information while keeping the control over its 841 distribution at the same time. Extended with TLP:EX:CHR. 843 tor: 844 Taxonomy to describe Tor network infrastructure 846 veris: 847 Vocabulary for Event Recording and Incident Sharing (VERIS). 849 vocabulaire-des-probabilites-estimatives: 850 Vocabulaire des probabilites estimatives 852 workflow: 853 Workflow support language is a common language to support 854 intelligence analysts to perform their analysis on data and 855 information. 857 5. JSON Schema 859 The JSON Schema [JSON-SCHEMA] below defines the structure of the MISP 860 taxonomy document as literally described before. The JSON Schema is 861 used validating a MISP taxonomy. The validation is a _MUST_ if the 862 taxonomy is included in the MISP taxonomies directory. 864 { 865 "$schema": "http://json-schema.org/schema#", 866 "title": "Validator for misp-taxonomies", 867 "id": "https://www.github.com/MISP/misp-taxonomies/schema.json", 868 "defs": { 869 "entry": { 870 "type": "array", 871 "uniqueItems": true, 872 "items": { 873 "type": "object", 874 "additionalProperties": false, 875 "properties": { 876 "numerical_value": { 877 "type": "number" 878 }, 879 "expanded": { 880 "type": "string" 881 }, 882 "description": { 883 "type": "string" 884 }, 885 "colour": { 886 "type": "string" 887 }, 888 "value": { 889 "type": "string" 890 }, 891 "required": [ 892 "value" 893 ] 894 } 895 } 896 }, 897 "values": { 898 "type": "array", 899 "uniqueItems": true, 900 "items": { 901 "type": "object", 902 "additionalProperties": false, 903 "properties": { 904 "entry": { 905 "$ref": "#/defs/entry" 906 }, 907 "predicate": { 908 "type": "string" 909 } 910 }, 911 "required": [ 912 "predicate" 913 ] 914 } 915 }, 916 "predicates": { 917 "type": "array", 918 "uniqueItems": true, 919 "items": { 920 "type": "object", 921 "additionalProperties": false, 922 "properties": { 923 "numerical_value": { 924 "type": "number" 925 }, 926 "colour": { 927 "type": "string" 928 }, 929 "description": { 930 "type": "string" 931 }, 932 "expanded": { 933 "type": "string" 934 }, 935 "value": { 936 "type": "string" 937 }, 938 "exclusive": { 939 "type": "boolean" 940 }, 941 "required": [ 942 "value" 943 ] 944 } 946 } 947 } 948 }, 949 "type": "object", 950 "additionalProperties": false, 951 "properties": { 952 "version": { 953 "type": "integer" 954 }, 955 "description": { 956 "type": "string" 957 }, 958 "expanded": { 959 "type": "string" 960 }, 961 "namespace": { 962 "type": "string" 963 }, 964 "exclusive": { 965 "type": "boolean" 966 }, 967 "type": { 968 "type": "array", 969 "uniqueItems": true, 970 "items": { 971 "type": "string", 972 "enum": [ 973 "org", 974 "user", 975 "attribute", 976 "event" 977 ] 978 } 979 }, 980 "refs": { 981 "type": "array", 982 "uniqueItems": true, 983 "items": { 984 "type": "string" 985 } 986 }, 987 "predicates": { 988 "$ref": "#/defs/predicates" 989 }, 990 "values": { 991 "$ref": "#/defs/values" 992 } 993 }, 994 "required": [ 995 "namespace", 996 "description", 997 "version", 998 "predicates" 999 ] 1000 } 1002 6. Acknowledgements 1004 The authors wish to thank all the MISP community who are supporting 1005 the creation of open standards in threat intelligence sharing. 1007 7. References 1009 7.1. Normative References 1011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1012 Requirement Levels", BCP 14, RFC 2119, 1013 DOI 10.17487/RFC2119, March 1997, 1014 . 1016 [RFC4627] Crockford, D., "The application/json Media Type for 1017 JavaScript Object Notation (JSON)", RFC 4627, 1018 DOI 10.17487/RFC4627, July 2006, 1019 . 1021 7.2. Informative References 1023 [JSON-SCHEMA] 1024 "JSON Schema: A Media Type for Describing JSON Documents", 1025 2016, 1026 . 1028 [machine-tags] 1029 "Machine tags", 2007, 1030 . 1033 [MISP-P] MISP, "MISP Project - Malware Information Sharing Platform 1034 and Threat Sharing", . 1036 [MISP-T] MISP, "MISP Taxonomies - shared and common vocabularies of 1037 tags", . 1039 7.3. URIs 1041 [1] https://fpf.org/2016/04/25/a-visual-guide-to-practical-data-de- 1042 identification/ 1044 Authors' Addresses 1046 Alexandre Dulaunoy 1047 Computer Incident Response Center Luxembourg 1048 16, bd d'Avranches 1049 Luxembourg L-1611 1050 Luxembourg 1052 Phone: +352 247 88444 1053 Email: alexandre.dulaunoy@circl.lu 1055 Andras Iklody 1056 Computer Incident Response Center Luxembourg 1057 16, bd d'Avranches 1058 Luxembourg L-1611 1059 Luxembourg 1061 Phone: +352 247 88444 1062 Email: andras.iklody@circl.lu