idnits 2.17.1 draft-ietf-mile-iodef-guidance-10.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 28 instances of too long lines in the document, the longest one being 53 characters in excess of 72. ** The abstract seems to contain references ([RFC7970]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 22, 2017) is 2503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group P. Kampanakis 3 Internet-Draft Cisco Systems 4 Intended status: Informational M. Suzuki 5 Expires: November 23, 2017 NICT 6 May 22, 2017 8 IODEF Usage Guidance 9 draft-ietf-mile-iodef-guidance-10 11 Abstract 13 The Incident Object Description Exchange Format v2 [RFC7970] defines 14 a data representation that provides a framework for sharing 15 information commonly exchanged by Computer Security Incident Response 16 Teams (CSIRTs) about computer security incidents. Since the IODEF 17 model includes a wealth of available options that can be used to 18 describe a security incident or issue, it can be challenging for 19 security practitioners to develop tools that can leverage IODEF for 20 incident sharing. This document provides guidelines for IODEF 21 implementers. It also addresses how common security indicators can 22 be represented in IODEF and use-cases of how IODEF is being used. 23 This document aims to make IODEF's adoption by vendors easier and 24 encourage faster and wider adoption of the model by Computer Security 25 Incident Response Teams (CSIRTs) around the world. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 23, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Implementation and Use Strategy . . . . . . . . . . . . . . . 3 64 3.1. Minimal IODEF document . . . . . . . . . . . . . . . . . 4 65 3.2. Information represented . . . . . . . . . . . . . . . . . 4 66 3.3. IODEF Classes . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. External References . . . . . . . . . . . . . . . . . . . 6 69 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Indicator predicate logic . . . . . . . . . . . . . . . . 7 71 4.4. Disclosure level . . . . . . . . . . . . . . . . . . . . 7 72 5. IODEF Uses . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Implementations . . . . . . . . . . . . . . . . . . . . . 8 74 5.2. Inter-vendor and Service Provider Exercise . . . . . . . 8 75 5.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 8.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Appendix A. Indicator predicate logic examples . . . . . . . . . 15 82 Appendix B. Inter-vendor and Service Provider Exercise Examples 18 83 B.1. Malware Delivery URL . . . . . . . . . . . . . . . . . . 18 84 B.2. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 B.3. Spear-Phishing . . . . . . . . . . . . . . . . . . . . . 22 86 B.4. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 B.5. IoT Malware . . . . . . . . . . . . . . . . . . . . . . . 32 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 90 1. Introduction 92 The Incident Object Description Exchange Format v2 [RFC7970] defines 93 a data representation that provides a framework for sharing 94 information commonly exchanged by Computer Security Incident Response 95 Teams (CSIRTs) about computer security incidents. The IODEF data 96 model consists of multiple classes and data types that are defined in 97 the IODEF XML schema. 99 The IODEF schema was designed to be able to describe all the possible 100 fields that would be needed in a security incident exchange. Thus, 101 IODEF contains a plethora of data constructs that could potentially 102 make it harder for IODEF implementers to decide which are important. 103 Additionally, in the IODEF schema, there exist multiple fields and 104 classes which do not necessarily need to be used in every possible 105 data exchange. Moreover, some IODEF classes are useful only in rare 106 circumstances. This document tries to address how to avoid these 107 concerns. It also addresses how common security indicators can be 108 represented in IODEF. It points out the most important IODEF classes 109 for an implementer and describe other ones that are not as important. 110 Also, it presents some common challenges for IODEF implementers and 111 how to address them. The end goal of this document is to make 112 IODEF's use by vendors easier and encourage wider adoption of the 113 model by CSIRTs around the world. 115 Section 3 discusses the recommended classes and how an IODEF 116 implementer should chose the classes to implement. Section 4 117 presents common considerations a practitioner will come across and 118 how to address them. Section 5 goes over some common uses of IODEF. 120 2. Terminology 122 The terminology used in this document follows the one defined in 123 [RFC7970] and [RFC7203]. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Implementation and Use Strategy 131 It is important for IODEF implementers to be able to distinguish how 132 the IODEF classes will be used in incident information exchanges. To 133 do that one has to follow a strategy according to which of the 134 various IODEF classes will be implemented. It is also important to 135 know the most common classes that will be used to describe common 136 security incidents or indicators. Thus, this section describes the 137 most important classes and factors an IODEF practitioner should take 138 into consideration before using IODEF, or designing an 139 implementation. 141 3.1. Minimal IODEF document 143 IODEF includes one mandatory classes. An IODEF document MUST include 144 at least an Incident class, an xml:lang attribute that defines the 145 supported language an the IODEF version attribute. An Incident MUST 146 contain three minimal mandatory-to-implement classes. An Incident 147 class needs to have a Generation time and IncidentID class and at 148 least one Contact class. The structure of the minimal-style Incident 149 class follows below. 151 +-------------------------+ 152 | Incident | 153 +-------------------------+ 154 | ENUM purpose |<>----------[ IncidentID ] 155 | |<>----------[ GenerationTime ] 156 | |<>--{1..*}--[ Contact ] 157 +-------------------------+ 159 Minimal-style Incident class 161 The minimal Incident class needs to include a purpose attribute and 162 the IncidentID, GenerationTime, and Contact elements. 164 The Contact class requires the type and role attributes, but no 165 elements are required by the IODEF v2 specification. Nevertheless, 166 at least one of the elements in the Contact class, such as Email 167 class, SHOULD be implemented so that the IODEF document can be 168 practical. 170 Implementers can refer to Appendix B and Section 7 of [RFC7970] for 171 example IODEF v2 documents. 173 3.2. Information represented 175 There is no need for a practitioner to use or implement IODEF classes 176 and fields other than the minimal ones (Section 3.1) and the ones 177 that are necessary for her use-cases. The implementer should 178 carefully look into the schema and decide classes to implement (or 179 not). 181 For example, if we have Distributed Denial of Service (DDoS) as a 182 potential use-case, then the Flow class and its included information 183 are the most important classes to use. The Flow class describes 184 information related to the attacker hosts and victim hosts, which 185 information could help automated filtering or sink-hole operations. 187 Another potential use-case is malware command and control (c2). 188 After modern malware infects a device, it usually proceeds to connect 189 to one or more c2 servers to receive instructions from its master and 190 potentially exfiltrate information. To protect against such 191 activity, it is important to interrupt the c2 communication by 192 filtering the activity. IODEF can describe c2 activities using the 193 Flow and the ServiceName classes. 195 For use-cases where indicators need to be described, the 196 IndicatorData class its classes will be implemented instead of the 197 EventData class. 199 In summary, an implementer SHOULD identify her use-cases and find the 200 classes that are necessary to support in IODEF v2. Implementing and 201 parsing all IODEF classes can be cumbersome in some occasions and is 202 not always necessary. Other external schemata can also be used in 203 IODEF to describe incidents or indicators which should be treated 204 accordingly only if the implementer's IODEF use-cases require 205 external schema support. 207 IODEF supports multiple translations of free-form text in all 208 ML_STRING classes [RFC7970]. That way text can be translated to 209 different languages by using the same translation identifier in the 210 class. Implementers SHOULD be able to parse iodef:MLStringType 211 classes and extract only the information relavant to the language/s 212 of interest. 214 3.3. IODEF Classes 216 [RFC7970] contains classes that can describe attack Methods, Events, 217 Incidents, how they were discovered and the Assessment of the 218 repercussions of the incident to the victim. It is important for 219 IODEF users to know the distinction between these classes in order to 220 decide which ones fulfill their use-cases. 222 An IndicatorData class depicts a threat indicator or observable that 223 could be used to describe a threat that does not necessarily mean 224 that an successful attack happened. For example, we could see an 225 attack happening but it might have been prevented and not have 226 resulted in an incident or security event. On the other hand an 227 EventData class usually describes a security event and can be 228 considered as an incident report of something that took place. 230 Classes like Discovery, Assessment, Method, and RecoveryTime are used 231 in conjuction with EventData as they related to the incident report 232 described in the EventData. The RelatedActivity class can reference 233 an incident, an indicator or other related threat activity. 235 While deciding what classes are important for the needed use-cases, 236 IODEF users SHOULD carefully evaluate the necessary classes and how 237 these are used in order to avoid unnecessary work. For example, if 238 we want to only describe indicators in IODEF, the implementation of 239 Method or Assessment might not be important. 241 4. Considerations 243 Implementers need to consider some common, standardized options for 244 their IODEF use strategy. 246 4.1. External References 248 The IODEF format includes the Reference class that refers to 249 externally defined information such as a vulnerability, Intrusion 250 Detection System (IDS) alert, malware sample, advisory, or attack 251 technique. To facilitate the exchange of information, the Reference 252 class was extended to the Enumeration Reference Format [RFC7495]. 253 The Enumeration Reference Format specifies a means to use external 254 enumeration specifications (e.g. CVE) that could define an 255 enumeration format, specific enumeration values, or both. As 256 external enumerations can cary greatly, implementers SHOULD only 257 support external enumerations that are expected to describe their 258 specific use-cases. 260 4.2. Extensions 262 The IODEF data model ([RFC7970]) is extensible. Many attributes with 263 enumerated values can be extended using the "ext-*" prefix. 264 Additional classes can also be defined by using the AdditionalData 265 and RecordItem classes. An extension to the AdditionalData class for 266 reporting Phishing emails is defined in [RFC5901]. Information about 267 extending IODEF class attributes and enumerated values can be found 268 in Section 5 of [RFC7970]. 270 Additionally, IODEF can import existing schemata by using an 271 extension framework defined in [RFC7203]. The framework enables 272 IODEF users to embed XML data inside an IODEF document using external 273 schemata or structures defined by external specifications. Examples 274 include CVE, CVRF and OVAL. Thus, [RFC7203] enhances the IODEF 275 capabilities without further extending the data model. 277 IODEF implementers SHOULD NOT consider using their own IODEF 278 extensions unless data cannot be represented using existing standards 279 or importing them in an IODEF document using [RFC7203] is not a 280 suitable option. 282 4.3. Indicator predicate logic 284 An IODEF [RFC7970] document can describe incident reports and 285 indicators. The Indicator class can include references to other 286 indicators, observables and more classes the contain details about 287 the indicator. When describing security indicators, it is often 288 common to need to group them together in order to form a group of 289 indicators that constitute a security threat. For example, a botnet 290 might have multiple command and control servers. For that reason, 291 IODEF v2 introduced the IndicatorExpression class that is used to add 292 the indicator predicate logic when grouping more than one indicator 293 or observable. 295 Implementations MUST be able to parse and apply the Boolean logic 296 offered by an IndicatorExpression in order to evaluate the existence 297 of an indicator. As explained in Section 3.29.5 of [RFC7970] the 298 IndicatorExpression element operator defines the operator applied to 299 all the child element of the IndicatorExpression. If no operator is 300 defined "and" SHOULD be assumed. IndicatorExpressions can also be 301 nested together. Child IndicatorExpressions should be treated as 302 child elements of their parent and they SHOULD be evaluated first 303 before evaluated with the operator of their parent. 305 Users can refer to Appendix A for example uses of the 306 IndicatorExpressions in an IODEF v2. 308 4.4. Disclosure level 310 The information conveyed in IODEF documents SHOULD be treated 311 carefully since the content may be confidential. IODEF has a common 312 attribute, called "restriction", which indicates the disclosure 313 guideline to which the sender expects the recipient to adhere to for 314 the information represented in the class and its children. That way, 315 the sender can express the level of disclosure for each component of 316 an IODEF document. Appropriate external measures could be 317 implemented based on the restriction level. One example is when 318 Real-time Inter-network Defense (RID) [RFC6545] is used to transfer 319 the IODEF documents, it can provide policy guidelines for handling 320 IODEF documents by using the RIDPolicy class. 322 The enforcement of the disclosure guidelines is out of scope for 323 IODEF. The recipient of the IODEF document needs to follow the 324 guidelines, but these guidelines themselves do not provide any 325 enforcement measures. For that purpose, implementers SHOULD consider 326 appropriate measures, technical or operational. 328 5. IODEF Uses 330 IODEF is currently used by various organizations in order to 331 represent security incidents and share incident and threat 332 information between security operations organizations. 334 5.1. Implementations 336 In order to use IODEF, tools like IODEF parsers are necessary. 337 [I-D.ietf-mile-implementreport] describes a set of IODEF 338 implementations and uses by various vendors and Computer Security 339 Incident Response Teams (CERT) organizations. The document does not 340 specify any specific mandatory to implement (MTI) IODEF classes but 341 provides a list of real world uses. Perl and Python modules 342 (XML::IODEF, Iodef::Pb, iodeflib) are some examples. Section 7 also 343 includes practical IODEF use guidelines. Implementers are encouraged 344 to refer to [I-D.ietf-mile-implementreport]. [implementations], on 345 the other hand, includes various vendor incident reporting products 346 that can consume and export in IODEF format. 348 5.2. Inter-vendor and Service Provider Exercise 350 As an interoperability excercise, in 2013 a limited number of vendors 351 organized and executed threat indicators exchanges in IODEF. The 352 transport protocol used was RID. The threat information shared 353 included indicators from DDoS attacks; and Malware and Spear-Phishing 354 incidents. The results served as proof-of-concept (PoC) about how 355 seemingly compteting entities could use IODEF to exchange sanitized 356 security information.As this was a PoC exercise only example 357 information (no real threats) were shared as part of the exchanges. 359 ____________ ____________ 360 | Vendor X | | Vendor Y | 361 | RID Agent |_______-------------________| RID Agent | 362 |___________| | Internet | |___________| 363 ------------- 365 ---- RID Report message ---> 366 -- carrying IODEF example -> 367 --------- over TLS --------> 369 <----- RID Ack message ----- 370 <--- in case of failure ---- 372 PoC peering topology 374 The figure above shows how RID interactions took place during the 375 PoC. Participating organizations were running RID Agent software on- 376 premises. The RID Agents formed peering relationships with other 377 participating organizations. When Entity X had a new incident to 378 exchange it would package it in IODEF and send it to Entity Y over 379 TLS in a RID Report message. In case there was an issue with the 380 message, Entity Y would send an RID Acknowledgement message back to 381 Entity X which included an application level message to describe the 382 issue. Interoperability between RID agents and the standards, Use of 383 [RFC6545] and [RFC6546], were also proven in this exercise. 385 The first use-case included sharing of Malware Data Related to an 386 Incident between CSIRTs. After Entity X detected an incident, she 387 would put data about malware found during the incident in a backend 388 system. Entity X then decided to share the incident information with 389 Entity Y about the malware discovered. This could be a human 390 decision or part of an automated process. 392 Below are the steps followed for the malware information exchange 393 that was taking place: 395 (1) Entity X has a sharing agreement with Entity Y, and has already 396 been configured with the IP address of Entity Y's RID Agent 398 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 399 mutual authentication occurs using PKI certificates. 401 (3) Entity X pushes out a RID Report message which contains 402 information about N pieces of discovered malware. IODEF is used 403 in RID to describe the 405 (a) Hash of malware files 407 (b) Registry settings changed by the malware 409 (c) C&C Information for the malware 411 (4) Entity Y receives RID Report message, sends RID Acknowledgement 412 message 414 (5) Entity Y stores the data in a format that makes it possible for 415 the back end to know which source the data came from. 417 Another use-case was sharing a DDoS attack as explained in the 418 following scenario: Entity X, a Critical Infrastructure and Key 419 Resource (CIKR) company detects that their internet connection is 420 saturated with an abnormal amount of traffic. Further investigation 421 determines that this is an actual DDoS attack. Entity X's CSIT 422 contacts their ISP, Entity Y, and shares information with them about 423 the attack traffic characteristics. Entity X's ISP is being 424 overwhelmed by the amount of traffic, so it shares attack signatures 425 and IP addresses of the most prolific hosts with its adjacent ISPs. 427 Below are the steps followed for a DDoS information exchange: 429 (1) Entity X has a sharing agreement with Entity Y, and has already 430 been configured with the IP address of Entity Y's RID Agent 432 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 433 mutual authentication occurs using PKI certificates. 435 (3) Entity X pushes out a RID Report message which contains 436 information about the DDoS attack. IODEF is used in RID to 437 describe the 439 (a) Start and Detect dates and times 441 (b) IP Addresses of nodes sending DDoS Traffic 443 (c) Sharing and Use Restrictions 445 (d) Traffic characteristics (protocols and ports) 447 (e) HTTP User-Agents used 449 (f) IP Addresses of C&C for a botnet 451 (4) Entity Y receives RID Report message, sends RID Acknowledgement 452 message 454 (5) Entity Y stores the data in a format that makes it possible for 455 the back end to know which source the data came from. 457 (6) Entity Y shares information with other ISP Entities it has an 458 established relationship with. 460 One more use-case was sharing spear-phishing email information as 461 explained in the following scenario: The board members of several 462 defense contractors receive an email inviting them to attend a 463 conference in San Francisco. The board members are asked to provide 464 their personally identifiable information such as their home address, 465 phone number, corporate email, etc in an attached document which came 466 with the email. The board members are also asked to click on a URL 467 which would allow them to reach the sign up page for the conference. 468 One of the recipients believes the email to be a phishing attempt and 469 forwards the email to their corporate CSIRT for analysis. The CSIRT 470 identifies the email as an attempted spear phishing incident and 471 distributes the indicators to their sharing partners. 473 Below are the steps followed for a spear-phishing information 474 exchange between CSIRTs that was part of this PoC. 476 (1) Entity X has a sharing agreement with Entity Y, and has already 477 been configured with the IP address of Entity Y's RID Agent 479 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 480 mutual authentication occurs using PKI certificates. 482 (3) Entity X pushes out a RID Report message which contains 483 information about the spear-phishing email. IODEF is used in 484 RID to describe the 486 (a) Attachment details (file Name, hash, size, malware family 488 (b) Target description (IP, domain, NSLookup) 490 (c) Email information (From, Subject, header information, date/ 491 time, digital signature) 493 (d) Confidence Score 495 (4) Entity Y receives RID Report message, sends RID Acknowledgement 496 message 498 (5) Entity Y stores the data in a format that makes it possible for 499 the back end to know which source the data came from. 501 Appendix B includes some of the incident IODEF example information 502 that was exchanged by the organizations' RID Agents as part of this 503 proof-of-concept. 505 5.3. Use-cases 507 Other use-cases of IODEF, other than the ones described above, could 508 be: 510 (1) ISP notifying a national CERT or organization when it identifies 511 and acts upon an incident and CERTs notifying ISPs when they are 512 aware of incidents. 514 (2) Suspected phishing emails could be shared amongst organizations 515 and national agencies. Automation could validate web content 516 that the suspicious emails are pointing to. Identified 517 malicious content linked in a phishing email could then be 518 shared using IODEF. Phishing campaigns could thus be subverted 519 much faster by automating information sharing using IODEF. 521 (3) When finding a certificate that should be revoked, a third-party 522 would forward an automated IODEF message to the CA with the full 523 context of the certificate and the CA could act accordingly 524 after checking its validity. Alternatively, in the event of a 525 compromise of the private key of a certificate, a third-party 526 could alert the certificate owner about the compromise using 527 IODEF. 529 6. Security Considerations 531 This document does not incur any new security issues, since it only 532 talks about the usage of IODEFv2 defined RFC7970. Nevertheless, 533 readers of this document SHOULD refer to the Security Considerations 534 section of [RFC7970]. 536 7. Updates 538 [ EDNOTE: To delete during last call. ] 540 version -10 updates: 542 (1) Fixed nits identified by Adam M. 544 (2) Added paragraph about language support in ML_STRING classes. 546 version -09 updates: 548 (1) Made changes according to suggestions in IETF-98. 550 version -08 updates: 552 (1) Updated Appendix IODEFv2 examples. 554 (2) Moved Predicate logic examples in appendix. 556 (3) Syntax and grammar fixes, clarifications, wording. 558 (4) Reorganized IODEF uses section and subsections. 560 version -07 updates: 562 (1) Updated examples in Appendix A to follow IODEFv2. 564 version -06 updates: 566 (1) Updated wording in various sections to make content clearer. 568 (2) Updated Predicate Logic section to reflect the latest 569 IndicatorExpression logic in iodef-bis. 571 (3) Updated section to describe the difference between events and 572 indicators and their use in IODEF v2. 574 version -05 updates: 576 (1) Changed section title from "Restrictions in IODEF" to 577 "Disclosure level of IODEF" and added some description 579 (2) Mixed "Recommended classes to implement" section with 580 "Unnecessary Fields" section into "Minimal IODEF document" 581 section 583 (3) Added description to "Decide what IODEF will be used for" 584 section, "Implementations" section, and "Security 585 Considerations" section 587 version -04 updates: 589 (1) Expanded on the Extensions section using Take's suggestion. 591 (2) Moved Future use-cases under the Other section. 593 (3) CIF and APWG were consolidated in one "Implementation" section 595 (4) Added abstract of RFC7495 to the "External References" section 597 (5) Added Kathleen's example of malware delivery URL to "Appendix" 599 (6) Added a little description to "Recommended classes to implement" 600 section 602 version -03 updates: 604 (1) Added "Updates" section. 606 (2) Added details about the flow of information exchanges in "Inter- 607 vendor and Service Provider Exercise" section. Also updated the 608 usecases with more background information. 610 (3) Added future use-cases in the "Collective Intelligence 611 Framework" section 613 (4) Updated Perl and Python references with the actual module names. 614 Added IODEF implementation reference "implementations". 616 (5) Added Predicate logic section 618 (6) Updated Logic of watchlist of indicators section to simplify the 619 logic and include examples. 621 (7) Renamed externally defined indicators section to Indicator 622 reference and elaborated on the use of indicator-uid and 623 indicator-set-uid attribute use. 625 version -02 updates: 627 (1) Updated the "Logic for watchlist of indications" section to 628 clarify the logic based on community feedback. 630 (2) Added "Inter-vendor and Service Provider Exercise" section. 632 (3) Added Appendix to include actual use-case IODEF examples. 634 8. References 636 8.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document 644 Class for Reporting Phishing", RFC 5901, 645 DOI 10.17487/RFC5901, July 2010, 646 . 648 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 649 RFC 6545, DOI 10.17487/RFC6545, April 2012, 650 . 652 [RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An 653 Incident Object Description Exchange Format (IODEF) 654 Extension for Structured Cybersecurity Information", 655 RFC 7203, DOI 10.17487/RFC7203, April 2014, 656 . 658 [RFC7495] Montville, A. and D. Black, "Enumeration Reference Format 659 for the Incident Object Description Exchange Format 660 (IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015, 661 . 663 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 664 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 665 November 2016, . 667 8.2. Informative References 669 [I-D.ietf-mile-implementreport] 670 Inacio, C. and D. Miyamoto, "MILE Implementation Report", 671 draft-ietf-mile-implementreport-10 (work in progress), 672 November 2016. 674 [implementations] 675 "Implementations on IODEF", 676 . 678 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 679 Defense (RID) Messages over HTTP/TLS", RFC 6546, 680 DOI 10.17487/RFC6546, April 2012, 681 . 683 Appendix A. Indicator predicate logic examples 685 In the following example the EventData class evaluates as a Flow of 686 one System with source address being (10.10.10.104 OR 10.10.10.106) 687 AND target address 10.1.1.1. 689 690 691 692 693 G90823490 694 695 C2 domains 696 697 698 699 700 701
702 10.10.10.104 703
704
705
706
707 708 709 710
711 10.10.10.106 712
713
714
715
716
717 718 719 720
721 10.1.1.1 722
723
724
725
726
727
728
729 731 Similarly, the FileData Class can be an observable in an 732 IndicatorExpression. The hash values of two files can be used to 733 match against an indicator using Boolean "or" logic. In the 734 following example the indicator consists of either of the two files 735 with two different hashes. 737 738 739 740 741 A4399IWQ 742 743 File hash watchlist 744 745 746 747 748 dummy.txt 749 750 751 753 754 141accec23e7e5157de60853cb1e01bc38042d 755 08f9086040815300b7fe75c184 756 757 758 759 760 761 762 763 764 765 dummy2.txt 766 767 768 770 771 141accec23e7e5157de60853cb1e01bc38042d 772 08f9086040815300b7fe75c184 773 774 775 776 777 778 779 780 781 782 784 Appendix B. Inter-vendor and Service Provider Exercise Examples 786 Below some of the incident IODEF example information that was 787 exchanged by the vendors as part of this proof-of-concept Inter- 788 vendor and Service Provider Exercise. 790 B.1. Malware Delivery URL 792 This example indicates malware and related URL for file delivery. 794 795 799 800 801 189801 802 803 2012-12-05T12:20:00+00:00 804 2012-12-05T12:20:00+00:00 805 Malware and related indicators 806 807 808 Malware with C&C 809 810 811 812 813 example.com CSIRT 814 815 816 contact@csirt.example.com 817 818 819 820 821 822 823 824 192.0.2.200 825 826 827 /log-bin/lunch_install.php?aff_id=1&lunch_id=1&maddr=&action=install 828 829 830 831 832 833 834 835 837 B.2. DDoS 839 The DDoS test exchanged information that described a DDoS including 840 protocols and ports, bad IP addresses and HTTP User-Agent fields. 842 The IODEF version used for the data representation was based on 843 [RFC7970]. 845 846 850 851 852 189701 853 854 2013-02-05T01:15:45+00:00 855 2013-02-05T00:34:45+00:00 856 2013-02-05T01:34:45+00:00 857 2013-02-05T01:15:45+00:00 858 DDoS Traffic Seen 859 860 861 DDoS Traffic 862 863 864 865 866 867 Dummy Test 868 869 contact@dummytest.com 870 871 872 873 874 875 Dummy Test sharing with ISP1 876 877 878 879 880 http://blog.spiderlabs.com/2011/01/loic-ddos- 881 analysis-and-detection.html 882 883 884 http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon 885 886 887 Low Orbit Ion Cannon User Agent 888 889 891 892 893 894 895 896 192.0.2.104 897 898 899 900 1337 901 902 903 904 905 906 192.0.2.106 907 908 909 910 1337 911 912 913 914 915 916 198.51.100.0/24 917 918 919 920 1337 921 922 923 924 925 926 2001:db8:dead:beef::1 927 928 929 930 1337 931 932 933 934 935 936 203.0.113.1 937 938 939 940 80 941 942 943 944 945 946 947 Information provided in Flow class instance is from 948 Inspection of traffic from network tap 949 950 951 952 953 954 955 956 957 G83345941 958 959 960 User-Agent string 961 962 963 964 965 user-agent="Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12"> 966 967 968 969 970 971 972 974 B.3. Spear-Phishing 976 The Spear-Phishing test exchanged information that described a Spear- 977 Phishing email including DNS records and addresses about the sender, 978 malicious attached file information and email data. The IODEF 979 version used for the data representation was based on [RFC7970]. 981 982 988 989 990 189601 991 992 2013-01-04T08:06:12+00:00 993 2013-01-04T08:01:34+00:00 994 2013-01-04T08:31:27+00:00 995 2013-01-04T09:15:45+00:00 996 2013-01-04T09:15:45+00:00 997 998 Zeus Spear Phishing E-mail with Malware Attachment 999 1000 1001 1002 1003 Malware with Command and Control Server and System Changes 1004 1005 1006 1007 1008 example.com CSIRT 1009 1010 contact@csirt.example.com 1011 1012 1013 1014 1015 Targeting Defense Contractors, 1016 specifically board members attending Dummy Con 1017 1018 1019 1020 Zeus 1021 1022 1023 1024 1025 1026 1027 http://www.zeusevil.example.com 1028 1029 1030 192.0.2.166 1031 1032 1033 65535 1034 1035 1037 EXAMPLE-AS - University of Example" 1038 1039 1041 192.0.2.0/24 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 mail1.evildave.example.com 1052 1053 1054 198.51.100.6 1055 1056 1057 65534 1058 1059 1061 EXAMPLE-AS - University of Example 1062 1063 1064 evildave.example.com 1065 2013-01-04T09:10:24+00:00 1066 1067 1068 1069 evildave.example.com MX prefernce = 10, mail exchanger 1070 = mail1.evildave.example.com 1071 1072 1073 mail1.evildave.example.com 1074 internet address = 198.51.100.6 1075 1076 1077 zuesevil.example.com. IN TXT \"v=spf1 a mx -all\" 1078 1079 1080 1081 1082 1083 Sending phishing mails 1085 1086 1087 1088 1089 1090 emaildave@evildave.example.com 1091 1092 1093 Join us at Dummy Con 1094 1095 1096 StormRider 4.0 1097 1098 1099 1100 1101 1102 1103 1104 203.0.113.2 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 Dummy Con Sign Up Sheet.txt 1116 1117 1118 152 1119 1120 1121 1122 1124 1125 141accec23e7e5157de60853cb1e01bc38042d 1126 08f9086040815300b7fe75c184 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 FakeCA 1139 1140 1141 57482937101 1142 1143 1144 EvilDaveExample 1145 1146 1147 1148 1149 1150 1151 1152 1153 1155 B.4. Malware 1157 In this test, malware information was exchanged using RID and IODEF. 1158 The information included file hashes, registry setting changes and 1159 the C&C servers the malware uses. 1161 1162 1167 1168 1169 189234 1170 1171 2013-03-07T16:14:56.757+05:30 1172 2013-03-07T16:14:56.757+05:30 1173 1174 Malware and related indicators identified 1175 1176 1177 1178 1179 Malware with Command and Control Server and System Changes 1180 1182 1183 1184 1185 example.com CSIRT 1186 1187 contact@csirt.example.com 1188 1189 1190 1191 1192 1193 1194 http://www.threatexpert.example.com/report.aspx? 1195 md5=e2710ceb088dacdcb03678db250742b7 1196 1197 Zeus 1198 1199 1200 1201 1202 1203 1204 203.0.113.200 1205 1206 1207 http://zeus.556677889900.example.com/log-bin/ 1208 lunch_install.php?aff_id=1&amp; 1209 lunch_id=1&amp;maddr=&amp; 1210 action=install 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJFREZG 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTEzRjBBNA== 1235 1236 1237 1238 1239 1240 1241 1242 1243 HKLM\Software\Microsoft\Windows\ 1244 CurrentVersion\Run\tamg 1245 1246 1247 ?\?\?%System%\wins\mc.exe\?\?? 1248 1249 1250 1251 HKLM\Software\Microsoft\ 1252 Windows\CurrentVersion\Run\dqo 1253 1254 "\"\"%Windir%\Resources\ 1255 Themes\Luna\km.exe\?\?" 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 http://www.threatexpert.example.com/report.aspx? 1267 md5=c3c528c939f9b176c883ae0ce5df0001 1268 1269 Cridex 1270 1271 1272 1273 1274 1275 1276 203.0.113.100 1277 1279 1280 1281 1282 8080 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM1ODVFMzQzRTcxNDFD 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 MHg0M0NEODUwRkNEQURFNDMzMEE1QkVBNkYxNkVFOTcxQw== 1307 1308 1309 1310 1311 1312 1313 1314 1315 HKLM\Software\Microsoft\Windows\ 1316 CurrentVersion\Run\KB00121600.exe 1317 1318 1319 \?\?%AppData%\KB00121600.exe\?\? 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 ind-91011 1330 1331 1332 evil c2 server, file hash, and registry key 1333 1334 1335 1336 1337 1338 http://foo.example.com:12345/evil/cc.php 1339 1340 1341 1342 1343 192.0.2.1 1344 1345 1346 1347 1348 198.51.100.1 1349 1350 1351 1352 1353 2001:db8:dead:beef::1 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184 1369 1370 1371 1372 1373 1374 1375 1376 1377 1379 1380 HKLM\SYSTEM\CurrentControlSet\ 1381 Services\.Net CLR 1382 1383 1384 1386 1387 HKLM\SYSTEM\CurrentControlSet\ 1388 Services\.Net CLR\Parameters 1389 1390 1391 \"\"%AppData%\KB00121600.exe\"\" 1392 1393 1394 1396 1397 HKLM\SYSTEM\CurrentControlSet\Services\ 1398 .Net CLR\Parameters\ServiceDll 1399 1400 C:\bad.exe 1401 1402 1404 1405 HKLM\SYSTEM\CurrentControlSet\ 1406 Services\.Net CLR\Parameters\Bar 1407 1408 Baz 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1432 B.5. IoT Malware 1434 The IoT Malware test exchanged information that described a bad IP 1435 address of IoT malware and its scanned ports. This example 1436 information is extracted from alert messages of a Darknet monitoring 1437 system referred in [I-D.ietf-mile-implementreport]. The IODEF 1438 version used for the data representation was based on [RFC7970]. 1440 1441 1445 1446 1447 189802 1448 1449 2017-03-01T01:15:00+09:00 1450 2017-03-01T01:15:00+09:00 1451 IoT Malware and related indicators 1452 1453 1454 IoT Malware is scanning other hosts 1455 1456 1457 1458 1459 example.com CSIRT 1460 1461 1462 contact@csirt.example.com 1463 1464 1465 1466 1467 1468 1469 Detected by darknet monitoring 1470 1472 1473 1474 1475 1476 1477 192.0.2.210 1478 1479 1480 1481 1482 23 1483 1484 1485 1486 Example Surveillance Camera OS 2.1.1 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 198.51.100.1 1497 1498 1499 1500 1501 23 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 198.51.100.94 1512 1513 1514 1515 1516 23 1517 1518 1519 1521 1522 1523 1524 1525 1526 1527 198.51.100.237 1528 1529 1530 1531 1532 2323 1533 1534 1535 1536 1537 1538 1539 1541 Authors' Addresses 1543 Panos Kampanakis 1544 Cisco Systems 1546 Email: pkampana@cisco.com 1548 Mio Suzuki 1549 NICT 1550 4-2-1, Nukui-Kitamachi 1551 Koganei, Tokyo 184-8795 1552 JP 1554 Email: mio@nict.go.jp